Pesquisadores acharam, com ajuda de IA, falhas críticas no próprio motor do PHP, que roda cerca de 70% dos sites. A correção saiu em 21 de outubro. Veja como checar a versão do seu servidor, o que cobrar da hospedagem e o que fazer se estiver no PHP 8.1 ou anterior.
Se a sua empresa tem site, loja ou sistema rodando em PHP, a tarefa desta semana é simples de dizer: confirmar a versão do PHP no servidor e atualizar. Em 21 de outubro de 2026, o time de pesquisa da Wiz divulgou um conjunto de falhas no próprio motor do PHP, batizado de PHP2Shell, e no mesmo dia o projeto PHP publicou a correção.
O problema não está no código do seu site. Está na linguagem que roda por baixo dele, o que inclui sites em WordPress, Drupal e Joomla e sistemas feitos sob medida em PHP.
O que foi descoberto?
Segundo a Wiz, as falhas foram agrupadas em duas identificações oficiais, CVE-2026-109618 e CVE-2026-109619, com gravidade de até 9.2 na escala CVSS, que vai até 10. Pelo que descrevem a Wiz, a CISA (agência de cibersegurança e infraestrutura do governo dos EUA) e o TechCrunch:
- As falhas permitem executar código no servidor remotamente, sem login.
- Também permitem ler pedaços da memória do servidor, onde podem estar senhas, tokens de acesso, chaves de API e certificados.
- Toda versão do PHP lançada na última década é afetada por pelo menos uma delas, desde a 5.4, segundo a Wiz.
- A exploração não depende de erro no código da aplicação: até uma página simples rodando numa versão afetada pode ser vulnerável.
- Os pesquisadores demonstraram a execução remota sem login em instalações atuais de WordPress, Drupal e Joomla, como exemplos. A falha está no PHP, não nesses sistemas.
A CISA informou que não tinha observado exploração dessas falhas até a publicação do alerta, e o TechCrunch relata que não havia registro de ataques. Mas, agora que os detalhes são públicos, o prazo para atualizar ficou curto.
Como saber qual versão do PHP o seu site usa?
- Na hospedagem compartilhada, o painel (cPanel, Plesk ou o painel próprio da empresa) costuma mostrar a versão do PHP em uma opção como "Selecionar versão do PHP" ou "MultiPHP".
- No WordPress, a versão aparece em Ferramentas, Saúde do site, aba Informações, seção Servidor.
- Em servidor próprio ou VPS, quem administra pode conferir com o comando php -v e também a versão usada pelo servidor web, que às vezes é diferente da linha de comando.
- Em sistema feito por um fornecedor, peça a ele por escrito a versão do PHP em produção e a data prevista da atualização.
Qual versão resolve?
A CISA orienta atualizar para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Segundo a Wiz, a correção do projeto PHP ataca a causa na raiz e elimina também as variantes conhecidas do problema. A CISA também pede para fazer um inventário de tudo que roda PHP, porque ele muitas vezes vem embutido em outros softwares, e priorizar o que está exposto na internet.
O que cobrar da hospedagem?
- Que a hospedagem confirme por escrito qual versão do PHP está ativa no seu plano e se ela já recebeu a correção de 21 de outubro.
- Se a correção ainda não foi aplicada, uma data para isso.
- Se há firewall de aplicação (WAF) ou outra proteção ativa enquanto a atualização não sai. Vários provedores de infraestrutura prepararam proteções para quem não consegue atualizar na hora, segundo a Wiz, e a CISA diz que um WAF pode dar alguma proteção até a correção.
- Depois da troca de versão, teste o site: formulários, carrinho, login e integrações. Atualização de PHP às vezes quebra plugin ou código antigo.
E se o site estiver no PHP 8.1 ou anterior?
Aqui o caso é mais sério. O PHP 8.1 e as versões anteriores não recebem mais suporte, e por isso não ganham essa correção. A orientação da CISA é direta: quem não consegue atualizar agora, ou ainda usa o PHP 8.1 ou anterior, deve tirar os sistemas em PHP do ar até conseguir atualizar. O TechCrunch relata que a NSA, agência de segurança nacional dos EUA, deu a mesma recomendação.
Na prática, isso costuma exigir migrar para uma versão suportada e testar plugins, temas e código próprio que dependem da versão antiga. Se o sistema foi feito há anos e ninguém mais mexe nele, é a hora de descobrir quem pode fazer essa migração. Enquanto isso, vale ativar a proteção de WAF que a hospedagem ou a CDN oferecerem e revisar se o sistema precisa mesmo ficar aberto na internet.
O próprio WordPress informou, segundo o TechCrunch, que a falha não é específica do WordPress e que os donos de sites precisam atualizar os servidores e trabalhar com a hospedagem para garantir a proteção. Atualizar plugins não basta neste caso: a troca é no PHP.
O que observar enquanto a atualização não sai?
Como as falhas agem abaixo da aplicação, os registros do site podem mostrar pouca coisa. A Wiz sugere atenção a alguns sinais, e a CISA acrescenta outro:
- Requisições de upload incomuns seguidas de erros de limite de memória ou de erros HTTP 500 repetidos.
- Cookies PHPSESSID grandes ou malformados nas respostas do servidor.
- Processos do PHP reiniciando sem explicação.
- Processos do PHP abrindo um terminal (shell) ou baixando ferramentas, segundo a CISA.
Esses sinais ajudam numa investigação, mas a Wiz é clara: a única correção completa é aplicar a atualização do PHP.
Por que a IA encurtou o prazo entre a falha e o ataque?
O código vulnerável estava no PHP havia mais de dez anos. Segundo a Wiz, transformar essas falhas em um ataque que funciona exigia encadear vários erros e ajustar a técnica ao jeito como cada servidor organiza a memória, um trabalho no limite do que pesquisadores conseguiam fazer na prática. Modelos de IA de ponta reduziram essa barreira: ajudam a adaptar o ataque a versões, configurações e servidores diferentes, testando e corrigindo cada tentativa.
A Wiz diz que, com modelos de fronteira e as ferramentas certas, um único pesquisador fez em uma semana o que antes levaria meses de um time inteiro. A primeira falha foi encontrada em 19 de agosto, reportada ao PHP em 24 de agosto, e a correção saiu em 21 de outubro, junto com a divulgação pública. A mesma capacidade que ajudou a achar e corrigir as falhas também baixa o custo de quem quer explorá-las. A complexidade deixou de ser uma proteção.
O que fica para quem tem sistema em produção?
A lição vale além do PHP. Todo sistema roda sobre camadas que alguém precisa acompanhar: linguagem, servidor, banco de dados, bibliotecas. Quando sai uma correção crítica, a pergunta "o que roda onde, e em que versão?" precisa ter resposta em minutos, não em dias.
Nos sistemas sob medida que construímos, isso faz parte do projeto e da operação: inventário do que roda em cada servidor, um caminho testado para atualizar sem derrubar a operação e registro de cada mudança. Explicamos como organizamos essas camadas em As quatro camadas de um software com agentes de IA.
Falha antiga com ataque novo: a correção já existe, o que conta agora é quanto tempo leva para chegar ao seu servidor.
Leia também
- As quatro camadas de um software com agentes de IA
- Agente de IA como funcionário com crachá: permissão mínima, aprovação humana e registro de tudo
- Quando um software pronto deixa de servir (e quando ainda serve)
Fontes
- Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 21 de outubro de 2026
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching, 21 de outubro de 2026
- TechCrunch: PHP Armageddon: OpenAI, Google's Wiz find ancient holes, panicking the internet, 21 de outubro de 2026
Transforme essa leitura em um sistema.
Diagnóstico da operação, projeto e construção por etapas. O próximo passo depende do seu caso, não de um pacote pronto.
