PHP2Shell: falha crítica no PHP pede atualização do site

Em 21 de outubro de 2026, o projeto PHP publicou correções de emergência para duas falhas críticas. Elas ganharam o apelido PHP2Shell, e são importantes para qualquer empresa com site, loja virtual ou sistema web, porque o PHP está por trás de muitos deles. Este texto resume o que os avisos oficiais do PHP dizem e o que fazer.

O que são as falhas

São duas vulnerabilidades no núcleo do PHP:

CVE-2026-109618, "RCE via OOM corruption": o PHP usa um desvio brusco (longjmp) quando falta memória, e isso pode deixar a memória em estado inválido. Segundo o aviso, a exploração remota sem autenticação foi validada contra o mod_php com configuração padrão.
CVE-2026-109619, "RCE via stale global state": um estado interno que continua apontando para memória de uma requisição já encerrada. O aviso afirma que isso pode levar à execução de código e que a exploração por meio do ciclo de vida de sessão foi validada tanto no mod_php quanto no PHP-FPM.

As duas têm nota 9,2 (crítica) na escala CVSS v4 e permitem execução remota de código com os privilégios do processo web, sem precisar de login. Em termos práticos: alguém na internet pode, em condições favoráveis, fazer o servidor executar comandos.

As versões corrigidas

Os avisos listam como corrigidas as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As versões anteriores a essas, em cada ramo, são consideradas afetadas.

Segundo o BleepingComputer, o ramo 8.1 e os anteriores já não recebem atualizações do projeto. Distribuições e fornecedores de suporte estendido podem ter correções adaptadas, e o texto indica que o ideal é migrar para uma versão corrigida. Se o seu site roda em uma versão antiga, a pergunta à hospedagem é: esta versão recebeu a correção, ou preciso migrar?

Antes da publicação, circularam relatos de que "todas as versões do PHP 5 em diante" seriam afetadas e de nota 10. Os avisos oficiais publicados depois mostram outro quadro: nota 9,2 e as versões corrigidas acima.

E o meu site (WordPress, Joomla, Drupal, loja virtual)?

O CMS não é a falha. A falha está na linguagem em que ele roda. Quem tem risco é o site hospedado em servidor com PHP anterior às versões corrigidas. O que importa, portanto, é a versão de PHP do servidor, que em hospedagem compartilhada ou gerenciada é controlada pelo provedor.

Há ataques?

O aviso do PHP afirma que a exploração remota sem autenticação foi validada. O BleepingComputer registra que o diretor de tecnologia da Cloudflare disse ter observado ataques iniciais direcionados às duas falhas antes das correções. Não há, nas fontes que li, número de sites atacados, mas já é motivo suficiente para atualizar sem esperar.

O que fazer, na ordem

Descubra a versão de PHP do seu site e como ela é atualizada. Pergunte à hospedagem ou à equipe técnica: "o PHP do meu plano já foi atualizado para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou recebeu a correção equivalente?"
Atualize para uma versão corrigida assim que possível. Os avisos do PHP dizem que é a única mitigação completa.
Se não der para atualizar já, quem administra o servidor pode aplicar medidas temporárias descritas nos avisos, como limitar o tamanho de requisições e uploads e desativar o acompanhamento de progresso de upload de sessão. Os avisos deixam claro que essas medidas não substituem a correção. A Cloudflare também publicou regras de firewall temporárias, válidas só para o tráfego que passa por ela.
Faça um backup antes de atualizar e teste o site depois.
Observe sinais de invasão nos próximos dias: arquivos desconhecidos, usuários administradores que você não criou, redirecionamentos estranhos e picos de tráfego.

Atualizar impede novos ataques por essa falha, mas não remove um acesso já obtido. Se houver suspeita, veja o que fazer quando o site é invadido. E se você usa o plugin Rank Math PRO, leia também sobre o incidente de 15 e 16 de outubro.

Cuidados para a equipe técnica

Confirme o tipo de servidor (mod_php, PHP-FPM etc.): o aviso trata os casos de forma diferente.
Não use RLIMIT_AS nem RLIMIT_DATA como mitigação, porque, segundo o aviso, podem acionar o caminho vulnerável.
Siga o texto completo dos dois avisos antes de mexer na configuração.

Precisa de ajuda com o seu site?

A Codlinx trabalha com segurança e recuperação de sites: avaliação da exposição, limpeza de malware, restauração e proteção contra novos ataques. O atendimento é de segunda a sexta, das 8h às 20h, com retorno em até 24 horas úteis. Fale com a gente.

Perguntas frequentes

O que é o PHP2Shell?

É o apelido dado a duas falhas críticas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619. Segundo os avisos oficiais do PHP, ambas permitem execução remota de código, sem autenticação, com os privilégios do processo web do servidor. Cada uma recebeu nota 9,2 na escala CVSS v4.

Meu site WordPress está vulnerável?

O WordPress em si não é o problema: a falha está no PHP, a linguagem em que ele roda. Quem corre risco é o site hospedado em um servidor com uma versão de PHP anterior às corrigidas. A reportagem do BleepingComputer cita WordPress, Joomla e Drupal apenas como plataformas que usam PHP, sem afirmar que eles sejam vulneráveis por si só. Para saber, é preciso conferir a versão de PHP do servidor.

Quais são as versões corrigidas?

Os avisos do PHP listam como corrigidas as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As versões anteriores a essas, em cada ramo, são consideradas afetadas. O BleepingComputer informa que o ramo 8.1 e os anteriores não recebem mais atualizações do projeto, e que distribuições e fornecedores de suporte estendido podem ter correções adaptadas, que o seu fornecedor deve confirmar.

Já estão explorando essa falha?

O aviso do PHP afirma que a exploração remota sem autenticação foi validada em ambientes com mod_php. O BleepingComputer registra que o diretor de tecnologia da Cloudflare disse ter observado ataques iniciais, direcionados às duas falhas, antes da publicação das correções. Isso não é prova de ataque em larga escala, mas é motivo suficiente para atualizar logo.

Não posso atualizar o PHP agora. Existe alguma proteção?

Os avisos do PHP descrevem medidas temporárias, como limitar o tamanho de requisições e uploads, desativar o acompanhamento de progresso de upload de sessão e, no PHP 8.5, desativar o backtrace de erros fatais. Os próprios avisos dizem que atualizar é a única mitigação completa. A Cloudflare também publicou regras de firewall de aplicação temporárias, que só valem para o tráfego que passa por ela. Essas medidas devem ser aplicadas por quem administra o servidor.

Quem atualiza o PHP: eu ou a hospedagem?

Depende do tipo de hospedagem. Em hospedagem compartilhada ou gerenciada, normalmente é o provedor, e vale perguntar a ele se o PHP do seu plano já foi atualizado ou corrigido. Em servidor próprio ou VPS, a atualização é responsabilidade de quem administra o servidor. Guarde a resposta por escrito.

E se o site já foi invadido?

Atualizar o PHP impede novos ataques por essa falha, mas não remove um acesso que o invasor já tenha obtido. Se houver sinais de invasão, como arquivos desconhecidos, administradores que você não criou ou redirecionamentos estranhos, trate como incidente. Veja o que fazer em 'Meu site foi invadido'.