A infraestrutura global da web enfrentou um cenário de alerta máximo com a descoberta de três vulnerabilidades de execução remota de código (RCE) no núcleo do PHP. As duas primeiras falhas, rastreadas como CVE-2026-109618 e CVE-2026-109619 e batizadas coletivamente como PHP2Shell, atingiram a pontuação 9.2 no sistema CVSS e desencadearam uma corrida contra o tempo para a aplicação de correções. Horas após o anúncio, códigos de exploração de prova de conceito (PoC) tornaram-se públicos, resultando em uma onda de varreduras automatizadas por toda a internet.
Apesar do cenário alarmante e do volume massivo de tentativas de invasão, a realidade da exploração provou ser muito diferente da teoria. Dados consolidados pela equipe de pesquisa Counter Threat Unit (CTU) da Sophos revelam que a complexidade da arquitetura do PHP tem atuado como uma barreira intransponível para os invasores. Os ataques documentados até o momento, majoritariamente orquestrados para instalar uma variante da botnet Mirai conhecida como Potassium, falharam em comprometer os servidores alvo, sendo interceptados por contramedidas de rede ou esbarrando em dependências de configuração.
O episódio expõe não apenas o ciclo de vida de uma vulnerabilidade crítica desde a sua descoberta até a tentativa de armamento por cibercriminosos, mas também lança luz sobre o gerenciamento de memória do PHP, o comportamento de botnets modernas e os desafios de manter sistemas legados em produção.
A anatomia do PHP2Shell e o gerenciamento de memória
Para compreender a gravidade teórica do PHP2Shell, é necessário observar como o PHP gerencia seu ciclo de vida de requisições e a alocação de memória. O PHP opera sob um modelo onde cada requisição web inicia um estado limpo, alocando memória para variáveis e estruturas internas, e teoricamente liberando todos esses recursos ao final do processamento (ciclo de request startup e shutdown).
A vulnerabilidade CVE-2026-109618 expõe uma falha crítica nesse mecanismo de limpeza, especificamente durante condições de esgotamento de recursos. Quando um servidor atinge o limite de memória alocada (Out-Of-Memory, ou OOM), o motor interno do PHP tenta abortar a operação e limpar o estado da requisição. No entanto, a falha permite que o processo de descarte falhe em neutralizar ou zerar completamente os ponteiros de memória. O resultado é que o sistema passa a interpretar dados residuais e não inicializados da requisição maliciosa como estruturas válidas. Invasores utilizam requisições POST com payloads anormalmente grandes (frequentemente usando limites de multipart boundaries extensos, como a string “B7kQpoc618” observada nos ataques) para forçar intencionalmente esse estado de OOM.
A CVE-2026-109619 atua de forma complementar, afetando o estado global interno da aplicação. O erro fundamental reside no fato de que o estado de uma requisição pode sobreviver na memória mesmo após a função responsável por sua liberação ter sido executada. Isso cria uma condição clássica de uso após liberação (Use-After-Free). Uma requisição subsequente consegue acessar, ler ou até mesmo sobrescrever esses dados antes que o ambiente do PHP seja completamente redefinido. A combinação dessas duas vulnerabilidades permite que um invasor injete código arbitrário diretamente na memória do processo e force a sua execução, burlando completamente os mecanismos de autenticação da aplicação web.
As falhas afetam um espectro vasto de instalações, abrangendo desde a versão 5.4 (lançada há mais de uma década) até a versão 8.5.11, englobando praticamente todas as instâncias que processam requisições web.
A terceira falha e a armadilha das sessões
Enquanto as equipes de infraestrutura concentravam esforços na mitigação do PHP2Shell, a PHP Foundation emitiu um aviso suplementar no dia 23 de outubro confirmando uma terceira vulnerabilidade de RCE, rastreada como CVE-2026-115560.
Diferente da urgência aplicada às correções das CVEs anteriores, os desenvolvedores do PHP optaram por não liberar um patch emergencial imediato para esta falha, programando a correção definitiva para o ciclo regular de atualizações. A decisão baseia-se na extrema especificidade do vetor de ataque. Especialistas em segurança apontam que a exploração requer um alinhamento rigoroso e incomum de configurações do servidor e do código da aplicação.
Para que a CVE-2026-115560 seja explorável, o ambiente precisa atender a três condições simultâneas. Primeiro, o recurso de progresso de upload de sessão (session.upload_progress.enabled) deve estar ativo. Segundo, o parâmetro session.serialize_handler precisa estar definido nativamente como php_binary ou php_serialize no arquivo de configuração principal (php.ini). Terceiro (e o mais restritivo), a aplicação web deve alterar esse manipulador de serialização em tempo de execução para o valor padrão php utilizando a função ini_set(), e isso deve ocorrer estritamente antes da invocação de session_start().
Essa sequência desencadeia uma confusão no motor de serialização do PHP, permitindo que a injeção de dados no formulário de progresso de upload seja desserializada incorretamente, levando à execução de código. A ausência de exploração confirmada dessa falha corrobora a avaliação de que o vetor é restrito demais para campanhas de ataque automatizadas em larga escala.
Potassium: a evolução da botnet Mirai em servidores Linux
A agilidade com que os atores de ameaças tentaram capitalizar sobre o PHP2Shell chamou a atenção da comunidade de segurança. Horas após a publicação dos exploits conceituais, a telemetria da Sophos detectou tráfego originado do IP 45[.]198[.]224[.]169, carregando a assinatura de varredura php2shell-scan/109618 no cabeçalho User-Agent. O objetivo dessas requisições era claro: injetar e executar a variante Potassium da botnet Mirai.
A Mirai original tornou-se infame em 2016 por sequestrar dispositivos de Internet das Coisas (IoT) com senhas fracas, criando exércitos de equipamentos zumbis capazes de gerar os maiores ataques de negação de serviço distribuída (DDoS) registrados até então. A variante Potassium representa uma evolução significativa dessa família de malware, adaptando-se para comprometer servidores de alto desempenho em vez de apenas roteadores ou câmeras de segurança.
A análise em sandbox do payload revela um comportamento altamente metódico. Quando o exploit tenta executar o comando ./nfs php, o malware inicia sua rotina de infecção buscando o diretório temporário /tmp/nfs, um local comumente configurado com permissões de gravação em servidores Linux. O Potassium possui uma função de resolução de rede nativa, capaz de lidar com endereços IPv4 e nomes de host, incorporando inclusive mecanismos de fallback (alternativa de segurança) que consultam servidores DNS públicos fixos no código, como 8.8.8.8 (Google) e 1.1.1.1 (Cloudflare), para garantir que a comunicação não seja bloqueada por configurações de DNS locais.
O artefato malicioso tenta estabelecer uma conexão TCP com seus servidores de comando e controle principais, localizados nos IPs 134[.]199[.]154[.]64 e 117[.]55[.]202[.]115, além de se comunicar com domínios de infraestrutura como hackattackkaboom[.]botlesscucks[.]st. A carga verifica ativamente se a resposta HTTP do servidor possui o status 200 (OK) e se os primeiros bytes retornados correspondem à assinatura hexadecimal 7F 45 4C 46. Esses são os “magic bytes” (bytes mágicos) que identificam um arquivo no formato ELF (Executable and Linkable Format), o padrão para binários executáveis em sistemas baseados em Unix e Linux. Ao validar a assinatura, o malware garante que está baixando a carga correta para a arquitetura do sistema infectado, preparando o servidor para receber comandos de ataques DDoS ou atuar como plataforma de distribuição de novas ameaças.
Por que os ataques estão falhando na prática
Existe um abismo técnico entre desenvolver um código de exploração que funciona em um laboratório controlado e criar uma arma cibernética capaz de comprometer infraestruturas diversificadas na internet. No caso do PHP2Shell, essa barreira tem se provado intransponível para as campanhas automatizadas atuais.
A Sophos inicialmente classificou algumas detecções como comprometimentos bem-sucedidos, mas revisou sua avaliação após análises forenses aprofundadas. O que os sistemas de segurança registraram foram ataques em andamento que acabaram contidos por defesas de perímetro ou que colapsaram devido a incompatibilidades de ambiente. A equipe do Sophos Adversary Group (divisão focada em simulação de ataques) relatou dificuldades técnicas substanciais para estabilizar um exploit funcional, mesmo empregando assistência de inteligência artificial generativa na análise do código.
O fracasso dos cibercriminosos decorre da natureza do gerenciamento de memória em linguagens compiladas em C, como o PHP. A corrupção de memória necessária para o RCE depende da localização exata de variáveis, do tamanho exato dos blocos de memória alocados (heap layout) e do comportamento do coletor de lixo (garbage collector) do PHP. Essas variáveis mudam drasticamente de acordo com a distribuição Linux (Ubuntu, Debian, AlmaLinux, Alpine), a arquitetura do processador (x86_64, ARM64), a versão exata do binário do PHP e até mesmo os módulos adicionais carregados (como OPcache ou Xdebug).
Um exploit automatizado que dispara a carga sem conhecer a topografia exata da memória do alvo tem mais probabilidade de causar um travamento do processo (crash) (gerando um erro 502 Bad Gateway ou 503 Service Unavailable) do que de executar o código malicioso com sucesso.
Além das limitações físicas do exploit, as contramedidas de rede provaram ser altamente eficazes. Assinaturas de Sistemas de Prevenção de Intrusão (IPS) e Firewalls de Aplicação Web (WAF) conseguem identificar o padrão anômalo das requisições utilizadas para forçar o erro de falta de memória (OOM). Regras focadas em inspecionar limites de boundary multipart e identificar strings conhecidas associadas à botnet Mirai têm bloqueado o tráfego antes mesmo que ele alcance o processo do PHP. Soluções de detecção de endpoint (EDR e XDR) também estão configuradas para alertar imediatamente sobre processos PHP tentando gravar arquivos executáveis no diretório /tmp ou iniciar conexões de rede atípicas.
O problema do código legado e as estratégias de mitigação
A disponibilidade imediata de patches resolve o problema para infraestruturas modernas, mas expõe a fragilidade de sistemas legados. O projeto PHP liberou correções definitivas por meio das versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A simples atualização dos pacotes por meio dos gerenciadores oficiais (como APT, YUM ou DNF) mitiga completamente as falhas de corrupção de memória.
No entanto, organizações que ainda operam com as versões 8.1 ou anteriores enfrentam um cenário de risco prolongado. Essas versões atingiram o estágio de fim de vida útil (End of Life – EOL) e não recebem mais atualizações de segurança da PHP Foundation. Para esses sistemas, a segurança depende inteiramente da capacidade técnica e da agilidade dos mantenedores das distribuições Linux empresariais (como Red Hat, SUSE ou Canonical) em realizar o backporting; ou seja, isolar o código de correção das versões mais novas e adaptá-lo para os binários antigos sem quebrar a compatibilidade das aplicações existentes.
Para instâncias onde a atualização imediata é arquiteturalmente impossível, os pesquisadores de segurança validaram uma mitigação provisória no nível de configuração. A alteração da diretiva session.upload_progress.enabled = 0 no arquivo php.ini desativa a funcionalidade de monitoramento de upload nativa da linguagem. Essa ação simples remove o vetor de entrada que os exploits atuais do PHP2Shell utilizam para manipular a memória e provocar as falhas, neutralizando também a cadeia de exploração da terceira vulnerabilidade (CVE-2026-115560). Especialistas recomendam que, além da configuração, administradores considerem o uso de arquiteturas Zero Trust Network Access (ZTNA) para isolar servidores vulneráveis da internet pública até que a migração para uma versão suportada do PHP seja concluída.
A crise do PHP2Shell demonstra que, embora a publicação de códigos de exploração acelere a corrida armamentista cibernética, a resiliência das arquiteturas modernas, aliada à aplicação de configurações seguras padrão e defesas em camadas, continua sendo o fator determinante para evitar comprometimentos em escala global.
