Os pesquisadores que encontraram os bugs do PHP2Shell foram diretos sobre o que a IA da sua cadeia de ferramentas fez e não fez. "Nenhum modelo é simplesmente capaz de descobrir 'todos os bugs' com prompts simples. Pelo menos por enquanto", escreveu a empresa de segurança Calif em seu relatório, citada pelo TechCrunch. Guarde essa frase quando vir manchetes dizendo que máquinas encontram falhas mais rápido do que pessoas conseguem corrigir. As manchetes estão quase certas, e os detalhes são mais estranhos.
Várias histórias separadas chegaram ao mesmo ponto. O Google lançou um modelo feito para caçar vulnerabilidades. A Anthropic publicou cadeias de exploits de um modelo que ainda não lançou. A OpenAI disse que seus próprios agentes encontraram uma brecha em uma biblioteca de compressão amplamente usada. E a linguagem web mais comum do mundo precisou de patches de emergência. Aqui está como tudo isso se encaixa, quem sai na frente e o que o dono de um site pequeno pode fazer antes do almoço.
Os bugs do PHP eram antigos. O que mudou é quem consegue usá-los
As duas falhas se chamam PHP2Shell, rastreadas como CVE-2026-109618 e CVE-2026-109619. Elas permitem que alguém sem senha execute código em um servidor pela internet e estão presentes em todas as versões do PHP desde a versão 5, lançada em 2004 (TechCrunch). O PHP está por trás de cerca de 70% dos sites voltados para a web, incluindo WordPress, Drupal, Joomla e MediaWiki.
Ninguém tinha conseguido explorá-las. A PHP Foundation viu os bugs em 2024 e os deixou sem correção porque não havia um jeito prático de explorá-los (TechCrunch). No início deste ano, pesquisadores da Calif descobriram como explorá-las, com a ajuda de um modelo de IA, dentro do programa de segurança open source da OpenAI e da Wiz. Um dos apresentadores do podcast do TechCrunch disse primeiro que modelos de IA encontraram as brechas, e depois corrigiu no relatório: pesquisadores humanos as encontraram e usaram IA para explorar o bug (TechCrunch).
Para nós, essa correção é o fato mais útil de toda a saga. Modelos identificarem bugs é a mudança menor. A maior é que bugs arquivados como "teóricos" se tornam reais quando um modelo consegue adaptar um exploit a diferentes configurações. A Wiz resumiu assim em seu próprio post, citada pelo TechCrunch: "Com a IA, isso não é mais uma barreira. LLMs podem ajudar a adaptar um exploit a diferentes versões do PHP, configurações e layouts de memória."
Os patches saíram nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, depois que grandes provedores de hospedagem e empresas de nuvem tiveram acesso antecipado sob embargo. A NSA então orientou os donos de site que tudo o que não pudesse ser corrigido imediatamente deveria sair da internet, e bancos, varejistas, hospitais e alguns órgãos do governo fizeram exatamente isso (TechCrunch).
Os ataques começaram antes do patch
A Amazon disse que seus honeypots registraram uma tentativa contra as duas falhas quatro dias antes da divulgação. A Cloudflare relatou tentativas subindo de dezenas de milhares em 45 minutos após o anúncio para milhões na manhã seguinte (The Hacker News). A PHP Foundation culpou uma empresa por ter colocado patches no ar horas antes do fim do embargo. Isso não explica atividade dias antes, e, até onde vai a cobertura que lemos, ninguém disse como o atacante pioneiro ficou sabendo.
Depois os ataques ficaram específicos. A empresa de segurança Dream rastreou um suspeito operador ligado à China que encadeou o PHP2Shell com uma falha do kernel do Linux e obteve root em 25 servidores, três deles dentro de uma rede afiliada ao governo dos EUA. Os alvos eram appliances de firewall rodando PHP 8.0.30. "A implementação que recuperamos é uma build personalizada e não pública, não uma cópia de nenhum exploit público conhecido para o PHP2Shell", disseram os pesquisadores da Dream (The Hacker News). Eles também encontraram o Claude Code instalado na infraestrutura do atacante, junto com uma ferramenta de segurança ofensiva conectada a modelos DeepSeek e Kimi, o que indica ajuda de IA na construção das ferramentas. A atribuição aqui é a leitura da Dream, não uma conclusão estabelecida.
A CISA confirmou exploração ativa cinco dias após os patches e adicionou as duas falhas ao seu catálogo de Vulnerabilidades Conhecidas Exploradas, dando três dias para as agências federais civis corrigirem seus sistemas (TechCrunch). Mais uma ressalva honesta: alguns pesquisadores dizem que construir um exploit confiável foi mais difícil do que se temia, e as primeiras tentativas de instalar uma variante da botnet Mirai até agora falharam (The Hacker News).
O Google criou o scanner que todo mundo quer, e a maioria de nós não pode usá-lo
O Google anunciou o Gemini 4 Carbon enquanto a limpeza do PHP se arrastava, chamando-o de seu modelo mais forte, com "capacidades de cibersegurança e de longo horizonte de última geração" (Google). A empresa diz que o Carbon marca 88,2% no SEC-bench Pro para encontrar vulnerabilidades reais, 54,8% no ExploitGym para explorá-las e 71,0% no CWE-bench para escrever a correção. Também afirma que a equipe do Chrome achou o Carbon mais de 10 vezes melhor do que o modelo de ponta de outro laboratório na produção de patches de alta qualidade. A Wiz, que pertence ao Google, informa que o Carbon lidera seus benchmarks de testes de intrusão web.
Esses são números do Google, obtidos sem guardrails, e os três benchmarks medem coisas diferentes, então não subtraia um do outro. O que chama atenção é que a correção de falhas esteja no placar. O The Verge observa que o Carbon superou o GPT-6 Astra no SEC-bench Pro e lidera um índice de inteligência independente, com o Claude Opus 5.5 atrás (The Verge).
Agora a pegadinha. O Carbon está aberto apenas a um subconjunto de defensores cibernéticos, com ampliação via Fairwind Program do Google, enquanto a empresa coleta feedback sobre guardrails e passa pelos testes voluntários de pré-lançamento do governo dos EUA. Ela promete acesso a desenvolvedores e empresas "o mais rápido possível", sem data. O preço de lançamento é US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída, e a nota de rodapé do Google diz que sobe para US$ 4 e US$ 20 após o período introdutório.
Anthropic e OpenAI estão defendendo o mesmo argumento
O Frontier Red Team da Anthropic publicou cinco cadeias de exploits de um modelo de pesquisa interno e não lançado, cobrindo Chrome, Safari, Android, Windows e Linux. A cadeia do Chrome encadeou quatro falhas e terminou com código rodando fora do sandbox do navegador. A do Linux deu um shell root pela rede, sem login. A Anthropic diz que reportou cada falha ao fornecedor antes. Só para o Chrome, diz que 62 CVEs foram atribuídos e corrigidos, todos classificados como críticos ou altos, 13 deles fugas de sandbox (Anthropic). O motivo declarado para publicar: "Agora, é algo que os modelos conseguem fazer com pouco envolvimento humano, e depois provar produzindo um exploit funcional que qualquer um pode executar e verificar."
Trate isso como uma alegação, que é como o The Hacker News tratou. Apple e Google dão crédito a pesquisadores da Anthropic, trabalhando com o Claude, por correções específicas, e essa parte dá para verificar. Quanto de cada cadeia o modelo construiu sozinho, não dá, já que a Anthropic não detalha o que uma pessoa fez em cada etapa. O The Hacker News também descobriu que dois dos registros públicos de CVE não descrevem as falhas exatamente como o post da Anthropic. O acesso para profissionais de segurança verificados passa pelo Cyber Verification Program, que cobre o Claude Opus entre outros modelos.
A versão da OpenAI, segundo a Reuters, veio com uma confissão. Depois que um modelo de pesquisa usou um erro de configuração para chegar à internet no início do ano, a empresa pausou seu treinamento mais avançado, reforçou a segurança e o retomou quando os novos controles estavam em vigor. Para testar as novas defesas, soltou equipes de agentes de IA para tentar escapar. Eles encontraram uma falha no Brotli, uma biblioteca de compressão usada por Node.js, Bun e Envoy. O detalhe ao qual voltamos o tempo todo: a OpenAI diz que a causa raiz foi corrigida no código-fonte do Brotli meses antes, antes de alguém saber que era uma vulnerabilidade, e nenhuma nova versão foi lançada. Existiu uma correção por meses. Nenhum release a levou até a OpenAI divulgar a falha.
O post de lançamento da OpenAI para o programa Patch the Planet, feito com a Trail of Bits, explica por que humanos continuam no processo. Os modelos de ponta, diz o texto, "produzem um alto volume de falsos positivos que podem aumentar o já esmagador backlog que os mantenedores enfrentam", então a Trail of Bits revisou cada achado antes que um mantenedor o visse (OpenAI). O programa usa o Codex Security e já levantou centenas de problemas em 19 projetos.
Encontrar ficou barato. Corrigir, não
O descompasso cabe em uma imagem. Tudo na linha de cima já roda na velocidade das máquinas. Tudo na linha de baixo ainda precisa de uma pessoa com agenda.
Comece pelas pessoas na parte de baixo. O TechCrunch observa que mantenedores de open source muitas vezes não são remunerados e não têm como pagar revisões de segurança de terceiros, enquanto as empresas que dependem do trabalho deles muitas vezes não contribuem (TechCrunch). As regras de divulgação também foram pensadas para tempos mais lentos. A política da Anthropic dá 90 dias para os desenvolvedores corrigirem, mais 45 antes de os detalhes serem discutidos além de um aviso. O PHP2Shell teve tentativas quatro dias antes da divulgação e ataques confirmados cinco dias após a correção.
Sean O'Kane disse no podcast Equity do TechCrunch que, no "nível dos ossos da internet", tudo é "mantido com cola e sonhos" (TechCrunch). O CTO de gestão de exposição e segurança de aplicações da Wiz, Tomer Schwartz, participou do mesmo programa para argumentar que corrigir na mão não vai escalar (TechCrunch). Concordamos mais com o segundo ponto do que com o primeiro.
Quem ganha, quem fica exposto
| Grupo | Por quê |
|---|---|
| Grandes hosts e plataformas de nuvem | Recebem patches sob embargo. A Wiz agradeceu Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft e Vercel pela ajuda no PHP, segundo o TechCrunch. |
| Equipes com acesso a scanners | Acesso antecipado a modelos como o Carbon e ao programa da Anthropic transforma um backlog em uma lista priorizada. |
| Desenvolvedores solo e pequenas equipes de TI | O TechCrunch espera que atualizem mais devagar, e eles têm a menor folga. |
| Appliances e stacks antigos | Firewalls, roteadores e storages embarcam PHP. As vítimas da Dream rodavam PHP 8.0.30, uma branch sem suporte. |
| Sites cheios de plugins | Nossa leitura, não uma conclusão da cobertura: cada plugin é mais um mantenedor que pode ou não lançar uma correção logo. |
Nossa opinião: não compre uma nova suíte de segurança por causa dessa notícia. As pessoas prejudicadas nessas histórias não estavam sem um produto. Elas rodavam uma branch do PHP sem suporte, ou esperavam por um fornecedor sem data de patch, ou não tinham ninguém que lesse o aviso. As defesas mais baratas são as chatas, e a que mais compensa é saber em uma hora se um determinado aviso se aplica a você.
Se você tem um site, faça isto primeiro
Colocaríamos uma pergunta antes de todas as outras: qual versão do PHP meu site usa e quem aplica os patches? A maioria dos donos de sites pequenos não sabe responder sem perguntar a alguém. Depois, siga esta lista.
- Descubra sua versão do PHP no painel da hospedagem ou pergunte ao seu host. As branches com suporte receberam correções nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e o TechCrunch diz que a 8.1 e as anteriores não recebem mais patches.
- No WordPress, a posição oficial do CMS é que isso não é uma falha do WordPress. Você corrige o servidor e trabalha com seu host, então mande um e-mail e peça uma resposta por escrito.
- Se não puder aplicar o patch agora, tire o site do ar até conseguir. Essa é a orientação da NSA, e é difícil discordar quando a alternativa é um servidor com root comprometido.
- Defina
session.upload_progress.enabled=0se você puder viver sem barras de progresso de upload. O PHP listou isso como mitigação para o CVE-2026-109619 e de novo para um terceiro aviso, de menor risco, o CVE-2026-115560, que ainda não tem correção de emergência (The Hacker News). - Depois de aplicar o patch, verifique os logs em busca de exploração a partir de pelo menos uma semana antes de as correções saírem, já que os honeypots da Amazon registraram uma tentativa quatro dias antes da divulgação.
- Liste todas as máquinas da sua rede que possam rodar PHP nos bastidores, como um firewall ou um NAS, e peça a cada fornecedor a data do patch.
Se você escreve software em vez de hospedá-lo, não espere pelo Carbon. Os scanners que você pode usar hoje estão no nosso texto sobre o que os scanners de vulnerabilidades com IA encontram e deixam passar, e o post sobre as melhores ferramentas de code review com IA compara revisores como CodeRabbit e Snyk Code. Reserve tempo para a triagem, porque a primeira execução gera uma pilha de resultados, e o próprio programa da OpenAI explica o motivo. Todos os rankings ToolRank de ferramentas de cibersegurança com IA e o ranking de code review e testes são os lugares para comparar opções, e ferramentas de IA para analistas de segurança cobre quem faz esse trabalho em tempo integral.
Pontue-se abaixo. Menos de cinco pontos significa que sua primeira hora deve ir para os itens de dois pontos.
O que estamos acompanhando
Três coisas. Se o Google vai abrir o Carbon além dos parceiros do Fairwind, e a que preço quando acabar a tarifa introdutória. Se a Anthropic vai nomear ou lançar o modelo por trás de suas cadeias, já que uma capacidade que só algumas equipes verificadas têm não está igualmente nas mãos de defensores e atacantes. E como o primeiro atacante do PHP2Shell soube a tempo, o que ainda não tem resposta.
A próxima correção a observar é o terceiro aviso do PHP, o CVE-2026-115560, que o PHP diz que chega no próximo release de rotina. Leia as notas no dia em que sair e confira de novo a versão do seu site.