PHP2Shell: o que fazer com as CVE-2026-109618 e CVE-2026-109619

PHP2Shell é o apelido de duas vulnerabilidades no interpretador PHP, a CVE-2026-109618 e a CVE-2026-109619, ambas com nota 9,2 no CVSS v4.0. As duas permitem execução remota de código sem autenticação em servidores que processam requisições web com PHP. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas em 21 de outubro de 2026.

Texto atualizado em 22 de outubro de 2026. O caso está em movimento e os números abaixo vão envelhecer rápido.

Por que esta é diferente

Falha crítica em PHP não é novidade. Quase toda semana sai uma em algum CMS, plugin ou framework escrito na linguagem. A PHP2Shell está em outro andar: mora no próprio interpretador, no código que trata cada requisição HTTP antes de entregar o controle para a aplicação.

Isso muda a conta de quem está exposto. Não importa se o site roda WordPress, Laravel, Magento ou um sistema caseiro de 2012. Se o PHP que atende a requisição está numa versão vulnerável, o ponto de entrada existe. A equipe do PHP classificou as descobertas entre as mais graves da história do projeto, segundo a análise publicada pela Wiz, uma das três casas que descobriram o problema junto com a OpenAI e a Calif.

E o PHP está em toda parte. Pelo W3Techs, 70,3% dos sites cuja linguagem de servidor dá para identificar usam PHP. Desses, 28,9% ainda rodam a versão 7 e 7,9% a versão 5, ramos que não recebem correção oficial do projeto.

O que cada CVE faz

As duas falhas nascem do mesmo mecanismo. Quando o PHP fica sem memória ou encontra um erro fatal no meio de uma requisição, ele aborta o trabalho com um salto direto para fora do contexto atual, o longjmp(), que a equipe do projeto chama de bailout. Alguns trechos do código não contavam com essa interrupção e deixavam o estado interno pela metade.

A CVE-2026-109618 é a corrupção por falta de memória. Se o bailout acontece enquanto dados internos da requisição estão parcialmente inicializados, a rotina de limpeza que roda em seguida lê essa memória como se fosse válida. O advisory oficial diz que várias estratégias de esgotamento de memória disparam a condição de forma consistente.

A CVE-2026-109619 é estado global obsoleto. O PHP guarda ponteiros globais que apontam temporariamente para a memória da requisição. Em alguns cenários eles não são zerados no fim, ou são repovoados depois de zerados, e continuam apontando para memória já liberada. A requisição seguinte, atendida pelo mesmo processo, pode usar esse ponteiro antes da inicialização normal acontecer. É um use-after-free entre requisições, descrito no GHSA-6wmf-4rv5-p3rp.

O gatilho remoto mais citado é o recurso de upload progress de sessão (session.upload_progress), ligado por padrão desde o PHP 5.4. Ele atualiza o estado da sessão enquanto o PHP ainda está lendo o corpo de um POST multipart, ou seja, antes de a aplicação existir na história. Segundo a Imperva, três das cinco técnicas de exploração conhecidas passam por ele. O watchTowr reforça que esse é um caminho confirmado, e não o único.

Não vamos detalhar a cadeia de exploração aqui. Para quem defende, o que importa cabe numa frase: um atacante sem conta nenhuma manda uma requisição montada para qualquer endpoint que aceite POST e pode sair com execução de código no servidor.

Um detalhe que ajuda a calibrar o risco. A exploração tem complexidade alta, porque depende de a requisição seguinte cair no mesmo processo e ocupar a memória liberada do jeito certo. Quando não encaixa, o processo cai em vez de executar código. Isso atrasa o atacante de um ataque só, mas não segura uma varredura em massa que tenta milhares de vezes.

Quem está exposto

Toda instalação de PHP que atende requisição web, em qualquer SAPI: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O Qualys e o watchTowr apontam o mod_php como o caso mais urgente, porque o Apache chama a rotina de encerramento da requisição mesmo quando a inicialização falhou. O ataque fecha antes de qualquer código da aplicação rodar.

Atenção ao número da versão em distribuições Linux. Red Hat, Ubuntu, Fedora, AlmaLinux e outras aplicam o backport sem trocar a versão upstream, então um php -v mostrando 8.1 pode estar corrigido e um mostrando 8.2.30 compilado à mão certamente não está. Quem decide é o advisory do distribuidor.

E tem o PHP que ninguém lembra que existe. Em 22 de outubro a Palo Alto Networks informou que todas as versões do PAN-OS e do Panorama são afetadas, ainda sem correção. A Fortinet está avaliando 12 produtos e a Cisco, 31 produtos e serviços de nuvem. Firewall, painel de roteador, console de gerenciamento, appliance de backup: muito equipamento carrega um PHP embutido que não aparece em nenhum inventário de software.

Linha do tempo

A Sansec tinha previsto exploração em massa em até 15 minutos depois do patch. A previsão foi otimista. O ataque começou antes do patch.

O que o ThreatSensor mostra

O ThreatSensor, a base pública de inteligência de exploração da CSURFACE, já lista as duas CVEs com tudo o que foi coletado até agora. A foto de 22 de outubro:

Duas coisas chamam a atenção nesses números.

A primeira é a velocidade. Em menos de 48 horas depois do patch, a CVE-2026-109618 acumulou mais de 300 repositórios públicos, entre PoCs, scanners, laboratórios em Docker e regras de detecção. A Wiz escreveu que modelos de IA de fronteira reduziram de forma substancial a barreira para transformar a falha em exploit, e o volume de código público no primeiro dia combina com isso.

A segunda é o KEV. A falha tem exploração confirmada desde antes do patch e ainda não entrou no catálogo da CISA. Quem prioriza correção esperando o KEV está, neste momento, atrás de 133 ataques já observados. A CISA precisa de evidência para catalogar, e evidência leva dias. Por isso a fila não pode depender só do catálogo.

O que fazer agora

Em ordem. A ordem importa.

1. Preserve evidência antes de mexer. Logs do PHP e do servidor web, configuração atual, arquivos suspeitos. Se o servidor já foi comprometido, o patch apaga a pista sem tirar o invasor de dentro.
2. Atualize para a versão corrigida do seu ramo, ou para o pacote corrigido do seu distribuidor. Ramos sem suporte precisam do backport do projeto ou de um fornecedor de LTS. Atualizar é a única correção completa, e todas as fontes concordam nisso.
3. Reinicie todos os workers do PHP. PHP-FPM, Apache, LiteSpeed. O estado obsoleto vive no processo, e processo antigo continua vulnerável com binário novo no disco.
4. Priorize mod_php exposto à internet, depois os demais SAPIs expostos, depois o resto.
5. Procure sinais de comprometimento nos servidores que ficaram expostos desde 17 de outubro: web shell nova, cron inesperado, conta criada, processo filho estranho do PHP, conexão de saída que não existia.
6. O que não puder ser corrigido hoje sai da internet ou vai para trás de controle de acesso. É a recomendação do NCSC.

Mitigação temporária, para quem não consegue atualizar já

Estas configurações fecham parte dos caminhos. Nenhuma delas substitui o patch, e o watchTowr alerta que alterações via .ini não cobrem a superfície toda.

; desliga o gatilho usado por três das cinco técnicas conhecidas
session.upload_progress.enabled = Off

; PHP 8.5
fatal_error_backtraces = Off

No PHP-FPM, pm.max_requests = 1 faz cada processo morrer depois de uma requisição, o que impede o estado obsoleto de passar para a próxima. O custo em desempenho é alto e precisa de teste. A Imperva sugere ainda opcache.enable = 0 como medida temporária, também com teste antes. A session.upload_progress não resolve a CVE-2026-109618 por completo, porque a corrupção por falta de memória está no núcleo do Zend.

WAF ajuda enquanto o patch não chega. Cloudflare, Imperva e outros já publicaram regras para os vetores conhecidos. Variante nova passa por regra velha, então trate o WAF como ponte.

Sinais para procurar nos logs

• POST multipart com o campo PHP_SESSION_UPLOAD_PROGRESS, especialmente com corpo grande demais ou número anormal de campos.
• Erros Allowed memory size of ... bytes exhausted seguidos de queda de worker.
• Cookie PHPSESSID de tamanho absurdo na resposta. Uma das técnicas vaza cerca de 67 KB de memória do processo por esse cabeçalho.
• Rajadas de requisições para o mesmo endpoint vindas de um único IP, típicas de quem tenta acertar o mesmo processo várias vezes.

A pergunta que a maioria das empresas não consegue responder hoje

Todo time de segurança recebeu a mesma ordem nesta semana: corrigir o PHP. Ela pressupõe uma lista. Quais servidores rodam PHP, em que versão, expostos a quê.

A lista que existe é a do inventário oficial, e ela cobre o que alguém lembrou de registrar. O PHP que vai ser explorado nesta semana mora em outro lugar. O hotsite da campanha de 2019 que ninguém desligou. O ambiente de homologação que subiu junto com uma integração e ficou com IP público. O blog institucional numa hospedagem que o marketing contratou com cartão corporativo. O domínio que veio de brinde numa aquisição. O painel do appliance que a TI nunca pensou como servidor PHP.

Isso é shadow IT, e é a parte da superfície que mais pesa numa falha como a PHP2Shell, porque é justamente a que roda as versões mais antigas. O 7,9% de sites ainda em PHP 5 não está no servidor principal de ninguém.

Pior que o ativo esquecido é o ativo que ninguém sabe que não sabe. O esquecido alguém já conheceu um dia e dá para lembrar. O desconhecido entrou no ar por um caminho que não passou pela segurança, e nenhuma pergunta interna chega até ele, porque ninguém sabe que precisa perguntar.

Em dois casos documentados pela CSURFACE, uma instituição financeira de médio porte tinha 160 ativos externos no inventário oficial e a descoberta encontrou 271. Uma startup de SaaS B2B monitorava 85 e eram 570. O coordenador de cibersegurança de uma das maiores empresas do país resumiu o efeito numa frase: descobrir que monitorávamos apenas 15% da nossa real superfície de ataque.

Numa empresa assim, corrigir 100% da lista é corrigir 15% do problema.

Como clientes CSURFACE se anteciparam a esse tipo de problema

Para quem tem a CSURFACE rodando, a pergunta "onde temos PHP exposto e em que versão" já tem resposta antes de a falha ganhar nome. O trabalho que responde a ela roda o tempo todo, e a semana começa pela correção em vez da planilha.

Visão completa da superfície

A descoberta contínua mapeia a superfície externa a partir do que é público: domínios, subdomínios, certificados, blocos de IP, registros de DNS, empresas do grupo. O ponto de partida é o nome da empresa. A lista que a empresa entregou serve de comparação, para mostrar o que estava faltando nela. Cada ativo encontrado é identificado por tecnologia, o que inclui o PHP e sua versão quando o servidor a revela, o SAPI quando dá para inferir e os appliances que carregam PHP embutido.

Shadow IT e o que ninguém sabia que existia

É aí que aparecem o hotsite antigo, a homologação com IP público, o painel de appliance e o domínio da aquisição. Ativo descoberto sem dono vira item com contexto: onde está, quando apareceu, o que roda, quem provavelmente responde por ele. Quem avisa o cliente de que o servidor esquecido existe é a CSURFACE, antes de o atacante bater nele.

Inteligência de exploração cruzada com o inventário real

O ThreatSensor acompanha cada CVE com sinal de exploração, e a camada de threat intel cruza esse sinal com o que a descoberta já sabe. Quando uma CVE como a CVE-2026-109618 começa a ser avistada em ataque, os ativos do cliente que rodam a tecnologia afetada sobem para o topo da fila pelo sinal de exploração. Sem esperar o KEV e sem depender do CVSS.

Detecção rápida, com prova

A validação contínua confirma, de forma não destrutiva, se o ativo está de fato exposto nas condições em que está. A fila deixa de ser "todos os servidores com PHP" e vira "estes, que têm caminho aberto agora", com evidência para o time de infraestrutura agir e para o gestor reportar ao board. Depois do patch, a mesma validação confirma que a correção pegou.

O ativo que aparecer amanhã também entra

Corrigir tudo nesta quinta não protege contra o servidor que alguém sobe na terça seguinte com uma imagem Docker antiga. O monitoramento contínuo pega esse servidor no dia em que ele aparece. O pentest anual só o veria no ano que vem.

A PHP2Shell vai ser corrigida, como foram a Log4Shell e a React2Shell. A próxima falha desse tamanho vai encontrar a mesma pergunta sem resposta em quem não sabe o que tem na internet.

Se você quer saber hoje onde está o PHP da sua empresa, inclusive o que não está em lista nenhuma, a análise preliminar gratuita da CSURFACE devolve a primeira foto da sua superfície externa.

Perguntas frequentes

O que é PHP2Shell?

É o apelido de duas vulnerabilidades no interpretador PHP, a CVE-2026-109618 e a CVE-2026-109619, divulgadas em 21 de outubro de 2026 com nota 9,2 no CVSS v4.0. As duas permitem execução remota de código sem autenticação, disparada por uma requisição HTTP antes de o código da aplicação rodar.

Quais versões do PHP estão vulneráveis?

Todas as versões anteriores a 8.5.12, 8.4.27, 8.3.36 e 8.2.35, nos respectivos ramos. Os ramos 8.1, 8.0 e 7.4 receberam só backport em código-fonte. Versões mais antigas, até a 5.4, devem ser tratadas como vulneráveis e sem correção oficial. Em pacotes de distribuição Linux, confira o advisory do distribuidor, porque o backport pode manter o número de versão antigo.

A PHP2Shell já está sendo explorada?

Sim. A Amazon registrou tentativa de exploração em 17 de outubro, quatro dias antes do patch. O ThreatSensor mostra exploração confirmada da CVE-2026-109618, com 133 avistamentos até 22 de outubro, e mais de 300 repositórios públicos de PoC e ferramentas. Para a CVE-2026-109619 a exploração em campo ainda não foi detectada, mas há PoC pública desde 20 de outubro.

Desligar o session.upload_progress resolve?

Reduz o risco, sem resolver. A configuração remove o gatilho de três das cinco técnicas conhecidas, mas a corrupção por falta de memória da CVE-2026-109618 está no núcleo do PHP e tem outros caminhos. A única correção completa é atualizar e reiniciar todos os workers.

Meu site usa WordPress (ou Laravel, ou Magento). Estou exposto?

Se o PHP que roda por baixo está numa versão vulnerável, sim. A falha está no interpretador e é atingida antes de a aplicação rodar, então o framework e o CMS não interferem. Atualizar o WordPress não corrige a PHP2Shell, atualizar o PHP sim.

Como saber todos os servidores com PHP que a empresa tem na internet?

O inventário interno responde pelo que foi registrado. Para o que está publicado sem registro, como ambientes de teste, hotsites antigos, domínios de aquisição e appliances com PHP embutido, é preciso olhar de fora, a partir do que é público sobre a empresa. É o que a descoberta de ativos faz, e é o ponto de partida da gestão contínua de exposição.