PHP2Shell: duas falhas críticas no PHP permitem execução remota de código sem login

O projeto PHP publicou em 21 de outubro de 2026 correções de emergência para duas vulnerabilidades críticas no núcleo da linguagem, apelidadas de PHP2Shell: CVE-2026-109618 e CVE-2026-109619, ambas com CVSS v4.0 9.2. Elas permitem execução remota de código (RCE) sem autenticação.

O ponto mais importante: o problema está no runtime do PHP, não nas aplicações. Um site pode ter código seguro e ainda assim estar vulnerável.

O que as falhas fazem

• CVE-2026-109618, corrupção de memória por falta de memória (OOM). Se uma requisição atinge o memory_limit no momento errado, o PHP pode deixar dados internos parcialmente inicializados e tratá-los como válidos, corrompendo a memória. No Apache com mod_php, uma requisição não autenticada pode disparar a falha antes de qualquer código da aplicação, e a execução remota foi demonstrada com configurações padrão. No PHP-FPM, a RCE foi confirmada por caminhos de código no nível da aplicação.
• CVE-2026-109619, estado obsoleto. Um erro fatal no ponto errado pode deixar o estado interno apontando para memória de uma requisição anterior, que uma requisição seguinte, no mesmo worker, volta a usar depois de liberada (use-after-free). A RCE foi demonstrada em uma aplicação real sob Apache com mod_php.

Segundo a cobertura do The Hacker News, as duas falhas também podem vazar memória do worker, com possíveis senhas, tokens e chaves de outras requisições.

Quem está exposto

Toda instalação de PHP que atende requisições web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. Segundo a cobertura, quase todas as versões desde o PHP 5.4 até a 8.5.11 são afetadas. O PHP pode vir embutido em outros softwares, então ele nem sempre está visível no inventário.

Como corrigir

As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

1. Faça o inventário de tudo que roda PHP, começando pelos sistemas expostos à internet.
2. Atualize e reinicie Apache, PHP-FPM e workers de longa duração. Sem o reinício, o processo antigo continua vulnerável.
3. Em distribuições Linux, o patch pode ter sido aplicado sem mudar o número da versão. Confira o changelog do pacote pelo número da CVE.
4. Depois de atualizar, revise memory_limit e post_max_size. O novo limite rígido de memória encerra o processo e impede a execução de shutdown handlers, o que pode afetar aplicações que dependiam disso.

E quem não consegue atualizar?

PHP 8.1 e anteriores não recebem mais correções do projeto. Para a 7.4, a 8.0 e a 8.1 foram publicados backports em código-fonte, destinados a quem compila por conta própria ou aguarda um fornecedor. A CISA orienta tirar do ar os sistemas baseados em PHP que não possam ser corrigidos ou que usem a 8.1 ou anteriores, até que sejam atualizados.

Quem depende de hospedagem, CMS ou distribuição que ainda não entregou o pacote corrigido segue exposto. Cobre o fornecedor e pergunte a data.

Medidas paliativas, que não tornam o servidor seguro:

• limite o tamanho das requisições no servidor web ou no proxy e mantenha post_max_size baixo;
• para a CVE-2026-109618, defina memory_limit=-1 para que aplicações não o sobrescrevam. Não use RLIMIT_AS nem RLIMIT_DATA;
• para a CVE-2026-109619, defina session.upload_progress.enabled=0 e reinicie os workers. No PHP 8.5, defina também fatal_error_backtraces=0. Isso não bloqueia todas as variantes;
• um firewall de aplicação web (WAF) pode dar alguma proteção temporária, mas há relatos de atacantes trocando payloads para contornar regras.

Há exploração?

O quadro ainda estava mudando na noite de 21/10, e as fontes divergem.

• A CISA informou que não observou exploração até a publicação do alerta e orienta aplicar o patch imediatamente.
• A equipe de segurança do PHP não identificou nenhum exploit funcional até o lançamento, mas diz que a circulação de provas de conceito aumentou em 21/10.
• A Cloudflare relatou tentativas iniciais de exploração e ataques que trocavam payloads para contornar suas regras de firewall.
• A watchTowr disse, em um primeiro momento, não ter observado exploração e, horas depois, atualizou para tentativas ativas contra as duas CVEs.
• Nenhuma fonte confirmou a invasão bem-sucedida de um servidor específico, e as falhas não estavam no catálogo KEV da CISA na data da cobertura.

Na prática: trate como risco de exploração iminente.

Como saber se já houve tentativa

Procure por:

• requisições multipart incomuns seguidas de erros de limite de memória ou HTTP 500 repetidos;
• cookies PHPSESSID anormalmente grandes;
• reinícios inexplicados de workers;
• processos de worker do PHP iniciando shells ou baixando ferramentas.

Como chegou até aqui

Em 20/10, os identificadores das CVEs começaram a circular em fóruns e redes sociais, com um CVSS 10.0 que o projeto não confirmou (a nota real é 9.2). O PHP antecipou a divulgação de 22/10 para 21/10. Segundo a PHP Foundation, a Calif publicou por engano um vídeo com prova de conceito, depois removido, e a Chainguard publicou imagens com o patch antes do prazo combinado. Isso acelerou o trabalho de quem quer reproduzir a falha. Segundo a cobertura, a Cloudflare ativou regras de WAF na manhã de 21/10. Organizações como a BambooHR chegaram a tirar serviços do ar por precaução.

Como a Indene pode ajudar

Podemos ajudar a mapear onde o PHP roda no seu ambiente (inclusive embutido em outros softwares), priorizar a atualização e procurar sinais de tentativa de exploração. [a confirmar: canal de contato e CTA padrão da casa]

Fontes: PHP Foundation, alerta da CISA e The Hacker News.