Do spam de IA ao PHP2Shell
A 21 de outubro, o PHP lançou correções de emergência para duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, a que se chamou PHP2Shell. Permitiam a um atacante, sem qualquer autenticação, executar código no servidor. O PHP corre em cerca de 75% dos sites cuja linguagem se consegue identificar, e o caminho mais antigo afetado remonta ao PHP 5.4, de 2012. Agências governamentais nos Países Baixos, na Finlândia e na Austrália tiraram sites do ar por precaução.
Em termos simples, um pedido preparado para o efeito faz o PHP ficar sem memória, ou dar um erro fatal, a meio do seu processamento. Ao limpar esse pedido, o PHP usa memória que já não é válida, e daí se chega à execução de código. O que acontece na prática é que um site com uma versão do PHP por corrigir pode ser controlado à distância por um atacante, sem palavra-passe nenhuma. A partir daí, o atacante pode ler ou alterar os dados a que o site tem acesso e correr os seus próprios programas no servidor.
O PHP2Shell não é caso único. Também a 21 de outubro, o Node.js corrigiu o Node2Shell, uma falha no Brotli, o descodificador que trata dados comprimidos, que também podia permitir executar código à distância. Em maio soube-se de uma vulnerabilidade com 18 anos no NGINX, o servidor web de um terço dos sites mais visitados, encontrada por um sistema autónomo de IA. Em janeiro, a AISLE disse ter encontrado as 12 falhas de uma ronda de correções do OpenSSL, a biblioteca que protege grande parte das ligações na internet, em código que em alguns casos remonta a 1998.
O PHP2Shell foi encontrado com IA. A PHP Foundation conta que a Calif começou a auditar o PHP a 30 de julho e reportou a falha a 11 de agosto, que a OpenAI reportou a mesma causa-raiz de forma independente, e que a Wiz acrescentou outros vetores de ataque a 24 de agosto. Segundo a Calif, foram os humanos a escolher o alvo e a dar a teoria, e foi um agente a ler o código e a apontar a falha.
Do spam às descobertas
Em 2024, a IA prometia criar disrupção na maneira como os developers faziam código. A opinião geral era que a internet iria ficar repleta de código fraco e cheia de vulnerabilidades.
Em 2025, a IA prometia encontrar vulnerabilidades a escalas sem precedentes. O que sucedeu foi a criação de spam em magnitude incomportável, levando projetos como o curl a desligar a sua bug bounty no início de 2026, tal era o volume de ruído.
Em finais de 2026, a IA continua a gerar spam em grande escala, mas no meio desse spam existe uma quantidade de vulnerabilidades de segurança de tal modo substancial que já ninguém se pode desmarcar de passar pelo trabalho de filtrar o spam para encontrar o valor no meio. Em abril, o principal programador do curl escrevia que o desafio tinha passado de um "tsunami de slop de IA" para um "tsunami de relatórios de segurança": "Muitos deles realmente bons."
De janeiro a outubro de 2025, a base de dados de segurança do GitHub publicou cerca de 3 mil vulnerabilidades revistas. No mesmo período de 2026 foram mais de 12 mil, e as críticas, nos primeiros nove meses do ano, passaram de 281 para 1221. Em maio, o GitHub publicou mais de 1500, o máximo da sua história e mais de cinco vezes o normal. No registo público de vulnerabilidades contaram-se 48 150 em todo o ano de 2025, e já vão mais de 93 mil em 2026. Estes números não dizem quanto disto veio da IA, mas é evidente que estes aumentos se devem à instrumentalização de IA para descoberta de vulnerabilidades em maior escala.
Dados: GitHub Advisory Database.
Aquilo que vemos na Immunefi confirma-o. Em 2023, nenhum relatório feito com o ChatGPT trazia coisas reais. Era tudo spam, e a utilização de IA era vista como uma coisa a banir. Em 2026, o número de relatórios aumentou significativamente, e posso dizer que a esmagadora maioria faz uso de IA, para não dizer que quase 100% da escrita é feita por IA. Em agosto de 2026, a Immunefi registou 424 relatórios válidos, contra 154 um ano antes, e as falhas críticas confirmadas passaram de 14 para 126. Hoje em dia somos uma plataforma que dá as boas-vindas a todos os agentes que queiram ajudar os nossos clientes a ficar mais seguros, porque é evidente para nós que a indústria caminha para aí.
Dados: Immunefi.
A IA também ajuda a encontrar os bugs, não só a escrever relatórios. Antes, os investigadores reportavam vulnerabilidades em certos projetos e possivelmente demoravam semanas ou meses a passar para outro cliente. Hoje, investigadores avançados reportam vários bugs em diferentes clientes na mesma semana. Esta descoberta de vulnerabilidades em escala só é possível graças aos agentes mais recentes.
Quase todos os investigadores usam os mesmos modelos. Quando um modelo novo é lançado, as mesmas novas vulnerabilidades são descobertas. É certo que há uma arte na utilização destes agentes para procurar falhas de segurança, e por este motivo vemos investigadores a terem mais sucesso que outros. Mas a densidade de duplicados tem efetivamente aumentado substancialmente. Numa competição de auditoria na Immunefi, a da Quantus, 77 dos 143 relatórios válidos eram duplicados, e um bug de severidade alta foi reportado 25 vezes. O PHP2Shell seguiu o mesmo padrão, com a Calif e a OpenAI a chegarem à mesma causa-raiz.
O que os humanos deixaram passar
Pragmaticamente falando, os humanos falharam. Não é novidade. A falha de memória na origem do PHP2Shell já tinha sido reportada em 2020, como um bug aparentemente inofensivo. Em 2024, numa auditoria externa, um programador do core do PHP viu os primeiros sinais do problema. Foi teorizada uma exploração, mas sem vetores concretos, e a correção arrastou-se durante meses. A própria PHP Foundation chama a esse atraso uma "falha estrutural", causada pelo processo de decisão da equipa de segurança e pela falta de recursos.
Apesar de ser código vastamente usado em metade da internet, a descoberta de problemas de segurança depende dos incentivos que sejam postos para que tais sistemas permaneçam seguros e se tornem cada vez mais robustos. Estes softwares são públicos, portanto não é que exista propriamente uma empresa bilionária responsável por garantir que tal software seja continuamente fortalecido. A PHP Foundation tem uma única funcionária a tempo inteiro e 14 contratados, quase todos a tempo parcial. O Node.js suspendeu o seu programa de recompensas quando acabou o financiamento do Internet Bug Bounty.
Cada empresa que use estes softwares trata de estabelecer proteções próprias, se é que o fazem, para procurar que uma vulnerabilidade numa dependência não lhes seja letal, e que tal dependência seja rapidamente atualizada com qualquer correção que seja feita a montante.
Ainda na infância
Tudo isto é muito novo. As vulnerabilidades são descobertas e tornadas públicas, e as empresas mal conseguem manter o ritmo para atualizar as dependências e manter-se seguras. Até 22 de maio, o Project Glasswing, da Anthropic, tinha comunicado 1596 falhas a 281 projetos open source, e só 97 estavam confirmadas como corrigidas. A Amazon registou a primeira tentativa de exploração do PHP2Shell a 17 de outubro, quatro dias antes da correção. A correção do Node2Shell esteve oito meses à vista de todos no repositório público do Brotli, sem nova versão e sem aviso.
Dados: Cloud Security Alliance.
O problema de cibersegurança sempre foi que, no geral, a cibersegurança de uma empresa não é o core do seu negócio, e é normal que assim seja. As empresas estão focadas, naturalmente, naquilo que as faz crescer e bem servir os seus clientes. Daqui sucede que não haja todo o tempo e recursos do mundo para que algumas empresas parem o que estão a fazer e se dediquem continuamente à correção de vulnerabilidades.
Trata-se de um problema que está ainda na sua infância, e só irá piorar. Os bugs velhos podem esgotar-se, se bem que existe muito código por onde descobrir problemas, mas novo código chega, e a velocidades estonteantes. Tornar-se-á cada vez mais necessário que as empresas arranjem parceiros dedicados a ajudá-las a manter-se protegidas. Mas será que haverá orçamento para isso?