PHP2Shell não será a última. Veja onde a próxima vai aparecer primeiro.

Em 17 de outubro, a rede de honeypots da Amazon registrou uma tentativa de exploração do PHP2Shell vinda de um endereço IP anonimizado. No entanto, a divulgação pública só aconteceria quatro dias depois.

Quando o PHP publicou as correções, em 21 de outubro, os detalhes técnicos já haviam vazado, as provas de conceito de exploração circulavam amplamente e novas tentativas eram registradas por toda parte. O problema eram duas vulnerabilidades críticas de execução remota de código sem autenticação no próprio mecanismo do PHP (CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 9.2) — o que hoje conhecemos como PHP2Shell.

Nossa equipe de pesquisa de segurança analisou o que aconteceu e o que você deve fazer: para quais versões migrar, quais medidas de mitigação você poderia adotar para reduzir a exposição até conseguir atualizar e onde cada parte da plataforma Snyk detecta o problema.

Esta publicação retoma o assunto de onde nossa equipe de pesquisa de segurança parou. Queremos falar sobre o que essa resposta nos ensinou: onde esse tipo de exposição existe e de onde vem, por que responder rápido depende do trabalho feito meses antes e por que a próxima vulnerabilidade já está a caminho.

Por que o PHP2Shell foi um problema para equipes com código limpo?

Porque as vulnerabilidades estão abaixo do código. E o que isso significa? As duas CVEs mencionadas ocorrem no ciclo de vida das requisições do mecanismo do PHP, o que as torna acessíveis antes mesmo de qualquer código da aplicação ser executado. No Apache, com mod_php, bastava uma única requisição sem autenticação para explorar a vulnerabilidade.

Agora, pense nisso por um instante. Você provavelmente tinha revisões cuidadosas, código limpo e uma árvore de dependências organizada — tudo acima do problema real. A primeira pergunta para cada equipe era onde o PHP estava respondendo às requisições e se alguém poderia explorá-lo naquele exato momento.

A pergunta era sobre aplicações em execução. É exatamente por aí que os invasores sempre começam.

Qual inventário mostra onde o PHP está em execução?

Cada tipo de inventário mostra uma parte do cenário.

O PHP chega à produção por meio de um Dockerfile, um pacote de distribuição, uma imagem de plataforma ou uma instalação manual. Uma restrição "php": ">=8.2" no composer.json informa quais versões a aplicação aceita, mas a versão implantada depende de qual desses caminhos foi usado para instalá-la. As verificações de contêiner detectam o PHP instalado por pacotes de distribuição assim que cada distribuição publica um aviso de segurança. Já o PHP compilado a partir do código-fonte, incluindo as imagens oficiais do PHP para Docker, fica fora dessa análise. (Mais uma vez, a publicação da nossa equipe de pesquisa mostra exatamente qual visão da Snyk detecta cada parte desse cenário.)

E há também a string de versão. O VirusTotal identifica a impressão digital de cerca de 5,1 milhões de endereços IP que executam PHP, mas apenas cerca de 1,1 milhão informa uma versão — ou seja, aproximadamente quatro em cada cinco a ocultam. O resumo deles traz uma das frases mais precisas que já lemos sobre o assunto: "Se você procurar apenas uma string de versão, verá somente a parte do problema que a revela por conta própria."

A lacuna entre o que suas ferramentas de análise de dentro para fora conhecem e o que realmente responde do lado de fora é onde mora o risco real. Os invasores acessam sua URL, e o PHP2Shell é o exemplo mais claro disso que já vimos. Quem procura essa vulnerabilidade acaba fazendo a mesma pergunta: o PHP responde nesta URL?

Como foi a resposta vista de fora para dentro?

A vantagem inicial: antes do lançamento do PHP, às 14h UTC de 21 de outubro, a Snyk já tinha publicado avisos para as duas CVEs. Assim, os projetos monitorados seriam alertados assim que as versões corrigidas fossem conhecidas. Em cerca de 30 minutos após o lançamento, os avisos já incluíam os intervalos afetados e as versões corrigidas. Os avisos das distribuições foram publicados à medida que cada uma divulgava os seus. Isso cobriu o que as verificações do Snyk Container e as verificações de software não gerenciado podiam detectar.

Três perguntas orientaram o Snyk API & Web:

1. Onde o PHP está em execução? O Discovery enumera os ativos nos seus domínios e identifica as tecnologias da pilha. Defina o filtro de tecnologia como PHP para ver todos os hosts e endpoints descobertos nos quais o PHP foi identificado, com classificação e pontuação de risco, além da data da última detecção. Os números de versão vêm depois, diretamente dos hosts. Como disse nossa equipe de pesquisa, antes de corrigir, você precisa ter a lista.

2. Alguém consegue explorar a vulnerabilidade? Em até 24 horas após o lançamento do PHP, o perfil completo de verificação já testava o PHP2Shell. As equipes também podiam executar essa verificação por conta própria, usando um perfil personalizado, para obter uma resposta rápida em todos os alvos com PHP.

3. A correção funcionou? Após aplicar o patch, execute novamente o mesmo perfil personalizado e confira também o aviso de segurança ou o nível do patch da sua distribuição, pois uma versão corrigida da distribuição pode continuar exibindo um número de versão antigo.

Então, descoberta --> verificação direcionada --> aplicação do patch --> nova verificação: sondar, observar e deduzir, contra um relógio que agora conta em horas. E essa é justamente a parte mais preocupante, a que mais importa para nós. Para as equipes que já usavam o Snyk API & Web, o trabalho difícil estava feito antes de 21 de outubro: os domínios estavam mapeados e as aplicações configuradas como alvos. Quando a verificação ficou disponível, bastaram um filtro e uma análise rápida para responder.

Para nós, esse é um dos principais benefícios dos testes contínuos de fora para dentro: o trabalho que permite responder no primeiro dia é feito meses antes.

Se é possível detectar o PHP2Shell de fora, qual foi a parte difícil?

O tempo.

Em maio, explicamos a distinção que fundamenta o COS. Vulnerabilidades detectáveis por heurística se revelam a ferramentas determinísticas: envie payloads a uma aplicação ou API em execução, observe as respostas e deduza. Vulnerabilidades que dependem do contexto (BOLA, vazamento entre locatários e cadeias de lógica de negócios) não têm assinatura alguma, pois existem na lacuna entre o que uma aplicação deveria fazer e o que realmente faz.

Depois de ser descoberta, a vulnerabilidade PHP2Shell pôde ser testada de fora, o que a coloca claramente na primeira categoria: vulnerabilidades detectáveis por heurística. A parte difícil, a limitação, era o intervalo entre a divulgação e a execução de uma verificação em tudo o que você expõe. Esse intervalo é a janela de exploração dos invasores e, desta vez, ela se abriu quatro dias antes da divulgação oficial.

E a divulgação continuou evoluindo. Em 23 de outubro, o projeto PHP descreveu um bypass parcial (CVE-2026-115560), aplicável quando uma aplicação troca o manipulador de serialização de sessão com ini_set() antes de iniciar a sessão, com o progresso do upload habilitado. As condições necessárias são raras, mas o que você concluiu na quarta-feira ainda precisava ser revisto na sexta-feira. Uma resposta obtida em um único momento fica desatualizada em poucos dias.

Por que o PHP2Shell não será a última vulnerabilidade?

Há três motivos, relacionados à forma como essas vulnerabilidades foram encontradas:

1. Porque foram encontradas com ajuda de IA, em um mecanismo que atende à Web há três décadas. Nossa equipe de pesquisa resumiu bem: "Em um mundo de LLMs e agentes, todo mundo continua usando servidores." E o tipo de modelo que encontrou essas vulnerabilidades é o mesmo que os invasores têm agora à disposição.

2. O ritmo mais acelerado. Manoj Nair, CTO e diretor de inovação da Snyk, descreveu esse cenário em setembro: "O tipo de falha grave que a IA agora encontra em softwares amplamente utilizados — aquela descoberta que antes surgia uma ou duas vezes por ano e redefinia o trimestre de todo mundo — está aparecendo várias vezes por semana, pelo que tenho visto."

3. O relógio está correndo muito mais rápido. CJ Moses, CISO da Amazon Integrated Security, apontou duas lições do PHP2Shell que vão muito além dessa vulnerabilidade. Os defensores "não devem presumir que a data da divulgação pública é a primeira data em que a vulnerabilidade foi explorada." E "o tempo entre a aplicação do patch e a criação de um exploit funcional está diminuindo por razões estruturais," porque a análise assistida por IA facilita transformar a diferença entre versões de um patch ou um aviso de segurança em um exploit funcional. Seu conselho para vulnerabilidades críticas em sistemas expostos à internet: "meça os prazos para aplicar patches e implementar mitigações em horas."

O que é preciso para estar preparado para a próxima vulnerabilidade?

Deixando os nomes dos produtos de lado, tudo se resume a quatro características. Avalie qualquer abordagem com base nelas, inclusive a nossa. Não pense nos nomes dos produtos, mas nessas quatro características — e use-as para avaliar qualquer abordagem, inclusive a nossa.

1. Um inventário disponível antes da publicação do aviso. Criado de fora para dentro e mantido atualizado, para que uma nova divulgação comece com um filtro.

2. Verificações disponíveis em poucas horas. O intervalo entre a publicação do aviso e a execução de um teste é a janela de exploração dos invasores. Meça esse tempo.

3. Novas verificações sob demanda. Execute a mesma verificação direcionada repetidamente até confirmar que a correção funcionou.

4. Testes que não dependem de uma assinatura. As heurísticas detectam o que já foi descrito. Todo o resto exige raciocínio: testes que determinam o que a aplicação deveria fazer e investigam a lacuna entre isso e o que ela realmente faz.

Veja como isso se traduz no que oferecemos na Snyk.

O Snyk API & Web cobre os três primeiros pontos: descoberta, um mecanismo que a equipe mantém atualizado conforme as vulnerabilidades são divulgadas e perfis direcionados que você pode executar e repetir. O Evo Continuous Offensive Security acrescenta o quarto: o AI Pentesting analisa sua aplicação como faria um pentester; o Agent Red Teaming entra em ação assim que o reconhecimento identifica um LLM na pilha; e o Dynamic Testing, mecanismo do Snyk API & Web, cobre continuamente as categorias detectáveis por heurística. Nos termos da nossa plataforma, isso é Validate: atacar continuamente suas aplicações para comprovar que as correções funcionaram e revelar o que ainda pode ser explorado.

E há também a postura de segurança. No evento The AI Security Panel: Unfiltered, em 14 de outubro, Manoj fez a pergunta à qual sempre voltamos: "Se um invasor autônomo vai atacar você, por que não atacar a si mesmo?" Essa pergunta é a premissa central do COS. Do nosso lado, o trabalho é reduzir cada intervalo desta história: entre a publicação do aviso e a execução da verificação, e entre a verificação e a confirmação da correção.

Onde a próxima vulnerabilidade vai aparecer primeiro?

Qual mecanismo será afetado e quando, ninguém sabe. Mas é mais fácil prever onde ela vai aparecer primeiro: na sua URL. É ali que seus testes já devem estar acontecendo.

Quer ver o que um invasor encontraria hoje na sua URL? Agende uma demonstração do Evo Continuous Offensive Security e veja como ele mapeia sua superfície de ataque de fora para dentro, comprova quais descobertas podem ser exploradas e repete os testes até confirmar que a correção funcionou.