Falha PHP2Shell expõe núcleo do PHP usado por 70% da web

Duas falhas no núcleo do PHP, achadas por dois caminhos diferentes

Em agosto de 2026, pesquisadores da empresa de segurança Calif, atuando dentro do programa Patch the Planet da OpenAI, identificaram duas vulnerabilidades no motor do PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) →: CVE-2026-109618 e CVE-2026-109619, batizadas de PHP2Shell. Segundo a cobertura da Latent Space, publicada em 22 de outubro de 2026, os defeitos ficam no tratamento interno de condições de falta de memória e erros fatais do PHP, não em um plugin de WordPress ou numa falha de autenticação de aplicação. Isso significa que o problema está no interpretador, não no código que os desenvolvedores escrevem por cima dele.

As demonstrações divulgadas pelo pesquisador Ryan Austin mostram execução remota de código sem autenticação (RCE) contra WordPress, Drupal e Joomla, além de um vazamento de memória remoto descrito como "estilo Heartbleed", capaz de atingir qualquer aplicação PHP. São resultados reportados pelos próprios pesquisadores, e a Latent Space frisa que isso não deve virar automaticamente a hipótese de que toda instalação tem o mesmo caminho de exploração imediatamente disponível.

GPT-5.6 Sol e Gemini 4 Argon entraram na caça ao bug, cada um por sua conta

A descoberta tem duas origens independentes, segundo o relato. De um lado, a Calif usou o GPT-5.6 Sol da OpenAI, com acesso viabilizado pelo programa Daybreak for Frontline Defenders, um subsídio de US$ 1 bilhão para pesquisadores de segurança usarem os modelos de ciber da OpenAI, anunciado cerca de dois meses antes do caso vir a público. De outro, a Wiz, recém-incorporada ao Google Cloud↳Google Cloud13 conteúdosPrograma da Google Cloud no Brasil projeta formar de forma gratuita 30 mil universitáriosDev (Back & Front) · mar 2026Google Cloud OnBoard capacita estudantes e desenvolvedores de TIGestão Dev & TI · mai 2019Desenvolvedores poderão participar de treinamento gratuito do Google CloudGestão Dev & TI · mai 2019Ver tudo em DevSecOps →, chegou às mesmas falhas usando o Gemini 4 Argon combinado com uma ferramenta própria, a Wiz Atlas.

• Calif / OpenAI: GPT-5.6 Sol, acesso via Daybreak, projeto Patch the Planet.
• Wiz / Google Cloud: Gemini 4 Argon, Wiz Atlas, achado de forma independente.

A OpenAI chama esse tipo de cenário de "janela do defensor": o modelo acha a falha antes do atacante, o que dá tempo para preparar uma resposta. Vale o cuidado que a própria Latent Space aponta: a formulação da empresa é "ao que sabemos" (to our knowledge), não uma prova de que nenhum atacante já conhecia a vulnerabilidade antes disso.

O Google, por sua vez, divulgou que em testes internos da Wiz o Gemini 4 Argon achou mais do que o dobro de vulnerabilidades em comparação a modelos usados como linha de base, mas sem publicar o conjunto de dados, orçamento de testes ou taxa de falsos positivos, o que impede qualquer comparação independente entre os dois modelos nesse episódio específico.

Dois meses de bastidores até o patch sair do forno

Assim que confirmada a gravidade do achado, PHP Foundation, pesquisadores e provedores de segurança entraram num ciclo de coordenação que durou cerca de dois meses antes da divulgação pública, segundo relatos da própria OpenAI (incluindo o pesquisador Eric Wallace e o presidente Greg Brockman). A correção exigiu uma mudança relevante no motor do PHP, não um ajuste pontual, e passou por testes de detecção e validação antes de ir ao ar.

Enquanto isso não saía, a Cloudflare publicou regras de WAF (web application firewall) cobrindo os vetores de exploração já conhecidos, liberadas inclusive para clientes do plano gratuito. O próprio CTO da empresa foi explícito: tratava-se de um paliativo, não de substituto para o patch, que teve janela de lançamento marcada para as 14h UTC de 21 de outubro de 2026 (23h no horário do Japão). A NSA, por sua vez, recomendou que operadores se preparassem para atualizar imediatamente e, caso não conseguissem mitigar a tempo, tirassem os sistemas do ar.

O que vazou antes da hora, e o que ainda não dá pra confirmar

A Cloudflare relatou, antes mesmo do lançamento oficial do patch, "ataques iniciais" explorando os vetores já conhecidos, o que indica que informações sobre a falha circularam de forma antecipada. Reportagens citadas pela Latent Space dizem que detalhes vazaram cedo, mas o material disponível não deixa claro o que exatamente vazou, quando, nem se isso mudou o cronograma de lançamento.

Uma compilação que viralizou depois junta números e incidentes que precisam ser lidos com cautela: cerca de 1,5 milhão de servidores sem a correção, atribuído à Censys; interrupções em instituições holandesas, sites de governo em outros países europeus, Wikipedia, Archive.org, Asana e GOG; e um alerta às 5h55 do primeiro-ministro do Japão. A própria Latent Space destaca que nenhuma dessas alegações individuais está amparada, no material disponível, por um aviso oficial, uma medição independente ou uma página de status que confirme a causa de cada interrupção.

Falta ainda, no conjunto de informações reunido pela cobertura, a camada mais básica que qualquer time de resposta a incidente precisa: o aviso oficial da PHP Foundation, a matriz exata de versões afetadas e corrigidas, os identificadores de pacote por distribuição e o commit do patch. Sem isso, uma instrução do tipo "atualize para a versão X" não pode ser dada com segurança pela cobertura disponível, e cabe a cada time buscar essa informação diretamente nos canais oficiais do PHP.

O que muda pra quem mantém PHP em produção no Brasil

O PHP segue sustentando boa parte do mercado de hospedagem compartilhada, agências e lojas virtuais no Brasil, normalmente via WordPress, mas também Drupal, Joomla e aplicações internas legadas. Um bug no motor, e não numa camada de aplicação, atinge esse parque inteiro de uma vez, inclusive sites que ninguém mexe há anos e que raramente aparecem num inventário de ativos atualizado.

O primeiro problema prático é achar onde o PHP está rodando: hospedagem gerenciada, contêineres, workers em segundo plano, appliances e aplicações antigas que ninguém lembra que existem. Um operador citado na cobertura da Latent Space descreve o cansaço de testar e atualizar dezenas de sites WordPress/PHP ao mesmo tempo; outro conclui que a distribuição de patches no ecossistema é mal coordenada, o que soa familiar pra quem já tentou atualizar um parque grande de sites de clientes de uma vez.

O segundo problema é a falsa sensação de segurança do WAF. A regra da Cloudflare cobre vetores conhecidos e estava sendo atualizada conforme novos ataques apareciam, mas o próprio fornecedor chamou isso de paliativo. Proxy ativado, rotas alternativas de entrada e exposição direta da origem precisam ser checados, não assumidos como resolvidos só porque o site está atrás de um WAF.

A OpenAI publicou um repositório com uma skill do Codex pensada para ajudar operadores a checar se seus sites estavam vulneráveis. É uma ferramenta de apoio, útil como primeiro filtro, mas não substitui a verificação da versão de pacote realmente instalada nem um aviso oficial de fornecedor.

O debate que fica: usar IA pra caçar bug em infraestrutura crítica muda a régua

O episódio reforça uma discussão que já vinha crescendo no setor de segurança: dar acesso a modelos de ponta para pesquisadores vetted muda o volume de vulnerabilidades encontradas. Outro pesquisador citado na cobertura credita o acesso ao Daybreak da OpenAI por um portfólio de achados que vai do PHP a GitLab, Chrome e WordPress. Em contraste, a Anthropic teria atrasado em quatro meses o acesso amplo a modelos da classe Mythos para reforçar salvaguardas de cibersegurança, segundo outro relato da cobertura, sem que o material disponível diga se essa cautela ajudou ou atrapalhou neste caso específico.

Também apareceu na discussão um número que merece ceticismo: a investidora Sarah Guo relatou alta nos registros de CVE, de cerca de 4.000 por mês para 15.000 desde abril, questionando se verificação formal de código e distribuições mais seguras deveriam entrar no radar. Esse volume não é verificado de forma independente no material disponível, e nem todo CVE a mais significa exploração bem-sucedida: pode refletir também mais gente (e mais IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →) caçando bug.

Por fim, surgiu uma ideia radical e, até aqui, só uma proposta: usar o próprio RCE do PHP2Shell para corrigir automaticamente servidores vulneráveis sem autorização dos donos. A sugestão apareceu em discussões citadas pela Latent Space, incluindo a ideia de um indulto para quem tentasse. Nada disso tem respaldo legal, e explorar sistemas sem autorização carrega risco de acesso indevido, quebra de evidências e responsabilidade civil e criminal em múltiplas jurisdições, mesmo com boa intenção.

O checklist que sobra pro time de infraestrutura

Sem o aviso oficial e a matriz de versões em mãos, a sequência defensável citada pela cobertura é:

1. Buscar o aviso oficial da PHP Foundation e da distribuição Linux usada em produção.
2. Fazer o inventário de onde o PHP roda de verdade (hospedagem, contêineres, workers, appliances).
3. Aplicar proteção temporária (WAF) só como ponte, nunca como solução final.
4. Instalar o pacote corrigido autenticado e reiniciar os processos afetados.
5. Verificar a versão realmente em execução, não só o que o gerenciador de pacotes diz.
6. Investigar sinais de exploração prévia separadamente, já que atualizar fecha a falha, mas não prova que nada vazou antes.

Essa é a parte que fica igual, com ou sem IA de ponta caçando bug: patch sem inventário e sem verificação é patch pela metade.

Fonte: Latent Space