Insights · Segurança

PHP2Shell: o que fazer se o seu sistema ainda roda PHP 7 ou 8.1, e como sair do PHP legado

Publicado em 22 de outubro de 2026

Em 21 de outubro de 2026, o projeto PHP corrigiu duas falhas críticas que podem permitir executar código no servidor sem login. Se o seu sistema roda uma versão com suporte, o caminho é atualizar hoje. Se roda PHP 7.4, 8.0 ou 8.1, não existe versão oficial corrigida: a CISA pede tirar esses sistemas do ar até corrigir ou atualizar, e a escolha seguinte fica entre backport, upgrade de versão e modernização. Este texto serve para as duas situações.

As fontes são o anúncio do projeto PHP, os alertas de agências de segurança e os textos de quem participou da descoberta ou monitora ataques, todos com link e data. Citações em tradução nossa. A Ithaca não participou da descoberta nem da correção dessas falhas.

O que é o PHP2Shell

PHP2Shell é o apelido de duas vulnerabilidades no próprio PHP, a CVE-2026-109618 e a CVE-2026-109619. O nome aparece no alerta da NSA de 21 de outubro de 2026, segundo o qual as falhas estão no PHP, e não na aplicação hospedada nem na configuração dela. Pelo alerta, elas podem permitir que um atacante assuma o servidor web sem acesso prévio e sem autenticação.

O anúncio de segurança do projeto PHP, da mesma data, descreve as duas:

• CVE-2026-109618, corrupção de memória no tratamento de falta de memória (OOM). Quando falta memória, o PHP pode ser interrompido com dados internos da requisição só parcialmente inicializados, e a limpeza da requisição pode tratar esses dados inválidos como válidos.
• CVE-2026-109619, estado global obsoleto. Um estado interno que pertence a uma requisição pode sobreviver depois que a memória por trás dele foi liberada. Uma requisição seguinte, atendida pelo mesmo worker, pode usar esse estado antes que a inicialização normal o reponha.

O Cyber Centre do Canadá classifica as duas como use-after-free (CWE-416). No aviso prévio de 20 de outubro, o projeto PHP deu às duas a nota 9,2 na escala CVSS v4.0.

Quem é afetado

Segundo o projeto PHP, toda instalação que atende requisições web está em risco, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php: há um exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação rodar. A PHP Foundation acrescenta que, no PHP-FPM, a execução remota foi confirmada por caminhos que passam pelo código da aplicação.

Três consequências práticas:

• Código bem escrito não basta. A falha está no motor da linguagem. O Wiz, que demonstrou o ataque em WordPress, Drupal e Joomla, afirma que até uma aplicação "Hello World" numa versão afetada pode ser vulnerável.
• PHP 8.1 e anteriores também estão afetados, e o projeto PHP não publica mais versões para eles. O CERT-EU põe esses ramos em fim de vida na lista de produtos afetados. Segundo o Wiz, versões desde o PHP 5.4 têm pelo menos um dos problemas.
• O PHP pode estar onde ninguém olha. O NCSC-NL lembra que o PHP vem embutido em appliances, equipamentos de rede, interfaces de gestão e produtos de terceiros, nos quais o administrador pode não conseguir atualizar o PHP diretamente.

No dia 21, o CERT-EU registrava provas de conceito em circulação. A CISA e o Cyber Centre diziam não ter observado exploração ativa até a publicação dos alertas, e o Cyber Centre avisava que isso podia mudar rápido. No mesmo dia, a Amazon relatou tentativas de exploração contra os sensores-isca (honeypots) dela desde 17 de outubro, quatro dias antes do anúncio, e escreveu que, depois da correção, a falha passou a ser explorada em larga escala. A própria Amazon diz que não estava claro se as tentativas anteriores ao anúncio teriam dado certo em um sistema real.

Como verificar a versão do PHP

• No terminal do servidor: php -v mostra a versão do PHP de linha de comando, como descreve o manual do PHP. O manual mostra que a saída traz também o SAPI, no exemplo cli. Para saber a versão que atende o site, confira também pelo servidor web.
• Pelo servidor web: um arquivo com <?php phpinfo(); mostra a versão e a configuração do PHP que atende o site. Apague o arquivo em seguida: segundo o manual, a página lista opções de compilação, extensões, ambiente, configuração e cabeçalhos HTTP, e isso não deve ficar público.
• No painel da hospedagem: em hospedagem compartilhada, procure a versão do PHP no painel ou pergunte ao suporte qual versão atende o seu site e quando o pacote corrigido entra.
• No WordPress: a tela Ferramentas > Diagnóstico > Informação (Tools > Site Health > Info, na interface em inglês), seção Servidor, mostra a configuração do servidor, e a aba Status avisa quando o site roda uma versão desatualizada do PHP, segundo a documentação do WordPress.

Se o PHP veio de pacote da distribuição Linux, não pare no número da versão. Segundo o projeto PHP, distribuições e fornecedores de suporte estendido (LTS) receberam as correções antes do anúncio, e é com eles que se confirma o pacote corrigido. Confira o aviso de segurança do seu fornecedor.

Quais versões estão corrigidas

As versões corrigidas saíram em 21 de outubro de 2026. Os prazos vêm das páginas de versões suportadas e de ramos sem suporte do projeto PHP. O 8.2.35 corrige o PHP2Shell, mas o ramo 8.2 sai do suporte em 31 de dezembro de 2026. Na nossa leitura, quem sobe agora para o 8.2 ganha pouco tempo, e quem pode deve mirar o 8.3 ou uma versão mais nova.

Quem usa o repositório voluntário rpms.remirepo.net deve trocar para os pacotes da distribuição ou compilar a partir do código-fonte, pede o projeto PHP, porque o repositório não teria atualização no dia do anúncio.

O que fazer se não dá para atualizar hoje

Só a atualização resolve. Nas palavras do projeto PHP, as medidas abaixo reduzem a exposição a caminhos de ataque específicos, mas não deixam a instalação segura.

• Inventário primeiro. NSA, CISA e NCSC-NL pedem o mesmo começo: listar tudo o que roda PHP, a começar pelo que está exposto à internet, incluindo produtos de terceiros, appliances e imagens de contêiner.
• Tirar do ar ou isolar. A NSA diz que, se a atualização imediata não for viável, o sistema deve sair do ar até ser totalmente mitigado. A CISA pede o mesmo a quem não consegue atualizar já ou continua no PHP 8.1 ou anterior: tirar do ar os sistemas em PHP até corrigir ou atualizar. O CERT-EU e o Cyber Centre falam em isolar da rede pública as aplicações expostas até a correção.
• Backport do fornecedor. Para PHP 8.1 e anteriores, distribuições e fornecedores de LTS oferecem correções retroportadas. O projeto PHP publicou backports mínimos de código-fonte para 7.4, 8.0 e 8.1, para quem compila o PHP ou não tem fornecedor de LTS.
• Ajustes de configuração do PHP. O anúncio lista medidas para cada falha, entre elas memory_limit=-1, de preferência definido de um jeito que a aplicação não consiga mudar e com limite de memória no contêiner ou no cgroup, post_max_size baixo e session.upload_progress.enabled=0 com reinício de todos os workers. Ele também diz onde aplicar cada uma e o que não usar no lugar. Cada medida bloqueia só caminhos de ataque já confirmados. Aplique a partir do texto do anúncio, não de um resumo.
• Limites no servidor web, no proxy ou no WAF. O projeto PHP sugere limitar no servidor web ou no proxy o tamanho da requisição decodificada, a quantidade de campos, de partes multipart e de cabeçalhos, e a profundidade de aninhamento. A CISA diz que um WAF pode dar alguma proteção até a atualização. Segundo o BleepingComputer, a Cloudflare publicou regras de WAF para os métodos de ataque conhecidos e chamou essas proteções de temporárias.
• Mais logs e mais atenção. A NSA pede registro reforçado no ambiente. O Cyber Centre pede revisão dos logs de servidor web, aplicação, autenticação e endpoint, e investigação de processos, comandos, arquivos, contas ou conexões de saída inesperados ligados ao PHP. O Wiz aponta como sinais requisições multipart incomuns seguidas de erros de limite de memória ou de respostas HTTP 500 repetidas, e cookies PHPSESSID grandes ou malformados. A CISA pede atenção a workers do PHP que abrem shells ou baixam ferramentas, e a Amazon sugere começar a investigação em 17 de outubro, não na data do anúncio.

Preso numa versão sem suporte: backport, upgrade ou modernização

Entre as medidas, a NSA inclui substituir serviços de PHP em fim de vida, que não vão ser compatíveis com a correção. Para quem roda 7.4, 8.0 ou 8.1, a urgência desta semana esconde uma decisão maior. São três caminhos, e eles se combinam.

Na nossa leitura, a ordem que faz sentido é fechar a porta desta semana primeiro (backport, isolamento ou, como pede a CISA para versões sem suporte, tirar do ar) e fazer o upgrade ou a modernização em seguida, para não depender de backport na próxima falha. Lift and shift, sozinho, não entra na lista: levar o sistema para outro servidor sem mudar a aplicação não muda o código que prende o sistema à versão antiga (lift and shift vs modernização).

Por que "só atualizar o PHP" trava em código legado

• Extensões e funções removidas. O PHP 7.0 removeu extensões como mysql e ereg, segundo o manual do PHP. O PHP 8.0 removeu funções como each() e create_function() e mudou outros comportamentos, listados nas mudanças incompatíveis do PHP 8.0. Quem está no 7.4 ainda tem essa passagem pela frente.
• Dependências. Antes do upgrade, confira que versões do PHP o framework e cada biblioteca aceitam. Se algum deles só roda na versão velha, o upgrade do PHP passa a incluir o upgrade dele, com as mudanças de API que vierem junto.
• Falta de testes. Sem testes que fixem o comportamento atual, não há como confirmar antes do deploy o que o upgrade mudou. Por isso, no guia de modernização, o passo que vem antes de mexer é fixar o comportamento atual com testes de caracterização.
• Conhecimento concentrado. Quando só uma ou duas pessoas sabem por que cada parte existe, o upgrade espera a agenda delas (falta de desenvolvedor para sistemas antigos).

O próprio projeto PHP passou por isso. Segundo a PHP Foundation, os primeiros sinais do problema por trás da CVE-2026-109618 apareceram em 2024, durante uma auditoria externa, e a correção travou e recomeçou por meses porque cada solução trazia um efeito colateral: quebra de compatibilidade, risco novo de negação de serviço ou mudança em extensões de terceiros. A fundação chama o atraso de falha estrutural. Na nossa leitura, é o mesmo mecanismo da dívida técnica em sistemas legados: toda opção de correção tinha um custo, e a decisão foi ficando para depois (o que é um sistema legado e custo da dívida técnica).

O que a IA mudou nessa história

Segundo o Wiz, modelos de IA de fronteira ajudaram a achar as falhas e tornaram prático montar exploits que funcionam em alvos diferentes. O texto do Wiz diz que, com esses modelos e as ferramentas certas, um pesquisador fez numa semana o que antes levaria meses de trabalho de um time de primeira linha. A PHP Foundation conta a outra parte: a Calif e a OpenAI reportaram o mesmo problema de raiz em 11 de agosto, o Wiz mandou outros vetores de ataque em 24 de agosto, e a pesquisa assistida por IA também aumentou o volume de relatos que o time de segurança do PHP recebe. A IA ajuda a validar e agrupar relatos, mas, segundo a fundação, uma pessoa decide cada caso e trabalha em cada correção.

Na nossa leitura, o que muda para quem tem código legado é o custo de quem ataca. Uma falha antiga e difícil de explorar ficava protegida, na prática, pela própria dificuldade, e o Wiz escreve que essa complexidade pode deixar de ser uma barreira. Isso não quer dizer que todo sistema antigo vai ser atacado amanhã. Quer dizer que adiar a atualização ficou mais caro.

O outro lado também vale. As mesmas ferramentas que leem código antigo em busca de falhas também podem ser usadas para documentar regras de negócio, escrever testes e trocar o sistema por partes. A diferença está em quem supervisiona e no que fica registrado (só aprove o que você sabe explicar e segurança em agentes de IA para código).

Onde a Ithaca entra

A Ithaca trabalha com modernização de sistemas legados numa plataforma de desenvolvimento agentic no nível 4 de autonomia: os agentes de código leem o sistema atual, escrevem testes que fixam o que ele faz hoje e constroem cada parte nova, e o time decide a ordem e lê o que vai para produção. Cada sessão fica registrada. O método para sistemas que não podem parar está em modernização de sistemas legados com IA, sem parar a operação.

Isso não substitui a correção desta semana. Para o PHP2Shell, o caminho é o deste texto: atualizar, aplicar o backport ou isolar.

Se o sistema ficou preso numa versão sem suporte e cada atualização parece um projeto em si, o próximo passo é mapear o que ele faz e por onde começar a troca. Agendar demonstração

Perguntas frequentes

Leia também

• Sistema legado: o que é, sinais de risco e quando modernizar
• Como modernizar um sistema legado: guia passo a passo
• Custo da dívida técnica: onde aparece e como medir
• Lift and shift vs modernização: o que muda
• Falta de desenvolvedor COBOL, Delphi e VB6: o que fazer
• Segurança em agentes de IA: o limite fica fora do agente
• Modernização de sistemas legados com IA, sem parar a operação

Fontes

• PHP. Security advisory: Critical remote code execution vulnerabilities, update now. php.net, 21 out. 2026.
• PHP. Upcoming Critical PHP Security Release. php.net, 20 out. 2026.
• PHP. Supported Versions e Unsupported Branches. php.net, consultadas em 21 out. 2026.
• PHP. Manual do PHP: Command line options, phpinfo, Removed Extensions and SAPIs (PHP 7.0) e Backward Incompatible Changes (PHP 8.0). Consultado em 21 out. 2026.
• The PHP Foundation. Today's PHP Security Release, and How We're Strengthening PHP Security. Blog da PHP Foundation, 21 out. 2026.
• NSA. NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities. Comunicado à imprensa, 21 out. 2026.
• CISA. Critical Vulnerabilities in PHP Require Immediate Patching. Alerta, 21 out. 2026.
• CERT-EU. Security Advisory 2026-018: Critical Vulnerabilities in PHP. 21 out. 2026.
• Canadian Centre for Cyber Security. AL26-026: Critical vulnerabilities impacting PHP. 21 out. 2026.
• NCSC-NL. php2shell, repositório de informação operacional no GitHub, consultado em 21 out. 2026.
• Sagi Tzadik, Shir Tamari, Nir Ohfeld e Tomer Schwartz (Wiz Research). Post sobre o PHP2Shell no blog do Wiz, 21 out. 2026. Texto de empresa de segurança sobre a própria pesquisa.
• CJ Moses (Amazon). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog, 21 out. 2026. Texto de empresa sobre a própria telemetria.
• Sergiu Gatlan. PHP ships emergency patches for critical PHP2Shell flaws. BleepingComputer, 21 out. 2026.
• WordPress. Site Health screen. Documentação do WordPress, consultada em 21 out. 2026.