PHP2Shell: duas falhas críticas no PHP exigem atualização

comando

**ALERTA DE SEGURANÇA — 21 DE OUTUBRO DE 2026**

Duas vulnerabilidades críticas no PHP, identificadas como **CVE-2026-109618 e CVE-2026-109619**, podem permitir que invasores executem código remotamente em servidores vulneráveis, sem precisar de usuário ou senha. As falhas, conhecidas como **PHP2Shell**, receberam classificação CVSS 4.0 de 9,2/10.

O projeto oficial PHP lançou correções emergenciais em 21 de outubro de 2026 e recomenda atualização imediata. Sites WordPress, lojas WooCommerce, sistemas Laravel e aplicações desenvolvidas em PHP podem ser afetados, dependendo da versão e da configuração do servidor.

**O que fazer agora?** Verifique qual versão do PHP atende seu site, confirme se ela já recebeu as correções das duas CVEs e atualize o ambiente. Um firewall pode reduzir determinados ataques, mas não substitui o patch.

O que aconteceu com o PHP em outubro de 2026?

Em 20 de outubro de 2026, a equipe de segurança do PHP publicou um aviso antecipando duas falhas críticas. O objetivo era permitir que administradores de servidores, provedores de hospedagem e equipes de segurança se preparassem para uma atualização emergencial.

No dia seguinte, 21 de outubro, foram publicadas quatro versões de segurança: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

As vulnerabilidades foram classificadas como críticas porque podem permitir **execução remota de código sem autenticação**, também chamada de *Remote Code Execution* (RCE).

Na prática, isso significa que, em determinados cenários de exploração, um atacante externo pode comprometer o processo PHP que executa o site.

O problema não está limitado a um plugin, tema ou plataforma. Ele envolve componentes internos da própria linguagem PHP.

A gravidade do incidente levou empresas especializadas em segurança, como a Cloudflare, a disponibilizar proteções para bloquear tentativas conhecidas de exploração.

O que é PHP2Shell?

PHP2Shell é o nome utilizado por pesquisadores para identificar as duas vulnerabilidades críticas descobertas no mecanismo de gerenciamento de memória do PHP.

As falhas estão relacionadas ao tratamento de situações de erro, à inicialização de estruturas internas e à reutilização de informações entre requisições.

Elas podem atingir aplicações PHP executadas por diferentes arquiteturas, incluindo:

• Apache com `mod_php`;
• Nginx ou Apache com PHP-FPM;
• PHP-CGI;
• LiteSpeed;
• FrankenPHP.

O projeto PHP considera o risco particularmente elevado em instalações com Apache e `mod_php`, nas quais foi demonstrada uma exploração capaz de acontecer antes mesmo da execução do código da aplicação.

**Atenção:** utilizar PHP-FPM, LiteSpeed ou outro modo de execução não significa estar automaticamente protegido.

CVE-2026-109618: corrupção de memória

A CVE-2026-109618 envolve o tratamento de erros de falta de memória, conhecidos como *Out of Memory* (OOM).

Durante determinadas operações, uma falha de alocação pode interromper a execução enquanto estruturas internas do PHP ainda estão parcialmente inicializadas.

O encerramento da requisição pode então processar dados em um estado inválido, provocando corrupção de memória.

Os mantenedores do PHP confirmaram que determinadas estratégias de exploração podem transformar esse comportamento em execução remota de código.

CVE-2026-109619: estado interno reutilizado indevidamente

A CVE-2026-109619 envolve referências a regiões de memória que já foram liberadas, mas permanecem acessíveis por estruturas globais do processo PHP.

Esse problema é conhecido como *Use After Free*.

Um processo que atende várias requisições pode reutilizar incorretamente o estado deixado por uma requisição anterior.

Em determinadas condições, a exploração pode permitir execução de código malicioso ou acesso indevido a informações processadas pelo servidor.

O risco não depende necessariamente da existência de uma vulnerabilidade no código do WordPress, do Laravel ou de outra aplicação.

Quais versões do PHP foram corrigidas?

As seguintes atualizações oficiais foram disponibilizadas em **21 de outubro de 2026**:

• **PHP 8.5:** atualizar para 8.5.12 ou posterior na mesma linha.
• **PHP 8.4:** atualizar para 8.4.27 ou posterior na mesma linha.
• **PHP 8.3:** atualizar para 8.3.36 ou posterior na mesma linha.
• **PHP 8.2:** atualizar para 8.2.35 ou posterior na mesma linha.
• **PHP 8.1 ou anterior:** verificar backports do fornecedor ou migrar para uma versão suportada.

Essas são as primeiras versões oficiais que corrigem as duas vulnerabilidades em cada linha.

E quem utiliza PHP 7.4, 8.0 ou 8.1?

Essas versões estão fora do suporte regular do projeto PHP.

Entretanto, fornecedores de distribuições Linux e serviços de suporte estendido podem disponibilizar correções retroativas, chamadas de *backports*.

Excepcionalmente, os mantenedores do PHP também disponibilizaram patches mínimos de código-fonte para as linhas 7.4, 8.0 e 8.1.

Isso não significa que as versões antigas tenham voltado ao suporte regular.

Se você utiliza CloudLinux, uma distribuição Linux empresarial ou outro fornecedor de PHP com suporte estendido, consulte o boletim de segurança do pacote instalado.

**Importante:** uma versão mais antiga pode conter o patch aplicado pelo fornecedor mesmo sem alterar seu número principal. A confirmação precisa considerar o histórico do pacote e as duas CVEs.

O PHP 8.2 também está próximo do fim do suporte oficial de segurança, previsto para 31 de dezembro de 2026. É recomendável planejar a migração para uma linha com suporte por mais tempo.

WordPress, WooCommerce e Magento estão vulneráveis?

**Sites WordPress, WooCommerce e Magento podem estar expostos ao PHP2Shell quando executados em servidores com versões vulneráveis do PHP.**

A mesma preocupação vale para plataformas Laravel, Symfony, Drupal, sistemas empresariais, APIs e aplicações PHP personalizadas.

O ponto principal é entender que a vulnerabilidade está no ambiente de execução da linguagem.

Mesmo um site com WordPress atualizado, plugins legítimos e senhas fortes pode estar exposto se o servidor executar uma versão vulnerável do PHP.

Isso não significa que todo site PHP possa ser invadido automaticamente. A exploração depende de condições técnicas específicas e pode variar conforme a arquitetura e a configuração do servidor.

Atualizar o WordPress resolve?

Não.

Atualizar o WordPress, os plugins e os temas é importante para corrigir problemas próprios dessas aplicações, mas não elimina as duas vulnerabilidades do PHP.

A correção deve ser aplicada ao runtime PHP instalado no servidor.

Para uma proteção completa, as diferentes camadas precisam ser mantidas: aplicação, linguagem, servidor web, sistema operacional e componentes de segurança.

Quais são os riscos para empresas e lojas virtuais?

As consequências de uma exploração bem-sucedida dependem das permissões do processo PHP, do isolamento entre usuários e da infraestrutura do servidor.

Entre os impactos possíveis estão:

1. Execução de código não autorizado

Um invasor pode executar instruções no contexto do processo PHP comprometido, acessando recursos permitidos àquele processo.

2. Exposição de dados confidenciais

Dependendo do cenário de exploração, podem ficar expostos dados da aplicação e informações presentes na memória, incluindo tokens, credenciais e segredos utilizados pelos sistemas.

3. Alteração de arquivos e aplicações

Um processo comprometido pode permitir modificações não autorizadas em arquivos e dados aos quais possui acesso de gravação.

4. Indisponibilidade de serviços

A exploração pode provocar erros, encerramento de processos e interrupções, afetando sites, APIs, sistemas internos e lojas virtuais.

5. Risco para outras aplicações

Em servidores que não possuem isolamento adequado entre contas e processos, o comprometimento pode ter consequências maiores.

O alcance real depende das permissões, da arquitetura e dos controles de segurança.

**A presença de uma versão vulnerável não comprova que houve invasão.** Para determinar se ocorreu comprometimento, é necessária uma investigação técnica.

Como verificar se meu site utiliza uma versão vulnerável do PHP?

A verificação pode ser realizada pelo painel de hospedagem ou pelo administrador do servidor.

Como consultar no cPanel

Se sua hospedagem utiliza cPanel:

1. Acesse o painel cPanel.
2. Localize a seção **Software**.
3. Abra o **MultiPHP Manager**, quando disponível.
4. Verifique a versão PHP configurada para o domínio.
5. Confirme com o provedor se o pacote contém as correções das duas CVEs.

Alguns ambientes com CloudLinux também utilizam um seletor próprio de PHP, que pode mostrar versões diferentes das instaladas no sistema operacional.

Como consultar no Plesk ou DirectAdmin

Nos painéis Plesk e DirectAdmin, procure a configuração PHP associada ao domínio.

Verifique a versão selecionada e consulte as atualizações fornecidas pelo administrador da hospedagem.

A nomenclatura e os recursos disponíveis dependem da versão e da configuração do painel.

Como consultar pelo terminal SSH

Em servidores Linux com acesso SSH, execute:

php -v

O comando informa a versão PHP disponível na linha de comando.

Entretanto, **a versão exibida pode ser diferente daquela utilizada pelo site**.

Servidores com PHP-FPM, múltiplas versões, contêineres ou painéis de hospedagem podem utilizar binários diferentes para atender as requisições web.

Por isso, a verificação precisa considerar o PHP efetivamente executado pela aplicação.

Em distribuições Linux empresariais, confira também o histórico de atualizações de segurança dos pacotes instalados.

Como corrigir as vulnerabilidades PHP2Shell?

A correção recomendada é atualizar o PHP para uma versão corrigida ou instalar um pacote do fornecedor que contenha os patches correspondentes.

Para reduzir riscos durante a atualização, siga esta sequência.

Passo 1: identifique todos os ambientes PHP

Faça um levantamento dos sites, domínios, subdomínios, APIs e aplicações que utilizam PHP.

Não esqueça instalações antigas, projetos secundários, contêineres e sistemas internos acessíveis pela internet.

Passo 2: confirme quais pacotes precisam de atualização

Identifique a versão, a origem do pacote e os processos utilizados pela aplicação.

Em servidores com cPanel/WHM, Plesk, DirectAdmin ou CloudLinux, consulte o mecanismo de atualização apropriado.

Não substitua manualmente pacotes administrados pelo painel sem considerar as dependências e o suporte do fornecedor.

Passo 3: prepare a atualização

Verifique se há backup recuperável e identifique as funcionalidades críticas que precisam ser testadas.

Em aplicações empresariais e lojas virtuais, considere especialmente login, checkout, integrações de pagamento, APIs e conexões com banco de dados.

Passo 4: instale as correções

Aplique os pacotes corrigidos e reinicie ou recicle os processos necessários para que o código atualizado entre efetivamente em execução.

Em ambientes Docker, atualize as imagens utilizadas e recrie os contêineres afetados, preservando corretamente os dados persistentes.

A atualização do pacote não deve ser considerada concluída enquanto os processos em execução ainda utilizarem componentes vulneráveis.

Passo 5: valide o funcionamento da aplicação

Após a correção, teste:

• Acesso ao site e ao painel administrativo;
• Autenticação e permissões;
• Formulários e envio de arquivos;
• Comunicação com banco de dados;
• Carrinho, checkout e meios de pagamento;
• APIs, integrações e tarefas agendadas.

Verifique também os logs de erro e eventuais problemas de compatibilidade.

Passo 6: investigue possíveis sinais de ataque

Se houver suspeita de exploração, preserve os registros do servidor e procure indicadores de comprometimento.

A análise pode envolver logs HTTP, processos, arquivos modificados, conexões suspeitas e atividades anormais.

Instalar o patch impede os caminhos de exploração corrigidos, mas não remove automaticamente arquivos maliciosos ou acessos estabelecidos antes da atualização.

Cloudflare, WAF e Imunify360 resolvem essas falhas?

Soluções de segurança como Cloudflare WAF e Imunify360 ajudam na estratégia de proteção dos servidores e das aplicações.

A Cloudflare informou que disponibilizou regras de proteção contra o PHP2Shell antes da divulgação pública, utilizando sinais associados às requisições HTTP e às respostas do servidor.

Segundo a empresa, seus clientes com WAF gratuito ou pago receberam proteções ativadas por padrão em 21 de outubro de 2026.

Mesmo assim, os mantenedores do PHP são claros: **não existe uma mitigação completa que substitua a atualização**.

O uso de um firewall não comprova que o PHP instalado está corrigido.

Da mesma forma, não se deve presumir que todas as regras de segurança de produtos diferentes ofereçam cobertura equivalente.

O ideal é combinar patches, firewall, isolamento de contas, monitoramento, controle de acesso e backups.

O que fazer se não for possível atualizar imediatamente?

O projeto PHP publicou medidas temporárias para reduzir caminhos específicos de exploração.

Entre elas estão ajustes no processamento de uploads, limites de requisições, gerenciamento de memória e determinadas configurações de sessão.

No caso da CVE-2026-109619, por exemplo, o comunicado apresenta a desativação de `session.upload_progress.enabled` como uma das medidas parciais.

Para a CVE-2026-109618, existem recomendações específicas envolvendo `memory_limit` e `post_max_size`.

**Esses ajustes não devem ser aplicados indiscriminadamente em produção.** Algumas alterações podem aumentar o consumo de recursos, provocar indisponibilidade ou interferir no funcionamento das aplicações.

A implementação exige análise do ambiente e das orientações oficiais.

Se não houver atualização disponível, avalie as proteções temporárias documentadas e reduza a exposição do serviço. Em sistemas com risco inaceitável, a suspensão temporária do acesso público pode ser necessária.

Quem é responsável pela atualização em uma hospedagem?

A responsabilidade depende do modelo de serviço contratado.

**Hospedagem compartilhada:** normalmente, o provedor administra o sistema operacional, o servidor web e os pacotes PHP que disponibiliza. O proprietário do site administra sua aplicação.

**VPS não gerenciada:** o cliente é responsável pela manutenção do servidor, incluindo sistema operacional, PHP, aplicações e serviços instalados.

**VPS assistida:** o cliente mantém responsabilidades administrativas e conta com assistência conforme o escopo contratado.

**VPS gerenciada:** as atividades de administração e atualização seguem as responsabilidades definidas no contrato do serviço.

Se você não sabe quem administra o PHP do seu site, essa é a primeira informação que deve confirmar.

Como solicitar a verificação ao suporte técnico?

Se você utiliza uma hospedagem administrada por terceiros, informe o domínio ou serviço e peça confirmação específica sobre:

• CVE-2026-109618;
• CVE-2026-109619;
• Versão PHP ou pacote de segurança instalado;
• Aplicação efetiva dos patches no runtime web.

A resposta deve informar se o ambiente foi corrigido ou se existe alguma pendência. Não basta confirmar apenas que existe um firewall ativo.

Como a Hospedagem Segura trabalha a proteção dos sites?

Uma hospedagem precisa oferecer mais do que espaço para arquivos. A segurança depende da combinação entre infraestrutura, isolamento, atualizações e responsabilidades bem definidas.

Os planos de hospedagem WordPress da **Hospedagem Segura** incluem recursos como:

• Proteção Imunify360 contra malware e ataques comuns;
• Isolamento de contas com CloudLinux e CageFS;
• Certificados SSL automáticos;
• Backups periódicos conforme o serviço contratado;
• Painel de gerenciamento e recursos compatíveis com o plano.

Esses mecanismos contribuem para a segurança do ambiente, mas não substituem a correção de vulnerabilidades no PHP ou a atualização das aplicações.

Também é fundamental distinguir as proteções oferecidas pelo provedor das atividades que continuam sob responsabilidade do proprietário do site.

Para conhecer os serviços disponíveis, consulte nossa [Hospedagem PHP](https://www.hospedagemsegura.com.br/hospedagem-php/) e a [Hospedagem para WordPress](https://www.hospedagemsegura.com.br/hospedagem-wordpress/).

Perguntas frequentes sobre as falhas críticas no PHP

O que é a vulnerabilidade PHP2Shell?

PHP2Shell é o nome utilizado para duas falhas críticas de gerenciamento de memória do PHP, identificadas como CVE-2026-109618 e CVE-2026-109619. Elas podem permitir execução remota de código em determinadas configurações vulneráveis.

Qual é a gravidade das vulnerabilidades?

As duas receberam pontuação CVSS 4.0 de 9,2 em uma escala de 0 a 10, correspondendo à classificação crítica.

Quais versões do PHP corrigem o problema?

As primeiras versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas em 21 de outubro de 2026. Fornecedores de suporte estendido podem disponibilizar backports para versões anteriores.

Meu WordPress pode ser invadido mesmo atualizado?

Pode existir exposição caso o WordPress utilize um runtime PHP vulnerável, mesmo quando a aplicação, os plugins e os temas estejam atualizados. A possibilidade de exploração depende do ambiente.

Quem utiliza PHP-FPM também precisa atualizar?

Sim. O comunicado oficial inclui PHP-FPM entre os ambientes afetados. A utilização desse modo de execução não elimina a necessidade de correção.

O Cloudflare impede completamente os ataques?

Não existe garantia de proteção completa apenas com WAF. A Cloudflare disponibilizou mecanismos específicos para reduzir a exposição, mas a recomendação definitiva do projeto PHP é atualizar o runtime.

Como saber se o provedor corrigiu o problema?

Solicite confirmação da aplicação dos patches para ambas as CVEs, informando o domínio ou serviço. A verificação deve considerar o pacote do fornecedor e o PHP realmente utilizado pela aplicação.

Preciso atualizar imediatamente?

Sim. Os mantenedores do PHP recomendam atualização imediata devido à gravidade das falhas e à possibilidade de execução remota de código sem autenticação.

Conclusão: manter o PHP atualizado é essencial para a segurança do seu site

As falhas CVE-2026-109618 e CVE-2026-109619 mostram que uma aplicação pode estar exposta mesmo quando seu código não apresenta uma vulnerabilidade conhecida.

A segurança de um site depende também do sistema operacional, do servidor web e da linguagem utilizada para executar suas funcionalidades.

A medida prioritária é verificar o runtime PHP, confirmar a disponibilização dos patches e aplicar as correções apropriadas.

Se você administra sites, lojas virtuais ou sistemas empresariais desenvolvidos em PHP, **não deixe essa atualização para depois**.

A Hospedagem Segura oferece [hospedagem de sites](https://www.hospedagemsegura.com.br/hospedagem-de-sites/), [hospedagem WordPress](https://www.hospedagemsegura.com.br/hospedagem-wordpress/) e soluções de servidores para diferentes necessidades de infraestrutura.

**Já é cliente?** Utilize a área do cliente para registrar uma solicitação técnica, informando seu domínio ou serviço. Para novos projetos, conheça nossas opções de [Hospedagem PHP](https://www.hospedagemsegura.com.br/hospedagem-php/).

Fontes oficiais e referências

Esta matéria foi elaborada a partir das publicações técnicas de 21 de outubro de 2026:

• [PHP.net — Comunicado oficial das vulnerabilidades e atualizações](https://www.php.net/archive/2026.php#2026-10-21-5)
• [PHP Security Advisory — CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
• [PHP Security Advisory — CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
• [Cloudflare — Proteções contra PHP2Shell](https://blog.cloudflare.com/php-vulnerabilities-waf-protection)
• [PHP.net — Ciclo de suporte das versões](https://www.php.net/supported-versions.php)

*Publicado em 21 de outubro de 2026. Equipe Técnica da Hospedagem Segura.*

*Recomendações técnicas devem ser adaptadas às características, aos pacotes instalados e às responsabilidades administrativas de cada ambiente.*