PHP2Shell: execução remota de código no PHP

Resumo

Em 21 de outubro de 2026, o projeto PHP publicou correções para duas vulnerabilidades críticas no interpretador, divulgadas em conjunto como PHP2Shell. Ambas receberam CVSS v4.0 9.2, com vetor de rede, sem privilégios e sem interação do usuário. Na CVE-2026-109618, o caminho confirmado em mod_php é explorado no processamento da requisição, antes da execução do código da aplicação; por isso, autenticação e validações implementadas no script não bloqueiam esse caminho.

O problema não está restrito a um framework, CMS ou função específica: qualquer instalação PHP que atenda requisições HTTP está no escopo, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior em mod_php, onde a exploração foi demonstrada de forma independente da aplicação.

A correção está disponível para as linhas suportadas. A atualização é a única correção completa; as mitigações de configuração documentadas reduzem a exposição a caminhos conhecidos, mas não tornam a instalação segura.

Por que este alerta é prioritário

• PHP está presente em sites, APIs, painéis administrativos, CMS e appliances, muitas vezes como componente embarcado e fora do inventário tradicional.
• Há relatos públicos de tentativas de exploração e atividade em ambiente real, incluindo uma tentativa observada em 17 de outubro de 2026, antes da divulgação.
• Versões fora de suporte também são afetadas: 7.4, 8.0 e 8.1 dependem de backport ou pacote do fornecedor; 7.3 e anteriores não têm correção do projeto PHP.
• A exploração pode não derrubar o worker nem retornar erro: uma resposta HTTP 200 não é evidência de que a requisição foi inofensiva.

Gravidade e exposição

A pontuação é alta, mas a exploração exige condições específicas: o atacante precisa provocar a falha no momento correto e, no caso da CVE-2026-109618, lidar com aleatorização de memória e múltiplas tentativas. Isso reduz a automação trivial, mas não impede a exploração — e ambientes com muitos workers ou tráfego intenso podem aumentar a superfície disponível.

Status de exploração: a Amazon Threat Intelligence relatou uma tentativa contra sua rede de sensores em 17 de outubro de 2026; a watchTowr relatou exploração em ambiente real em 21 de outubro. A CISA, no alerta de 21 de outubro, afirmou não ter observado exploração até a publicação. Até 22 de outubro, nenhum dos dois CVEs constava no catálogo Known Exploited Vulnerabilities (KEV) da CISA. Consulte o KEV para o status atual.

Detalhes técnicos

CVE-2026-109618 — corrupção durante OOM

O PHP usa um salto de controle (longjmp()) para abandonar o processamento quando uma alocação de memória falha. Em determinados pontos da inicialização da requisição, a memória ainda está parcialmente inicializada. Se a alocação falhar nesse intervalo, o encerramento da requisição pode tratar estruturas inválidas como válidas e desviar o fluxo para um callback controlado pelo atacante.

Os caminhos conhecidos incluem números excessivos de cabeçalhos em partes multipart, campos aninhados, controles de arquivo vazios e requisições multipart sem Content-Length utilizável. Falhas de alocação provocadas pela própria aplicação também podem servir de gatilho. O ponto relevante é que o estouro ocorre durante o parsing da entrada, antes de qualquer código do site ser executado.

CVE-2026-109619 — estado global obsoleto

O worker PHP mantém estado global — de erro, sessão, objetos e extensões — que aponta para memória pertencente a uma requisição. Normalmente esse estado é reiniciado antes da liberação da memória. Um erro fatal, um tempo de execução excedido ou um diagnóstico tardio pode interromper essa limpeza, deixando o worker com ponteiros para memória já liberada. A requisição seguinte, atendida pelo mesmo worker, pode consumir esse estado antes da inicialização normal.

Dois caminhos foram confirmados: o estado de backtrace de erros fatais no PHP 8.5, e o ciclo de session upload progress, que é habilitado por padrão e pode ser alcançado antes de a aplicação chamar session_start(). A exploração exige que produtor e consumidor sejam processados pelo mesmo worker; pools maiores reduzem a taxa de sucesso por tentativa, mas não eliminam a falha.

Fraquezas relacionadas nas advisories: CWE-416 (use after free), CWE-755, CWE-824, CWE-1325 e CWE-1419. Este alerta não reproduz código de exploração; o objetivo é orientar inventário, correção e detecção.

Versões afetadas e correção

Distribuições Linux e fornecedores de suporte de longo prazo receberam as correções antes da divulgação. Em pacotes de distribuição, o número da versão pode não mudar mesmo com o backport aplicado: valide pelo changelog e pelo advisory do fornecedor, não apenas por php -v.

Como verificar o runtime correto

O binário do CLI pode ser diferente do runtime que atende o serviço web. Confirme o SAPI, a configuração carregada e o binário do FPM/Apache:

php -v
php -i | grep -E 'Server API|Loaded Configuration File|memory_limit|post_max_size'
php -i | grep -E 'session.upload_progress.enabled|fatal_error_backtraces'
php-fpm -v
apache2ctl -M | grep -i php

Em contêineres, verifique a imagem que está em execução, não apenas o host:

docker exec <nome-do-container> php -v
docker exec <nome-do-container> php -i | grep 'Server API'

• Reconstrua e redeploye imagens afetadas; atualizar o PHP do host não corrige uma imagem antiga em execução.
• Reinicie ou substitua todos os workers após a atualização, inclusive processos mantidos por graceful reload.
• Confirme a versão em cada pool, nó de balanceamento e instância autoscaling.

Detecção

A investigação deve começar antes da data de divulgação: a Amazon relatou uma tentativa em 17 de outubro de 2026. Correlacione proxy/WAF, logs do PHP, logs do servidor web e telemetria de processos; nenhum sinal isolado é conclusivo.

Requisições suspeitas

• Corpos application/x-www-form-urlencoded ou multipart com nomes de campos excessivamente longos, na casa de megabytes.
• Multipart com quantidade anormal de cabeçalhos por parte, campos aninhados, arquivos vazios ou muitos arquivos.
• Requisições sem Content-Length utilizável ou com tamanho declarado incompatível com o corpo observado.
• Bytes nulos ou dados binários inesperados em valores de formulário; sequências de muitos campos com o mesmo prefixo.
• Padrões repetidos contra o mesmo endpoint ou o mesmo worker, com respostas 200, 500 ou conexões encerradas.

Logs do PHP e do servidor web

Erros de memória durante a inicialização da requisição, antes de qualquer script, são um sinal importante — especialmente quando correlacionados a POSTs grandes:

PHP Fatal error: Allowed memory size of ... bytes exhausted
(tried to allocate ... bytes) in Unknown on line 0

AH00052: child pid ... exit signal Segmentation fault (11)

Também merecem investigação avisos e erros fatais repetidos antes do script, mensagens de Maximum execution time exceeded, falhas em callbacks de upload/importação e encerramentos inesperados de workers. Esconder erros com display_errors=0 ou error_reporting não impede o acesso ao estado obsoleto; para detecção, é necessário registrar os eventos.

Processos, arquivos e rede

• Worker web gerando sh, bash, curl, wget, nc, interpretadores ou comandos de download.
• Novos arquivos PHP em diretórios de upload, alterações em arquivos existentes, .user.ini, auto_prepend_file ou configurações de PHP inesperadas.
• Tarefas agendadas, serviços, chaves SSH e usuários criados fora do padrão operacional.
• Conexões de saída para destinos desconhecidos, resolução DNS anômala, beacons e transferências de dados incompatíveis com o horário e o serviço.
• Em PHP 8.5, sinais do caminho de fatal error backtraces; em qualquer versão, atividade de session upload progress sem uso legítimo pela aplicação.

Recomendações

1. Inventarie todos os runtimes PHP. Inclua servidores web, APIs, painéis, CMS, appliances, funções serverless, imagens de contêiner e componentes embarcados. Priorize o que está exposto à internet e o que usa mod_php.
2. Atualize para a versão corrigida da linha em uso. Aplique o pacote do fornecedor ou distribuição, ou compile a release oficial. Para 7.4, 8.0 e 8.1, use o backport mínimo do PHP ou o pacote corrigido do fornecedor; para 7.3 e anteriores, migre para uma linha suportada.
3. Reconstrua imagens e reinicie os workers. Atualize a imagem base, gere nova imagem, faça o deploy e confirme que nenhum worker antigo continua atendendo. Em FPM, valide o binário e a configuração de cada pool.
4. Valide a correção. Confirme a versão no SAPI web, não apenas no CLI; verifique cada nó, contêiner e ambiente. Registre a evidência no inventário de vulnerabilidades.
5. Se não puder atualizar imediatamente, reduza a exposição. Retire o serviço da internet ou restrinja por proxy/WAF; aplique as mitigações temporárias abaixo; trate o ativo como potencialmente comprometido.
6. Reduza a superfície de entrada. Limite tamanho de corpo, quantidade de campos, cabeçalhos por parte multipart, profundidade de aninhamento e número de uploads. Se a aplicação não usa multipart, bloqueie esse tipo de requisição no frontend.
7. Monitore e cace ameaças. Revise logs desde 17 de outubro de 2026, com atenção a POSTs grandes, erros de memória, segfaults, shells filhos de workers, arquivos novos e conexões de saída.
8. Preserve evidências antes de limpar. Em suspeita de comprometimento, isole o ativo, colete logs e processos e avalie a memória com a equipe de resposta antes de reiniciar ou reconstruir.
9. Rotacione credenciais e segredos após um comprometimento confirmado: senhas, chaves SSH, tokens de API, segredos de aplicação, certificados e credenciais de banco. Reconstrua a partir de uma imagem confiável.
10. Comunique e registre. Acione o SOC da GigaCandanga e os canais oficiais aplicáveis (CISC, CTIR Gov, CERT.br). Avalie obrigações de notificação de incidente e de proteção de dados pessoais.

Mitigação temporária

Evite: usar RLIMIT_AS ou RLIMIT_DATA como limite de memória (eles podem provocar a falha de alocação que dispara a CVE-2026-109618); depender de ini_set() ou .user.ini para configurações que precisam valer antes do parsing; e esconder diagnósticos com display_errors=0 — isso não impede o acesso ao estado obsoleto.

Resposta a incidentes

Se houver suspeita de exploração, trate o servidor como comprometido até prova em contrário. A resposta deve preservar evidências e remover a causa raiz, não apenas os arquivos visíveis.

1. Contenha: isole o ativo da internet e de outros segmentos, preserve logs e, se a equipe de resposta orientar, colete memória e processos antes de reiniciar.
2. Investigue: revise logs de proxy/WAF, PHP, Apache/FPM, sistema e EDR; processos filhos de workers; arquivos PHP novos ou alterados; uploads; persistência (cron, serviços, chaves, usuários); conexões de saída e acessos a banco e storage.
3. Eradique: reconstrua o serviço a partir de imagem ou pacote confiável, com PHP corrigido; não confie apenas na remoção de um web shell.
4. Recupere: rotacione credenciais e segredos, valide a configuração, monitore o retorno e confirme a versão corrigida em todos os workers.
5. Notifique: acione o SOC da GigaCandanga e os canais oficiais (CISC, CTIR Gov, CERT.br). Avalie notificação de titulares e demais obrigações legais, inclusive LGPD, se houver dados pessoais afetados.

Referências

Links externos abrem em nova aba. Consulte sempre a fonte oficial para o status mais recente.

• PHP · Security advisory: Critical remote code execution vulnerabilities, update now PHP.net · 21 out. 2026
• GHSA-w8hw-w9fx-j79w · RCE via OOM corruption (CVE-2026-109618) PHP Security Advisories · 21 out. 2026
• GHSA-6wmf-4rv5-p3rp · RCE via stale global state (CVE-2026-109619) PHP Security Advisories · 21 out. 2026
• CISA · Critical Vulnerabilities in PHP Require Immediate Patching CISA · 21 out. 2026
• CERT-EU · Security Advisory 2026-018: Critical Vulnerabilities in PHP CERT-EU · 21 out. 2026
• CISC · CVE-2026-109618 e CVE-2026-109619 (CVSS 9.2): vulnerabilidades críticas de execução remota de código no PHP CISC Gov.br · 21 out. 2026
• Amazon Threat Intelligence identifica exploração de PHP2Shell antes da divulgação pública AWS Security Blog · 21 out. 2026
• PHP2Shell: critical vulnerabilities in PHP — detection, analysis and remediation Datadog Security Labs · 21 out. 2026
• Threat Brief: Critical Vulnerabilities in PHP CVE-2026-109618 and CVE-2026-109619 Unit 42 · 21 out. 2026
• php2shell: perguntas frequentes sobre as vulnerabilidades críticas de RCE no PHP Tenable · 21 out. 2026, atualizado em 22 out. 2026
• PHP2Shell FAQ: CVE-2026-109618 e CVE-2026-109619 watchTowr · atualizado em 22 out. 2026
• PHP2Shell · technical writeup Calif.io · 21 out. 2026

Outras fontes de consulta para resposta e investigação estão em Links úteis.

Revisão

Revisão 1.0 — 23 de outubro de 2026 — Publicação inicial. Fontes consultadas até 23 de outubro de 2026. O status de exploração e a inclusão no catálogo KEV podem mudar; confirme nas fontes oficiais.

Este alerta consolida informações públicas e tem caráter informativo. Não substitui os advisories dos fornecedores nem a avaliação da equipe responsável por cada ambiente. Teste as ações em ambiente controlado antes de aplicá-las em produção.