O projeto PHP corrigiu em 21 de outubro de 2026 duas falhas críticas, a CVE-2026-109618 e a CVE-2026-109619, que permitiam a um atacante sem login executar código em servidores que rodam a linguagem. Batizadas de php2shell, as falhas receberam nota 9,2 de 10 na escala CVSS 4.0, segundo o php.net, e atingem praticamente qualquer instalação PHP que responde a requisições na web. Para quem mantém site WordPress, loja virtual em WooCommerce ou Magento, ou revende hospedagem no Brasil, a conta é simples: servidor sem a atualização fica exposto a invasão, roubo de dados e pichação do site, e atualizar WordPress, tema ou plugin não resolve.
As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas pelo projeto às 11h de Brasília do dia 21. Uma das falhas foi achada pela empresa de segurança Calif com o modelo GPT-5.6 Sol, dentro do programa Patch the Planet da OpenAI, segundo post da OpenAI publicado no mesmo dia.
O que foi corrigido
A CVE-2026-109618 envolveu o tratamento de falta de memória. Segundo a PHP Foundation, se uma requisição atingisse o limite de memória do PHP no momento errado, o motor deixava dados internos montados pela metade e depois os tratava como válidos, corrompendo a memória.
A CVE-2026-109619 envolveu estado interno que sobrevivia a um erro fatal. De acordo com o aviso oficial do php.net, uma requisição seguinte atendida pelo mesmo processo podia usar memória que já tinha sido liberada, o que abre caminho para execução de código.
As duas falhas ficam em partes do PHP que quase toda requisição usa, o gerenciamento de memória e o tratamento de erros. A PHP Foundation afirmou que essa posição central explica tanto a gravidade quanto a dificuldade de corrigir sem quebrar compatibilidade ou desempenho.
Quem corre mais risco
O php.net listou como afetadas todas as instalações que servem páginas, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O projeto considerou o risco maior no mod_php, configuração em que um exploit demonstrado disparou o ataque com uma requisição sem autenticação, antes de qualquer código da aplicação rodar.
Segundo a PHP Foundation, a execução remota de código com configurações padrão foi demonstrada no Apache com mod_php. No PHP-FPM, comum em hospedagens com Nginx, a execução também foi confirmada, mas por caminhos que dependem do código da aplicação.
A Wiz, que publicou sua própria análise em 21/10, afirmou que toda versão do PHP lançada na última década tem ao menos uma das falhas, desde a 5.4. A empresa também disse que as brechas permitem ler a memória do processo, onde podem estar senhas, tokens e chaves de API de outras requisições.
Versões antigas e o recado da CISA
O PHP 8.1 e as versões anteriores não recebem mais atualizações oficiais do projeto, informou o php.net em 21/10. Pela gravidade do caso, a equipe de segurança publicou correções mínimas em código fonte para as versões 7.4, 8.0 e 8.1, voltadas a quem compila o PHP por conta própria, sem novas versões empacotadas.
A agência americana de cibersegurança CISA publicou alerta em 21 de outubro pedindo atualização imediata. A agência recomendou que organizações que não puderem atualizar logo, ou que sigam no PHP 8.1 ou anterior, tirem do ar os sistemas baseados em PHP até a correção.
A CISA disse que, até a publicação do alerta, não tinha observado exploração das falhas. A agência citou o firewall de aplicação web como proteção parcial e pediu monitoramento de processos PHP que abram shells ou baixem ferramentas.
No Brasil, o CTIR Gov, ligado ao Gabinete de Segurança Institucional, publicou o Alerta 93/2026 em 21/10, às 15h29. O órgão recomendou identificar os sistemas com PHP, aplicar as atualizações de imediato e, se isso não for viável, restringir o acesso pela internet, ressalvando que essas medidas não substituem a correção. A ias.news não localizou alerta específico do CERT.br até a publicação desta reportagem.
Como a falha foi achada com IA
A OpenAI afirmou que a Calif identificou uma falha crítica usando o GPT-5.6 Sol no Patch the Planet, programa da empresa de apoio a mantenedores de código aberto. Segundo a OpenAI, a Wiz descobriu e relatou as duas falhas de forma independente.
A PHP Foundation detalhou a linha do tempo. A Calif começou a auditar o PHP em 30 de julho de 2026, e em 11 de agosto o pesquisador Ryan A relatou uma execução remota de código com a mesma causa raiz de um problema de memória que a equipe do PHP já tinha detectado em 2024.
No mesmo 11 de agosto, segundo a fundação, a própria OpenAI relatou a mesma causa raiz, e a Wiz enviou novos vetores de ataque em 24 de agosto. A OpenAI mandou vetores adicionais em 18 de setembro.
A fundação reconheceu atraso na correção. Em 2024, a equipe chegou a desenvolver abordagens concorrentes, mas cada uma trazia efeitos colaterais, e o trabalho parou e recomeçou por meses, o que o texto classificou como “falha estrutural” de processo e de falta de recursos.
A Wiz afirmou que modelos de IA de fronteira reduziram a barreira para transformar uma falha antiga em exploit funcional. Segundo a empresa, montar o ataque exigiu encadear várias falhas e adaptar o código a cada alvo, trabalho que os modelos tornaram viável em horas.
Vazamento antes da hora
A divulgação coordenada estava marcada para 22 de outubro, às 14h UTC, mas os números das CVEs começaram a circular em fóruns em 20/10, por volta do meio-dia de Brasília. Segundo a PHP Foundation, o vazamento veio com nota errada, 10, e sem detalhes técnicos, e o projeto antecipou a correção em um dia.
A fundação relatou ainda que a Calif publicou por engano um vídeo com sua prova de conceito funcionando contra alguns alvos. O vídeo foi apagado, mas cópias circularam e, segundo a fundação, aceleraram o desenvolvimento de exploits por terceiros.
A fundação também acusou a Chainguard de quebrar o embargo às 4h41 de Brasília do dia 21, mais de seis horas antes da divulgação, ao publicar imagens com a correção. Até o lançamento, a equipe do PHP disse não ter identificado exploit funcional entre os que circularam.
O que dizem as hospedagens
A Hostinger informou em seu blog, em atualização de 22/10 às 4h20 de Brasília, que instalou a correção em todos os servidores de hospedagem, menos VPS, que ficam a cargo do cliente. A empresa disse ter bloqueado no firewall as tentativas de ataque conhecidas e desligado o recurso session.upload_progress em várias configurações; o comunicado é global e não traz nota específica sobre clientes brasileiros.
Segundo a Hostinger, na hospedagem gerenciada a correção entrou na mesma versão do PHP já usada pelo site, então o número pode não mudar. A empresa orientou checar a data de compilação na página PHP Info do painel, que precisa ser de 21 de outubro de 2026 ou posterior.
A HostGator publicou em sua página global de status, em 22/10, a lista de versões corrigidas em cPanel, CloudLinux e Plesk, incluindo correções de fornecedores para PHP 8.1, 8.0 e 7.4. A empresa disse aplicar os pacotes por conta própria e pediu que donos de VPS e servidores dedicados atualizem pelo painel; a ias.news não encontrou comunicado específico da operação brasileira.
A ias.news não localizou comunicado público da Locaweb nem da KingHost sobre as falhas até a publicação desta reportagem. Clientes dessas empresas devem abrir chamado e perguntar se o servidor já recebeu a correção e se os processos PHP foram reiniciados.
Box prático: como checar e atualizar o PHP
1. Descubra a versão. No WordPress, abra Ferramentas, Saúde do site, Informação, seção Servidor. Em hospedagem com cPanel ou painel próprio, procure a página PHP Info. Em servidor próprio, rode php -v no terminal.
2. Compare com as versões seguras. O mínimo é 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, conforme o ramo. Em distribuições Linux e hospedagens, a correção pode vir com outro número de versão; nesse caso, confira o changelog do pacote ou a data de compilação.
3. Hospedagem compartilhada. Pergunte ao suporte se a correção já foi aplicada no seu servidor. Se o site está no PHP 8.1 ou anterior, avalie migrar para 8.3 ou mais novo pelo painel, depois de confirmar que tema e plugins são compatíveis.
4. VPS ou servidor dedicado. Atualize o pacote do PHP pelo gerenciador da distribuição, por exemplo sudo apt update && sudo apt upgrade no Debian e Ubuntu ou sudo dnf upgrade no AlmaLinux e Rocky. Depois reinicie o PHP-FPM ou o Apache, porque processos antigos continuam vulneráveis.
5. Se não der para atualizar agora. O php.net sugeriu desligar session.upload_progress.enabled no php.ini e reiniciar os processos, além de reduzir post_max_size. O próprio projeto avisou que essas medidas só fecham caminhos específicos e não deixam a instalação segura.
O dinheiro da OpenAI e o acesso do Brasil
No post de 21/10, a OpenAI afirmou ter comprometido US$ 1 bilhão em acesso subsidiado ao Daybreak, seu conjunto de ferramentas de cibersegurança, pelo programa Daybreak for Frontline Defenders. O valor, anunciado em 3 de setembro de 2026, é em uso de produtos da empresa, não em dinheiro, e a OpenAI disse que pretende consumi-lo em seis meses.
Segundo a página do programa, a prioridade inicial é para os Estados Unidos, com operadores de água e energia, governos estaduais e locais, bancos regionais, organizações sem fins lucrativos e mantenedores de código aberto. A OpenAI disse que pretendia expandir o modelo a “países parceiros”, mas não divulgou quais, e não há confirmação de que organizações brasileiras possam participar agora.
Mantenedores de projetos abertos, inclusive brasileiros, podem se inscrever no Patch the Planet para receber apoio técnico, segundo o post. A empresa também citou assinaturas do Codex for OSS para mantenedores e patrocínio direto a projetos como a Rust Foundation.
O que a OpenAI propõe e o que ainda falta
A OpenAI apresentou no post um roteiro em cinco etapas para responder a falhas graves em software muito usado, da validação da correção ao apoio na implantação. A empresa disse ter trabalhado com a Cloudflare e outros parceiros em proteções antes da divulgação e ter acionado o Office of the National Cyber Director (ONCD) e a CISA, nos Estados Unidos.
A empresa disponibilizou um verificador de versões do PHP como skill do Codex e pediu sugestões da comunidade de segurança sobre prazos de divulgação e aviso prévio. A OpenAI também afirmou esperar aumento forte de achados parecidos nos próximos meses, sem divulgar quais outros softwares estão sob análise.
A PHP Foundation, por sua vez, informou que publicou 15 CVEs desde 1º de julho e descartou mais de 100 relatos inválidos, duplicados ou não reproduzíveis, volume que atribuiu em parte à pesquisa assistida por IA. A fundação pediu que empresas, hospedagens e governos que dependem do PHP financiem a equipe de segurança, hoje formada por poucos desenvolvedores pagos.
Para o dono de site no Brasil, o próximo passo não depende da OpenAI nem da fundação. O php.net lembrou que o PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026, o que torna a atualização desta semana também um bom momento para planejar a migração.
Fontes: php.net, aviso de segurança e notas das versões de 21/10/2026; PHP Foundation, “Today’s PHP Security Release, and How We’re Strengthening PHP Security”; CISA, alerta de 21/10/2026; CTIR Gov, Alerta 93/2026; OpenAI, “Patch the Planet: global response coordination as agents uncover critical vulnerabilities”; OpenAI, “Daybreak for Frontline Defenders”; Wiz, “PHP2Shell”; Hostinger; HostGator, página de status.