O Halloween trouxe uma vulnerabilidade fantasiada. PHP2Shell é o nome que circula para um par de registros CVE críticos no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, ambos resultando em execução remota de código sem autenticação. O nome está fazendo muito trabalho. Um bom nome coloca um bug no celular do CISO antes mesmo de o advisory ser legível, e neste caso o branding chegou literalmente antes dos fatos, quando um vídeo de prova de conceito sob embargo e diffs iniciais de contêiner vazaram em 20 de outubro, antes da divulgação coordenada.

Agora que a poeira baixou após o lançamento emergencial de 21 de outubro, vamos separar os fatos verificados do rumor das redes sociais. Ambas as vulnerabilidades residem no código C do próprio Zend Engine e afetam todas as versões do PHP de 5.4 até 8.5.11. Descobertas de forma independente em agosto por pesquisadores da Calif (em parceria com a OpenAI) e da Wiz Research por meio de auditoria de código assistida por IA, ambas as falhas carregam uma pontuação CVSS v4.0 oficial de 9.2:

• CVE-2026-109618 (Corrupção por Esgotamento de Memória): Quando uma requisição maliciosa esgota o memory_limit durante o parse, o PHP aborta via longjmp() antes que as estruturas internas sejam totalmente inicializadas, enganando a rotina de limpeza para liberar memória não inicializada. Contra o Apache mod_php, uma única requisição sem autenticação pode disparar RCE antes que uma única linha de código da aplicação seja executada.

• CVE-2026-109619 (Estado Global Obsoleto): Após um erro fatal, ponteiros pertencentes à requisição podem sobreviver apontando para memória liberada. A próxima requisição tratada pelo mesmo worker persistente (como o PHP-FPM) reutiliza esse estado corrompido, principalmente por meio da configuração session.upload_progress.enabled, habilitada por padrão.

Nas primeiras 48 horas de um bug nomeado, a história sempre tem três camadas: o que o advisory oficial diz, o que os write-ups dos pesquisadores dizem e o que mil reposts em pânico dizem. O catálogo Known Exploited Vulnerabilities (KEV) da CISA () continua sendo o sinal mais confiável aqui. Embora redes honeypot da Amazon, Cloudflare e Arctic Wolf já tenham detectado varreduras oportunistas e sondagens de botnets, a CISA informou em seu alerta de 21 de outubro que ainda não havia confirmado comprometimentos bem-sucedidos em produção, e nenhum dos CVEs foi adicionado ao KEV até o momento.

O que podemos analisar com total confiança é o que acontece a seguir, porque o playbook de pós-exploração nunca muda. Seja por execução de comandos diretamente em memória (MITRE ATT&CK T1190) ou por implantação de um web shell persistente (T1505.003, ), o payload é executado sob a identidade do servidor web. E em muitos ambientes, essa identidade é uma service account silenciosamente poderosa com uma senha de banco de dados num arquivo de configuração ao lado.

É por isso que uma publicação de IAM está escrevendo sobre um bug em PHP. O exploit é a entrada. A identidade é o prêmio. Uma vez que um atacante executa como www-data ou o usuário do pool de workers do FPM, as perguntas que decidem se isso será uma tarde ruim ou um trimestre ruim são todas perguntas de identidade:

• Que credenciais aquele processo consegue ler? Usuários de banco de dados, chaves de API, segredos de cliente OAuth e roles de instâncias de nuvem acessíveis pelo endpoint de metadados.

• O que essas credenciais podem fazer? Um usuário de banco de dados que só precisa de SELECT em três tabelas, mas que tem DBA porque "era mais fácil em 2019", transforma um worker comprometido em uma violação de dados completa.

• Que identidade própria o host web possui? Uma role IAM com escopo excessivo vinculada à instância de computação é o caminho mais rápido de uma máquina para toda a conta na nuvem. A AWS documenta o hardening de metadados de instância (IMDSv2) exatamente por esse motivo ().

• Você chegaria a perceber? Workers comprometidos são ruidosos se você registra o comportamento dos processos e silenciosos se você só monitora logs HTTP. Conexões de saída de um servidor web para hosts desconhecidos, novos arquivos em diretórios graváveis pelo servidor e workers PHP gerando /bin/sh, curl ou wget são detecções baratas e de alto sinal.

O PHP oferece configurações que reduzem a exposição enquanto você testa o patch (). Para o PHP2Shell especificamente, definir session.upload_progress.enabled = 0 e (no PHP 8.5) fatal_error_backtraces = 0 fecha os caminhos mais comuns do CVE-2026-109619. Restringir disable_functions (exec, shell_exec, system, passthru) e open_basedir ainda é uma boa prática contra payloads PHP oportunistas, embora, como o PHP2Shell corrompe memória no motor C subjacente, um exploit sofisticado possa contornar as restrições do php.ini em memória. O isolamento em nível de SO (SELinux, AppArmor e limites rígidos de memória com cgroup v2) é onde a fronteira real existe.

No lado da identidade, a recomendação permanente é pouco glamourosa e correta. Dê ao tier web o menor conjunto de permissões necessário, rotacione os segredos que ele mantém, mova esses segredos para fora de arquivos .env simples para um gerenciador de segredos com tokens de vida curta, e trate a service account do servidor web como um principal a ser auditado como qualquer administrador humano. Service accounts não reclamam em entrevistas de desligamento, então ninguém as revisa. Esse é o problema central.

Aqui está a parte encorajadora, e estou sendo sincero. Todo bug com um nome assustador é um exercício de tabletop gratuito. Você não precisa esperar o próximo CVE para responder: "Se um estranho executasse código no nosso tier PHP hoje à noite, o que ele obteria e nós saberíamos?" Se sua resposta honesta te faz franzir a testa, parabéns: você acabou de encontrar a vulnerabilidade real, e ela não precisou de um número CVE.

Atualize para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (e se você ainda roda PHP 8.1 ou 7.x em End-of-Life, reconheça que os patches upstream não vão chegar). Acompanhe o CISA KEV. Enquanto isso, reduza o que o tier web consegue acessar. O fantasia vai embora na segunda-feira. A service account com privilégios excessivos ainda estará lá, a menos que você a trate.