PHP2Shell: como corrigimos duas CVEs críticas do PHP em mais de 70 ambientes em menos de 24h, sem indisponibilidade

TL;DR: Em 21/10, o PHP corrigiu o PHP2Shell: duas falhas críticas (CVSS 9.2) que permitem executar código remotamente, sem login, em quase todo PHP exposto na web, com tentativas de exploração registradas antes mesmo do patch. Em menos de 24h aplicamos contenção e correção definitiva em mais de 70 ambientes, sem indisponibilidade e sem nenhum cliente impactado. Explicamos as CVEs e o que tornou essa resposta possível: processo de SecOps definido, gates automatizados no pipeline e IA a serviço do time.

---

Ontem, 21 de outubro de 2026, foi um daqueles dias em que a segurança deixa de ser assunto de planejamento e vira corrida contra o relógio. O projeto PHP publicou correções para duas vulnerabilidades críticas, batizadas de PHP2Shell, que afetam praticamente toda instalação de PHP que atende requisições web. Na Europa, órgãos como o CERT-EU e o NCSC britânico chegaram a recomendar tirar sites do ar até a atualização — e vários governos fizeram exatamente isso.

Por aqui, seguimos outro caminho: mantivemos tudo no ar e corrigimos tudo mesmo assim. Em menos de 24 horas, mais de 70 ambientes sob nossa operação receberam contenção imediata e, em seguida, o patch definitivo, sem indisponibilidade e sem que nenhum cliente fosse impactado pelas CVEs.

Este artigo explica o que são as falhas, por que elas são tão graves e — principalmente — o que precisa existir antes de um incidente para que a resposta caiba em um dia. Por respeito aos nossos clientes, não citamos nomes nem detalhes de ambiente.

---

O que é o PHP2Shell e por que ele é tão grave?

O PHP2Shell é a combinação de duas CVEs no próprio interpretador PHP, ambas com nota 9.2 no CVSS v4.0 (a watchTowr, que confirmou a execução remota de código, chegou a avaliá-las como 10.0). O trecho vulnerável existe desde o PHP 5.4, de 2012 — ou seja, mais de uma década de versões afetadas.

As duas falhas compartilham o mesmo padrão: um erro fatal interrompe uma operação interna no meio do caminho, e o PHP depois trata aquele estado incompleto como se fosse válido.

	CVE-2026-109618	CVE-2026-109619
Natureza	Corrupção de memória por out-of-memory: a exaustão do memory_limit durante a inicialização da requisição deixa estruturas internas pela metade, que depois são processadas como válidas	Estado global "velho" (use-after-free): o PHP mantém referências a dados de uma requisição cuja memória já foi liberada, e uma requisição seguinte no mesmo worker as reutiliza
Gatilho	Requisição HTTP sem autenticação, com corpo montado para estourar a memória no ponto certo	Recursos ligados por padrão, como o upload progress de sessão (que roda mesmo sem session_start())
Impacto	Execução remota de código	Vazamento de memória do worker e execução remota de código
Onde afeta	PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP, LiteSpeed	PHP-FPM e mod_php

O detalhe que torna o PHP2Shell especialmente perigoso é onde ele acontece: no parsing do corpo da requisição, antes de qualquer linha da aplicação rodar. Não importa se o seu código é impecável, se o CMS está atualizado ou se o framework é o mais moderno. Se há PHP vulnerável atendendo HTTP, o caminho existe. As pesquisas listam como expostos WordPress, Drupal, Joomla, Magento, Nextcloud, Laravel, Symfony e praticamente tudo o que roda sobre PHP. A Palo Alto Networks contou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis no dia da divulgação.

As versões corrigidas, publicadas em 21/10, são 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Do 8.1 para trás, o projeto não gera mais releases — só patches de código-fonte, o que deixa quem roda versões antigas dependente do backport do fornecedor.

Quão rápido o ataque chegou?

Mais rápido que o patch. A linha do tempo pública mostra por que "atualizar na próxima janela de manutenção" não era uma opção:

• Agosto/2026 — a Calif e a Wiz Research encontram as falhas de forma independente e reportam ao PHP. As duas equipes usaram modelos de IA na pesquisa que levou às descobertas.
• 17/10 — a inteligência de ameaças da Amazon registra uma tentativa de exploração em seus honeypots, quatro dias antes da divulgação.
• 20/10 — detalhes vazam e a execução remota de código é confirmada publicamente.
• 21/10, 07h43 UTC — a Cloudflare reporta os primeiros ataques, antes do release oficial.
• 21/10, 14h UTC — o PHP publica as versões corrigidas. No mesmo dia, Datadog e watchTowr relatam varredura ampla e tentativas de exploração.

Há um contraponto honesto: em atualização de 22/10, a Sansec avaliou que a exploração em massa tende a ser menor do que se temia, porque as provas de conceito públicas costumam falhar contra um PHP em configuração padrão e, em geral, dependem de uma segunda falha na aplicação. Isso não muda a recomendação — "provavelmente difícil de explorar" não é um controle de segurança — mas ajuda a separar urgência de pânico.

O recado mais importante da linha do tempo está no primeiro item: as falhas foram encontradas com a ajuda de IA. A mesma capacidade está nas mãos de quem ataca. A janela entre a divulgação e a exploração está encolhendo, e a defesa precisa encolher na mesma proporção.

Como resolvemos em menos de 24 horas, sem derrubar nada?

Nosso time de SecOps identificou a falha assim que ela se tornou pública e foi registrada como CVE. Na sequência, analisamos o impacto em nossos clientes e mapeamos todos os ambientes possivelmente afetados, notificamos cada cliente de forma ordenada — começando pelos ambientes mais expostos — e iniciamos o plano de contenção antes mesmo do patch oficial. A partir daí, a resposta seguiu o processo que já usamos em todo incidente de segurança: duas trilhas em paralelo — conter agora e corrigir de vez — com gates de validação entre cada passo.

Primeiro passo: entender antes de agir

Em cerca de 20 minutos, consolidamos as informações de cinco fontes diferentes de threat intelligence — que divergiam entre si sobre o mecanismo de cada CVE e sobre o status de exploração — e cruzamos com a realidade dos ambientes. Essa análise trouxe a descoberta que mudou o plano: a imagem oficial de container, republicada naquela mesma manhã, ainda carregava o PHP vulnerável. A tag era nova; o interpretador, não.

Quem confiasse no "atualizei a imagem para a última versão" estaria, naquela tarde, publicando um ambiente vulnerável com sensação de segurança. É exatamente o tipo de armadilha que um processo maduro precisa pegar — e que só se pega olhando a versão em runtime, não o nome da tag.

Trilha 1: contenção imediata na borda

Enquanto o patch não existia de forma utilizável, aplicamos as mitigações recomendadas pelas fontes técnicas, começando pelos ambientes mais expostos:

• Bloqueio de requisições multipart/form-data no proxy reverso, à frente do PHP — o vetor que entrega o payload ao parser vulnerável;
• session.upload_progress.enabled desligado, fechando o caminho confirmado de uma das CVEs.

Cada mudança seguiu o mesmo rito: backup da configuração, teste de sintaxe dentro do próprio container antes de recarregar, validação de que as rotas públicas continuavam respondendo e de que o vetor passava a ser recusado. Em pouco tempo, a contenção estava ativa nos ambientes críticos. O custo foi conhecido e aceito: uploads administrativos ficaram temporariamente indisponíveis, sem qualquer efeito para o público dos sites.

Trilha 2: correção definitiva, guiada pelo pipeline

Em paralelo, preparamos a correção de verdade — e aqui o pipeline fez o trabalho pesado:

1. Gate de versão no build. Incluímos no build uma checagem que falha a imagem se o PHP estiver abaixo da versão corrigida. Na primeira execução, o gate fez exatamente o que devia: barrou a imagem oficial ainda vulnerável. Quando o upstream republicou a imagem com o PHP corrigido, o mesmo gate ficou verde sem intervenção manual.
2. Imagem fixada por digest. Tag é mutável; digest não. A imagem corrigida entrou referenciada pelo hash, eliminando a chance de um pull futuro trazer outra coisa.
3. Policy-as-code antes do deploy. Os manifestos passaram por validação automática de políticas de segurança e por dry-run no servidor antes de qualquer aplicação. Aproveitamos a janela para endurecer os workloads: containers sem root, sistema de arquivos somente leitura, probes e limites de recurso.
4. Rollout em ondas com validação. Desenvolvimento → QA → homologação → produção. Em cada onda, conferimos o PHP dentro do container em execução, o usuário do processo, reinicializações, violações de política, rotas respondendo e o vetor bloqueado. Só então a onda seguinte começava.

No ambiente mais exposto, a produção estava corrigida no mesmo dia em que o patch oficial foi publicado. Com o patch confirmado em todos os ambientes, removemos o bloqueio temporário de multipart e restauramos os uploads — mitigação boa é mitigação que sai do ar quando deixa de ser necessária, com registro de que existiu.

Uma decisão que não tomamos

No meio do incidente, surgiu a pergunta legítima: não seria hora de migrar para um runtime mais moderno, como o FrankenPHP, e ganhar performance de quebra? Avaliamos e descartamos. O ganho do FrankenPHP vem do worker mode, que mantém o processo vivo entre requisições — e aplicações que dependem de estado global zerado a cada request podem "herdar" o estado da requisição anterior. É, na camada da aplicação, a mesma classe de problema da CVE-2026-109619. Além disso, o próprio FrankenPHP estava na lista de runtimes afetados. Incidente não é hora de trocar arquitetura: é hora de reduzir variáveis.

Por que um processo de SecOps definido faz toda a diferença?

Nada do que descrevemos acima foi improvisado no dia 21. O que permitiu atravessar mais de 70 ambientes em menos de 24 horas foram decisões tomadas muito antes:

Sem processo	Com processo de SecOps definido
Descobrir no dia quais ambientes rodam PHP	Inventário vivo de imagens, runtimes e versões por ambiente
"Atualizei a imagem" como prova de correção	Gate que verifica a versão real e falha o build se estiver vulnerável
Mudança manual direto em produção	Rollout em ondas, pelo pipeline, com validação entre cada onda
Tags mutáveis no deploy	Imagens fixadas por digest
Mitigação que fica esquecida em produção	Mitigação com dono, registro e data para sair
Escolher entre "ficar vulnerável" e "tirar do ar"	Contenção na borda enquanto o patch percorre o pipeline

Essa é a diferença entre segurança como evento e segurança como processo. Quando o processo existe, o incidente vira execução de um roteiro conhecido. Quando não existe, cada ambiente vira uma investigação do zero — e, com dezenas de ambientes, a conta não fecha em 24 horas.

A mesma lógica de "tudo como código, nada manual" sustenta as plataformas que entregamos, como detalhamos no case de Kubernetes on-premises sem lock-in: quando a infraestrutura é declarativa e versionada, aplicar um patch em escala é um commit, não uma maratona.

Como a IA entra no processo de segurança, sem tirar o humano do controle?

Se as falhas foram encontradas com IA, a defesa também precisa usá-la. Mas o modelo que adotamos é claro: a IA amplia o alcance do time; quem decide é o time.

Na prática, durante o PHP2Shell, nossos agentes de IA trabalharam em quatro frentes:

• Inteligência de ameaças em minutos. Leitura e consolidação de advisories divergentes (fabricantes, pesquisadores, distribuições), destacando o que era consenso e o que ainda era incerto.
• Análise de exposição. Cruzamento das CVEs com o inventário: quais ambientes rodam PHP-FPM, em que versão, atrás de qual borda, com quais recursos ligados. Foi essa verificação que revelou a imagem oficial ainda vulnerável.
• Antecipação de efeitos colaterais. Antes de cada mudança, a pergunta "o que isso quebra?": o bloqueio de multipart afeta quais fluxos? O endurecimento do container quebra algum script de inicialização? A migração de runtime traz um risco novo? Problemas previstos antes do deploy são problemas que o cliente nunca vê.
• Execução e acompanhamento. Preparação das mudanças, acompanhamento dos pipelines e validação pós-deploy em cada onda, com evidências registradas no ticket.

Duas coisas nunca saíram das mãos humanas: a aprovação de qualquer mudança em produção e a decisão sobre os trade-offs (aceitar uploads indisponíveis por algumas horas, adiar uma melhoria de rede para depois do incidente, descartar a troca de runtime). Os gates automatizados — gate de versão, políticas como código, validação em ondas — existem justamente para que nem a IA nem a pressa do incidente consigam empurrar para produção algo que não foi verificado.

É assim que a análise de vulnerabilidades deixa de ser um relatório mensal e passa a ser contínua: scanners e inventário apontando onde está o risco, o pipeline impedindo que o risco volte, e a IA reduzindo de horas para minutos o tempo entre "saiu uma CVE" e "sabemos exatamente o que fazer". Se a sua operação ainda não mede métricas como tempo de detecção e tempo de correção, vale começar pela base — observabilidade self-hosted é parte do mesmo alicerce.

O que fazer agora se você roda PHP?

Se o seu ambiente ainda não foi tratado, a ordem de prioridade é:

1. Atualize o PHP para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou o pacote com backport do seu fornecedor). É a única correção definitiva.
2. Confira a versão em runtime, não a tag da imagem: php -v dentro do container em execução.
3. Se não der para atualizar já, contenha: bloqueie multipart/form-data na borda onde uploads não são necessários e desligue session.upload_progress.enabled, reiniciando todos os workers.
4. Procure sinais de exploração: erros fatais de memória esgotada reportados como "Unknown on line 0", segfaults inesperados e, sobretudo, processos web abrindo shell — o indicador mais direto de comprometimento.
5. Depois do patch, remova as mitigações temporárias e registre o que foi feito.

Conclusão

O PHP2Shell vai entrar para a lista das vulnerabilidades que marcaram época, ao lado de nomes que todo time de infraestrutura conhece. Mas a lição que ele deixa não é sobre PHP: é sobre o tempo que uma operação leva para sair da divulgação de uma CVE e chegar ao patch em produção.

Corrigir mais de 70 ambientes em menos de 24 horas, sem indisponibilidade e sem impacto para nenhum cliente, não foi sorte nem heroísmo. Foi o resultado de um time treinado, de uma metodologia de SecOps que separa contenção de correção, de pipelines que verificam em vez de confiar, e de IA usada como multiplicador — com o humano sempre no comando das decisões que importam.

A próxima CVE crítica já está sendo encontrada, provavelmente com ajuda de IA. A pergunta não é se ela vai chegar, e sim quanto tempo a sua operação vai levar para responder.

---