PHP2Shell: Uma vulnerabilidade antiga, uma emergência global e o que fazer agora.
Uma falha de memória foi detectada pela primeira vez no PHP em 2024. Passaram-se dois anos sem que o problema fosse resolvido. Em seguida, pesquisas com auxílio de IA transformaram isso em uma exploração funcional. Agora, mais de 22,6 milhões de instâncias expostas à internet estão potencialmente em risco. Atualmente, os atacantes estão sondando servidores vulneráveis e sites públicos em toda a Europa saíram do ar enquanto as equipes trabalham para corrigir as falhas.
A confusão remonta a duas falhas críticas no PHP, conhecidas em conjunto como PHP2Shell. Em 21 de outubro, os desenvolvedores do PHP lançaram correções para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, cada uma classificada com 9,2 de 10 em termos de gravidade. O PHP é utilizado em aproximadamente 70% dos sites que usam uma linguagem de programação do lado do servidorconhecida, incluindo sites construídos em WordPress, Drupal e Joomla. E como as falhas estão no próprio PHP, e não em um plugin ou aplicativo, os invasores poderiam executar código malicioso sem precisar fazer login. A partir daí, eles poderiam assumir o controle de um servidor vulnerável ou extrair dados confidenciais diretamente de sua memória.
O PHP2Shell é mais do que um problema de aplicação de patches. A pesquisa assistida por IA pode transformar falhas antigas em exploits funcionais mais rapidamente do que as equipes conseguem testar e lançar correções. E um servidor web público comprometido pode dar aos invasores acesso a bancos de dados, aplicativos internos e cargas de trabalho na nuvem. O remendo deve vir acompanhado de um segundo plano: visualizar esses caminhos, limitar o movimento lateral e conter a violação de dados antes que ela se alastre.
“É quase como se alguém tivesse encontrado uma chave universal para todas as nossas portas de entrada”, disse Christer Swartz, diretor de soluções industriais da Illumio.
A corrida para remendar o vazamento começou com uma infiltração. Em 20 de outubro, os dois identificadores CVE começaram a circular online. O PHP antecipou seu lançamento em um dia. Naquela noite, a empresa de segurança Calif publicou por engano um vídeo de uma vulnerabilidade explorada em funcionamento. Cópias se espalharam pelas redes sociais. Na manhã seguinte, a Chainguard publicou imagens de software com a correção mais de seis horas antes do lançamento coordenado. Os atacantes conseguiam estudar a correção antes que a maioria das equipes tivesse a chance de aplicá-la.
As consequências afetaram rapidamente os serviços públicos. Agências governamentais, universidades e outros sites públicos em toda a Europa ficaram offline enquanto equipes se mobilizavam para corrigir os problemas. As agências de segurança solicitaram atualizações imediatas. A Cloudflare detectou tráfego de ataques contra seus clientes antes do lançamento das correções. A Amazon Ameaça Intelligence afirma ter detectado uma tentativa de exploração em 17 de outubro, quatro dias antes das falhas serem divulgadas publicamente. Agora, relata ampla exploração na natureza. Ainda não está claro quantas tentativas foram bem-sucedidas.
O aviso que ficou sem solução
A contagem regressiva começou muito antes de o público tomar conhecimento do PHP2Shell.
Em 2024, um desenvolvedor PHP encontrou os primeiros indícios do problema de memória enquanto corrigia uma questão diferente, identificada durante uma auditoria de segurança. A equipe avaliou diversas soluções. Cada uma delas apresentava o risco de quebrar a compatibilidade, criar novos riscos de negação de serviço ou forçar alterações em extensões de terceiros. Sem um método conhecido para execução remota de código, o trabalho ficou paralisado.
Então, as apostas mudaram.
Em agosto, uma pesquisa com auxílio de IA mostrou o que a falha poderia causar. Em 11 de agosto, pesquisadores da Universidade da Califórnia e da OpenAI relataram separadamente um caminho de execução remota de código com a mesma causa raiz. Dias depois, Wiz usou modelos de IA de ponta para encontrar mais caminhos de ataque. Sua equipe demonstrou ataques funcionais em sites WordPress, Drupal e Joomla. O bug agora servia como porta de entrada para um servidor web em funcionamento.
A equipe do PHP e os pesquisadores começaram a trabalhar em correções. O objetivo era dar aos proprietários dos terrenos tempo para se prepararem. Mas o plano desmoronou quando detalhes vazaram antes do lançamento.
O caminho do alerta à crise
- 2024: Ao corrigir uma constatação de auditoria, um desenvolvedor PHP identifica uma falha de memória. A solução está emperrada.
- Agosto de 2026: A Universidade da Califórnia, a OpenAI e a Wiz utilizam pesquisas assistidas por IA para demonstrar a execução remota de código.
- De agosto a outubro de 2026: os mantenedores e pesquisadores do PHP trabalham em uma correção para a versão de 22 de outubro.
- 17 de outubro: A Amazon detecta uma tentativa de exploração em um honeypot.
- 20 de outubro: Vazamento dos identificadores CVE. O PHP antecipou o lançamento em um dia. Calif publica vídeo de exploração por engano.
- 21 de outubro: Chainguard publica imagens corrigidas antecipadamente. O PHP lança atualizações de segurança à medida que sites ficam offline e as tentativas de exploração aumentam.
A Fundação PHP reconheceu posteriormente falhas na forma como lidou com o antigo aviso. O relato também mostra como é difícil manter uma correção em segredo depois que a evidência de uma vulnerabilidade se espalha. É necessário testar a correção. Os atacantes precisam apenas de um servidor que ainda não tenha sido atualizado.
Nem todos os sites PHP enfrentam o mesmo risco. O risco depende da versão em uso, da configuração do servidor e dos controles implementados. Mas a crise impôs um limite severo ao tempo que as equipes tinham para agir.
Um servidor web pode ser uma porta de entrada para a rede.
Pense em um portal do cliente. Pode conectar-se a um banco de dados para registros de contas, a uma API para pagamentos e a aplicativos em nuvem para outras tarefas. Esses links permitem que o site funcione. Elas também podem dar ao intruso uma rota de acesso à porta da frente.
Swartz alertou que um invasor que assume o controle de um servidor web pode seguir os caminhos que o aplicativo já utiliza.
“E se essa ameaça atingir um servidor web voltado para o cliente, e você não conseguir detectá-la, ela simplesmente começará a seguir os mesmos caminhos, cada vez mais fundo na sua rede, que você deixou abertos”, disse ele.
O atacante pode procurar por chaves de API ou tokens de login na memória do servidor. Wiz demonstrou que essas falhas podem vazar exatamente esse tipo de dado. O atacante também pode testar quais sistemas o servidor consegue alcançar. Se o acesso for muito amplo, uma única violação de dados poderá colocar em risco dados de clientes, aplicativos internos e ativos críticos.
Apenas o status da atualização não lhe dirá até onde isso pode chegar. As equipes também precisam saber o que um servidor pode acessar após ser invadido.
Isso inclui quaisquer ligações entre TI e tecnologia operacional (TO), onde um caminho mal protegido pode expor os sistemas da planta.
A IA mudou o ritmo da corrida.
A IA ajudou os pesquisadores a descobrir o risco. Isso deu aos defensores a chance de corrigir o problema. Mas as mesmas ferramentas podem ajudar os atacantes a encontrar brechas de acesso.
Swartz vê um novo problema para as equipes que dependem de respostas manuais.
"Eu diria que o que isso significa para a janela de vulnerabilidade é que ela agora é muito mais curta do que qualquer ser humano consegue reagir", disse ele. Ele foi mais direto sobre o custo do atraso: "Se você depende de uma pessoa... um ser humano digitando em um teclado, você perdeu."
O problema é a velocidade. Os analistas ainda precisam avaliar os riscos e investigar os ataques. Mas, quando alguém percebe uma conexão desconhecida e age de acordo com ela, o atacante pode já ter passado para outro alvo.
Como limitar os danos
1. Comece com os servidores expostos.
O primeiro passo é encontrar os servidores PHP afetados e aplicar as atualizações de segurança. Se um servidor público não puder ser atualizado, restringir o acesso ou desligá-lo do ar pode ser a opção mais segura.
Swartz classificaria o trabalho pela exposição, não apenas pelo número de servidores. Um site vinculado a um banco de dados sensível ou outro ativo crítico merece atenção especial.
“Você precisa aplicar patches, mas também precisa perguntar o que esse servidor consegue acessar”, disse ele. “Se estiver ligado a ativos críticos, o risco é muito maior do que a vulnerabilidade dessa máquina específica.” Para sites com balanceamento de carga, ele recomenda aplicar patches em um grupo de servidores enquanto os outros mantêm o site em funcionamento. Em seguida, as equipes podem alternar o tráfego e corrigir o restante.
2. Veja para onde um atacante poderia ir em seguida.
A próxima preocupação de Swartz são as conexões do servidor web com APIs, bancos de dados, aplicativos internos e cargas de trabalho na nuvem. Esses caminhos geralmente fazem sentido para o negócio. Elas também podem se tornar vias de movimento lateral.
“Se você não sabe com quais sistemas seu servidor web se comunica, você não sabe até onde um invasor pode chegar”, disse ele. “Mapeie essas conexões primeiro.” Assim, você poderá ver quais são necessárias e quais colocam em risco ativos críticos.”
3. Fique atento a mudanças no tráfego.
Ele também procuraria por tráfego que quebrasse o padrão normal de um servidor: novas conexões de carga de trabalho, destinos estranhos ou um aumento repentino no volume.
Ele citou o DNS como um exemplo. Um servidor que normalmente envia pequenas solicitações de DNS, mas começa a movimentar grandes quantidades de dados, pode precisar de uma análise mais detalhada. Não é um sinal específico do PHP2Shell e não comprova uma violação de dados. Para o PHP2Shell, Wiz sugere ficar atento a solicitações de upload incomuns seguidas por erros de limite de memória ou respostas HTTP 500 repetidas.
“Você pode não saber qual vulnerabilidade um invasor explorou”, disse ele. “Mas ainda é possível ver uma carga de trabalho fazendo algo que nunca fez antes.” Esse é o tipo de mudança que você precisa detectar antes que o ataque se espalhe.”
4. Elimine caminhos desnecessários
“A melhor prática, eu diria, é segmentar seus aplicativos independentemente dos segmentos subjacentes”, disse Swartz. Em outras palavras, defina controles para cada aplicativo, independentemente da rede em que ele esteja hospedado.
Ele argumenta que um firewall na borda da rede, uma VLAN ou um limite de rede em nuvem nem sempre controla o acesso entre aplicativos. A segmentação ao nível da carga de trabalho pode restringir cada servidor aos serviços de que necessita.
“Um servidor web pode precisar se comunicar com um banco de dados”, disse ele. “Isso não significa que deva ser capaz de alcançar todos os bancos de dados. Se o servidor for comprometido, esses limites podem impedir que o invasor o utilize como ponte para o resto da rede.”
5. Considere que a correção pode não ser a solução definitiva.
Swartz também alerta que uma atualização corrige uma vulnerabilidade, mas não impede que um invasor consiga acessar o sistema antes da correção. As equipes ainda precisam verificar registros, processos, tokens de acesso e novas conexões.
“Uma vez que um servidor tenha sido exposto, não presuma que a correção signifique que o problema está resolvido”, disse ele. “Procure sinais de que alguém entrou, verifique para onde foi e isole a carga de trabalho se encontrar uma ameaça.”
O objetivo, segundo ele, é conter a violação de dados sem interromper todos os serviços de que a empresa precisa.
Contenha o que você não conseguir corrigir a tempo.
O PHP2Shell coloca dois relógios em movimento. Uma ferramenta monitora quanto tempo as equipes precisam para testar e implementar uma atualização. A outra métrica monitora a rapidez com que um invasor consegue encontrar uma brecha.
Swartz comparou o PHP2Shell a uma chave universal para as portas da frente. As equipes nem sempre conseguem trocar as fechaduras antes que alguém tente usar a chave. Mas se eles conhecerem os caminhos entre as cargas de trabalho, limitarem o acesso e agirem rapidamente em caso de tráfego incomum, uma porta aberta não precisa abrir a casa toda.
Não deixe que uma única vulnerabilidade se transforme em uma violação de dados em toda a rede.
Os atacantes precisam apenas de um ponto de entrada para comprometer seu ambiente.
A Illumio ajuda você a detectar movimentos laterais suspeitos, conter ameaças e impedir que invasores transformem uma única vulnerabilidade em uma violação de dados.
.webp)
