Ir para o conteúdo principal

PHP2Shell: RCE crítico no PHP e como responder

Em 21 de outubro de 2026, o projeto PHP publicou as versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12 para corrigir duas vulnerabilidades críticas, registradas como CVE-2026-109618 e CVE-2026-109619 e apelidadas de "PHP2Shell". Ambas permitem execução remota de código sem autenticação, com os privilégios do processo web. Como o PHP sustenta grande parte dos portais corporativos, e-commerces e CMSs, como WordPress, Joomla e Magento, a pergunta inicial para qualquer organização não é técnica, e sim de inventário: onde executamos PHP hoje?

Resumo para a liderança

  • Risco: execução remota de código sem login, com CVSS v4 9.2 (crítico) nas duas falhas.
  • Exposição: todo servidor web com PHP 8.2 a 8.5 sem a atualização de 21/10, além dos ramos 7.4 a 8.1 sem backport do fornecedor. O PHP 7.3 e anteriores não recebem correção.
  • Decisão: tratar como correção emergencial, com prazo medido em horas, priorizando os sistemas expostos à internet.
  • Evidência: solicitar ao time e aos fornecedores o inventário de ativos com PHP e a comprovação da versão corrigida em produção.

Causa-raiz: duas falhas de gerenciamento de memória

CVE-2026-109618 (corrupção por falta de memória). Quando uma alocação falha por atingir o memory_limit, o PHP abandona o contexto atual por meio de longjmp(). Se isso ocorre enquanto estruturas da requisição estão parcialmente inicializadas, a rotina de encerramento passa a ler e a tomar decisões sobre um estado inválido. O vetor mais relevante é o processamento de requisições multipart: corpos sem tamanho declarado utilizável podem passar pela verificação inicial de post_max_size, cada parte pode conter cabeçalhos ilimitados e campos de arquivo vazios geram metadados sem contar para max_file_uploads. A correção substitui o longjmp() por um encerramento controlado no próximo ponto seguro da máquina virtual.

CVE-2026-109619 (estado global obsoleto). O PHP mantém estado global, como informações de erro e de sessão, que pode apontar para a memória de uma requisição. Em processos persistentes (workers), essa memória é liberada sem que o ponteiro seja reiniciado quando um erro fatal ou um timeout interrompe a limpeza. Uma requisição seguinte, atendida pelo mesmo worker, consome esse ponteiro antes da inicialização normal, caracterizando um use-after-free (CWE-416). Os consumidores confirmados são diagnósticos de diretivas INI e o recurso de session upload progress, que não depende de a aplicação chamar session_start().

O vetor CVSS v4 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) explica a nuance: a exploração é remota e não exige credenciais, mas depende de condições de implantação (AT:P). Isso reduz a confiabilidade de um ataque genérico, mas não elimina o risco.

Matriz de exposição

AmbienteRiscoObservação
Apache com mod_php Mais alto RCE confirmado com configuração padrão; a exploração ocorre antes do código da aplicação.
PHP-FPM Elevado RCE validado via ciclo de sessão; o cenário de falta de memória não tem exploit completo publicado.
FrankenPHP, LiteSpeed, php-cgi Afetados Considerados suscetíveis pelo projeto PHP.
PHP 7.4, 8.0 e 8.1 Afetados Dependem de pacotes da distribuição, fornecedor LTS ou backports mínimos.
PHP 7.3 ou anterior Sem correção Migração ou isolamento da internet.

Sobre exploração ativa, as fontes divergem: a watchTowr relata exploração em seus honeypots desde 21/10, enquanto a Rapid7 relata tentativas, mas não exploração confirmada. Até 22/10, as CVEs não constavam do catálogo KEV da CISA. Existem provas de conceito públicas, ainda dependentes de combinações específicas de sistema operacional, versão e servidor web.

Como verificar o ambiente

php -v
php -i | grep -E "Server API|memory_limit|session.upload_progress.enabled|fatal_error_backtraces"
apachectl -M 2>/dev/null | grep -i php     # mod_php carregado?
systemctl list-units | grep -i php-fpm      # pools FPM ativos?

Recomendamos atenção a três armadilhas comuns: o PHP de linha de comando pode ter versão diferente do PHP que atende o servidor web; imagens de contêiner e ambientes de hospedagem compartilhada precisam ser verificados separadamente; e a atualização só tem efeito após reiniciar todos os workers.

Mitigação

A atualização para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 é, segundo o próprio projeto PHP, a única mitigação completa. Enquanto ela não for possível, as medidas abaixo reduzem a exposição, sem substituí-la:

session.upload_progress.enabled = 0   ; recomendado mesmo após a correção, se não utilizado
fatal_error_backtraces = 0            ; PHP 8.5
post_max_size = 8M                    ; ou 32M se houver uploads; upload_max_filesize abaixo disso
  • Aplicar as diretivas de forma administrativa (php.ini, pool FPM ou configuração do servidor); um ini_set() na aplicação chega tarde demais.
  • No WAF ou proxy reverso, limitar o tamanho decodificado, a quantidade de partes multipart e de cabeçalhos por parte, e bloquear multipart onde a aplicação não o utiliza.
  • Não utilizar RLIMIT_AS ou RLIMIT_DATA: eles provocam justamente as falhas de alocação que levam ao caminho vulnerável.
  • Ocultar erros com @, display_errors ou error_reporting não impede o consumo do estado obsoleto.
  • Sistemas que não puderem ser corrigidos de imediato devem ter o acesso pela internet restringido.

Detecção

Recomendamos monitorar falhas de segmentação e reinícios inesperados de workers nos logs do servidor, picos de requisições multipart com corpo sem tamanho declarado ou com número anormal de partes, e sequências de erros 500 a partir da mesma origem. Varreduras autenticadas de vulnerabilidade complementam o inventário. Em ambiente isolado, ativar log_errors com error_reporting=E_ALL ajuda a identificar erros fatais e timeouts que um atacante poderia provocar.

Governança: da correção à evidência

Considere um e-commerce operado sobre um CMS em PHP e hospedado por terceiros. A correção depende do provedor, mas o risco, e a eventual exposição de dados de clientes, permanece com a empresa. Nesses casos, a pergunta para a diretoria é se existe um SLA contratual de correção para vulnerabilidades críticas e como a aplicação do patch será comprovada.

Para instituições reguladas, a Resolução CMN 4.893 exige procedimentos de tratamento de vulnerabilidades e controles sobre serviços contratados, o que inclui fornecedores de hospedagem e SaaS. Registrar o inventário, a data da correção, a versão em produção e as medidas temporárias adotadas transforma uma resposta emergencial em evidência de auditoria. Plataformas de priorização e correção automatizada, como a Vicarius, e camadas de proteção de aplicações web, como o WAF da Imperva (Thales), reduzem o tempo entre a divulgação e a correção efetiva.

Por fim, o episódio reforça um ponto estrutural: a segurança de aplicações web depende de componentes de terceiros que a organização não controla, mas pelos quais responde. Inventário atualizado de software, monitoramento de advisories e processos de correção testados são o que diferenciam uma resposta de horas de uma exposição de semanas.

Converse com nosso time sobre a exposição dos seus ativos web.

Referências

Leia também