CVE-2026-109618 (PHP2Shell): Guia para Gestores e CTOs

A CVE-2026-109618 e sua irmã, a CVE-2026-109619, formam o par apelidado de PHP2Shell: duas falhas no núcleo do PHP que permitem executar código no servidor sem login nenhum. Se a sua empresa tem site, loja, Moodle ou webhook em PHP, a pergunta é de negócio: quanto do seu faturamento roda num interpretador que ficou vulnerável na semana passada? Este guia traduz o incidente para quem decide.

TL;DR

• A CVE-2026-109618 (corrupção em falta de memória) e a CVE-2026-109619 (estado global obsoleto entre requisições) têm nota CVSS 4.0 de 9,2 e dispensam autenticação.
• Os identificadores vazaram em 20/10/2026; a correção saiu em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• PHP 7.4 a 8.1 só tem backports mínimos de código-fonte. PHP 5.4 a 7.3 não tem correção nenhuma.
• Ajustes de configuração (memory_limit=-1, session.upload_progress.enabled=0) reduzem o risco, mas não resolvem. Só atualizar resolve.
• Em 23/10 saiu um alerta extra, a CVE-2026-115560, de vetor improvável.

O que é a CVE-2026-109618 e por que ela virou pauta de diretoria

Em linguagem de gestão: a CVE-2026-109618 é uma porta dos fundos no motor que executa o seu sistema, e não no seu sistema. Não importa se o ERP é impecável ou se o WordPress e o Moodle estão atualizados. A falha mora no interpretador PHP, a camada embaixo de tudo.

Segundo o aviso oficial do PHP, a CVE-2026-109618 acontece quando o tratamento de falta de memória (out-of-memory, ou OOM) interrompe o PHP enquanto dados internos da requisição ainda estão pela metade. Na limpeza, o PHP trata esse lixo como se fosse válido. Um atacante que provoque isso de propósito consegue corromper memória e, a partir daí, executar comandos.

A CVE-2026-109619 é outro caminho para o mesmo destino: um estado interno da requisição sobrevive depois que sua memória foi liberada (use-after-free), e a próxima requisição no mesmo processo usa esse resto. O PHP confirma também vazamento de memória.

Por que o 9,2 importa mais que o número

Nota alta aparece todo mês. O que coloca o PHP2Shell em outro patamar são três fatores:

• Sem autenticação: basta uma requisição HTTP, sem senha nem sessão.
• Antes do seu código rodar: no Apache com mod_php, o PHP diz que há exploit demonstrado em que a requisição dispara o ataque antes de qualquer linha da aplicação.
• Base instalada gigantesca: a Tenable cita a W3Techs: PHP roda em 69,3% dos sites cuja linguagem de servidor é conhecida.

Detalhe de rigor: os identificadores que vazaram traziam nota 10,0, depois corrigida para 9,2 pela PHP Foundation, segundo a Tenable. Fornecedor que ainda fala em "nota 10" está lendo fonte velha.

Linha do tempo: do vazamento ao alerta extra de 23/10

As datas da CVE-2026-109618 definem desde quando a sua empresa está exposta e o que o seu fornecedor deveria ter feito em cada dia.

Data	O que aconteceu	Fonte
17/10/2026	Amazon Threat Intelligence registra tentativa de exploração em sua rede de honeypots MadPot, quatro dias antes da divulgação	Tenable
20/10/2026	Identificadores vazam; PHP antecipa a release de 22 para 21/10 e publica aviso prévio	Tenable, watchTowr, Huntress
21/10/2026	Saem 8.5.12, 8.4.27, 8.3.36 e 8.2.35; CISA emite alerta; watchTowr observa exploração em seus sensores	php.net, CISA, watchTowr
23/10/2026	Unit 42 atualiza o boletim; PHP publica alerta informativo da CVE-2026-115560	Unit 42, php.net

A Unit 42, da Palo Alto Networks, informou que o Cortex Xpanse identificou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis. É estimativa de superfície exposta, não de servidores invadidos. Outras medições citadas pela Tenable ficaram entre 1,3 e 1,9 milhão de hosts. A ordem de grandeza muda; a conclusão, não.

Sobre ataques reais, as fontes divergem. A Huntress não tinha visto exploração em seus parceiros até 20/10. A watchTowr relata exploração em seus honeypots desde 21/10. Até 23/10, as falhas ainda não estavam no catálogo KEV da CISA. Para quem decide: o exploit existe, foi demonstrado e já há gente testando. Esperar "ataque em massa confirmado" é esperar tarde demais.

Quem é afetado pela CVE-2026-109618 no PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed

O PHP foi direto: toda instalação que atende requisições web está em risco. A lista oficial cita cinco formas de rodar PHP, e saber qual a sua empresa usa muda a urgência e o tipo de trabalho.

Mapa de risco por forma de execução

Forma de execução	Onde costuma aparecer	Leitura de risco
Apache + mod_php	Servidores antigos, cPanel legado, VPS montada "à mão"	Maior risco segundo o PHP: exploit demonstrado antes do código da aplicação
PHP-FPM	Nginx, hospedagem gerenciada moderna, Moodle e Laravel em produção	Afetado; o PHP confirmou execução de comandos via processamento de upload
php-cgi	Ambientes legados, alguns painéis Windows	Trate como exposto
FrankenPHP	Stacks modernas, workers persistentes, containers	Afetado; workers de longa duração exigem reinício após o patch
LiteSpeed (LSAPI)	Hospedagens compartilhadas e painéis comerciais	Afetado; depende do fornecedor liberar o pacote

Se você não sabe qual é a sua linha nessa tabela, esse é o primeiro achado do incidente. Em mais de 15 anos operando servidores PHP, Moodle e integrações com a API oficial do WhatsApp, vejo o inventário como o elo mais fraco, não o patch.

O que quase ninguém lembra de checar

A Datadog alerta que o PHP de linha de comando e o que atende a web podem ter versões diferentes. A equipe roda php -v, vê versão nova e conclui que está tudo certo, enquanto o FPM segue no binário antigo.

Também entra o equipamento que você nem sabe que roda PHP: fabricantes de appliances de rede publicaram avisos próprios sobre o PHP2Shell. Painel de firewall, NAS e sistema de câmera entram no inventário.

Versões corrigidas da CVE-2026-109618 e o problema real: o PHP antigo

A decisão mais cara mora aqui. Há correção oficial para quatro ramos:

Ramo	Versão corrigida	Situação
8.5	8.5.12	Suportado
8.4	8.4.27	Suportado
8.3	8.3.36	Suportado
8.2	8.2.35	Só segurança; fim de vida em 31/12/2026
7.4, 8.0, 8.1	Sem release oficial	Só backport mínimo de código-fonte ou pacote de distribuição/fornecedor LTS
5.4 a 7.3	Nenhuma	Sem correção do projeto PHP

Repare no 8.2: quem vai para 8.2.35 resolve a CVE-2026-109618 hoje, mas o ramo morre em 31/12/2026, segundo o php.net. É correto como emergência, não como plano.

O dilema do PHP 7.x

Sistema preso em PHP 7.x é comum: ERP sob medida de dez anos atrás, Moodle nunca migrado, loja com plugin que "quebra se mexer". O projeto PHP publicou backports mínimos para 7.4, 8.0 e 8.1 no GitHub, para quem compila do código-fonte. Distribuições Linux e fornecedores de suporte estendido também liberaram pacotes corrigidos, às vezes sem mudar o número da versão, o que confunde scanners e auditorias.

Na prática, o gestor tem três caminhos para PHP antigo:

1. Pacote corrigido da distribuição, quando existe: o mais rápido e seguro.
2. Compilar com o backport: exige quem saiba compilar e manter PHP. É dívida técnica nova.
3. Migrar de versão: o caminho certo, que raramente cabe numa semana.

Para PHP 5.4 a 7.3, não há caminho 1 nem 2. Sobra isolar o sistema da internet ou migrar.

Mitigações: o que reduz o risco e o que é falsa sensação de segurança

O PHP publicou ajustes de configuração contra a CVE-2026-109618 e a CVE-2026-109619 para quem não consegue atualizar imediatamente, e fez questão de dizer que não substituem a atualização. Use como ponte, nunca como destino.

Para a CVE-2026-109618

• memory_limit = -1 de forma que a aplicação não consiga sobrescrever. No PHP-FPM, isso é feito com php_admin_value[memory_limit] = -1 no pool.
• post_max_size baixo: 8M sem upload, 32M com upload, com upload_max_filesize abaixo dele.
• Limites de tamanho, quantidade de campos, partes e profundidade no servidor web ou proxy.
• Limite de memória por container ou cgroup que derrube só o processo afetado.

Para a CVE-2026-109619

• session.upload_progress.enabled = 0 no php.ini ou no pool do FPM, e reiniciar todos os workers. O PHP avisa: não confie em ini_set() nem em .user.ini.
• No PHP 8.5, também fatal_error_backtraces = 0.
• Esconder erros com @ não ajuda.

Armadilhas que derrubam servidores

memory_limit=-1 sem limite de container troca um risco por outro: um script mal escrito consome toda a RAM e derruba o banco junto. E o PHP desaconselha RLIMIT_AS e RLIMIT_DATA, que podem provocar justamente a falha de alocação que o exploit usa.

WAF ajuda, mas tem limite. A Cloudflare publicou regras para os vetores conhecidos e as chamou de paliativo, e elas só protegem o tráfego que passa por ela: o IP direto do servidor segue aberto se o firewall não fechar. Por fim, desligar session.upload_progress quebra barras de progresso de upload. Avise o time de produto antes.

CVE-2026-115560: o alerta de 23/10 e por que ele não muda a prioridade

Dois dias depois do patch, o PHP publicou um aviso informativo sobre a CVE-2026-115560, outra falha ligada a sessão e upload progress, que afeta inclusive as versões já corrigidas. A boa notícia: o vetor é improvável. Segundo o php.net, só se aplica se a aplicação configura session.serialize_handler como php_binary ou php_serialize, troca para php em tempo de execução com ini_set() antes do session_start() e mantém o upload progress ligado.

A correção vem na próxima release regular. Até lá, vale a mesma mitigação: session.upload_progress.enabled=0. O The Hacker News cobriu o alerta.

A CVE-2026-115560 não é motivo para adiar o patch da CVE-2026-109618 e quem já desligou o upload progress como mitigação ganhou proteção para as duas.

Decisões de negócio: o que perguntar ao seu time ou fornecedor esta semana

O papel do gestor não é compilar PHP, é fazer as perguntas certas e cobrar prazo. Esta é a lista que eu levaria para a reunião.

As sete perguntas

1. Inventário: quais servidores, containers e appliances rodam PHP? Inclui o site institucional que a agência fez em 2019?
2. Versão real da web: qual versão do PHP atende as requisições, não a do terminal?
3. Status do patch: já estamos em 8.5.12, 8.4.27, 8.3.36 ou 8.2.35? Os workers foram reiniciados?
4. Imagens Docker: as imagens foram reconstruídas e reimplantadas, ou o container antigo continua no ar?
5. Legado: o que está em PHP 8.1 ou abaixo, e qual dos três caminhos vamos seguir para cada sistema?
6. Indícios: alguém olhou logs de erro com "Unknown on line 0", falhas de segmentação no Apache e shells disparados pelo processo web desde 17/10?
7. Responsável e prazo: quem assina cada item e até quando?

Quando atualizar já e quando não sair atualizando

Atualize no mesmo dia tudo em 8.2 a 8.5 exposto à internet: é versão de correção, com risco baixo de regressão.

Não salte de PHP 7.4 para 8.4 numa sexta à noite por pânico: mudança de ramo quebra plugin e código antigo. Isole primeiro (VPN ou lista de IPs), aplique pacote corrigido do fornecedor se existir e planeje a migração com teste.

Não confie em "minha hospedagem já corrigiu a CVE-2026-109618" sem prova. Peça a versão e a data do reinício por escrito.

Onde o incidente pode estar escondido

Webhooks são ponto cego clássico: o endpoint que recebe eventos da API oficial do WhatsApp ou do gateway de pagamento é público por definição. Se roda em PHP, vai para o topo da lista.

Homologação também: muita empresa protege produção e esquece o staging com a mesma base copiada e PHP velho. Para fechar as portas, o checklist de hardening de servidor Linux cobre o que vem depois do patch.

Custos: quanto custa agir agora versus depois

Não vou inventar valor médio de incidente; varia demais por porte e setor. Mas dá para comparar os tipos de custo da CVE-2026-109618, que é o que importa para priorizar.

Agir agora custa horas de equipe técnica: inventário, atualização, reinício, revisão de logs. Em 8.2+, costuma ser trabalho de dias. Em 7.x, soma-se isolamento e projeto de migração.

Agir depois custa o que custa qualquer execução remota de código: servidor invadido com os privilégios do processo web, banco e credenciais expostos, possível ransomware e, havendo dados pessoais, obrigações pela LGPD. O post sobre plano de resposta a vazamento de dados mostra quem avisa quem e em que prazo.

Há também um custo escondido: dívida técnica de versão. Uma empresa em PHP 8.3 resolve a CVE-2026-109618 numa janela de manutenção. Uma empresa em PHP 7.2 descobre que não tem patch e precisa de projeto. Para pequenas empresas sem time de segurança, a priorização segue a lógica de ransomware em pequenas empresas: o que fechar primeiro.

Se o seu time não tem fôlego para separar o urgente do importante, é aí que uma consultoria técnica independente se paga: alguém de fora mapeia, prioriza e entrega uma ordem de ataque.

Como a Agathas Web resolve isso

A Agathas Web opera servidores PHP desde 2008: hospedagem gerenciada, Moodle em produção, sistemas em PHP e Laravel e a API oficial do WhatsApp. Pela consultoria da Agathas Web, o trabalho começa pelo que os boletins não fazem: olhar o seu ambiente.

O que está incluso

• Inventário de exposição: servidores, containers, homologação, webhooks e appliances com PHP, e a versão real que atende a web.
• Matriz de decisão por sistema: atualizar já, aplicar pacote corrigido do fornecedor, compilar backport, isolar ou migrar, com custo e risco de cada opção.
• Mitigação segura enquanto o patch não sai, sem derrubar o servidor por falta de RAM.
• Busca por indícios nos logs e processos desde 17/10.
• Plano de migração para o que está em PHP 8.2 ou abaixo, antes do fim de vida de 31/12/2026.

Como funciona na prática

Quem conduz é o sócio/CTO, não um júnior. Para a CVE-2026-109618 o escopo é curto: diagnóstico, prioridades e execução do urgente. Se fizer sentido ir além, vira um diagnóstico técnico completo de 4 a 6 semanas, com relatório executivo e plano de ação, ou liderança técnica fracionada (CTO sob demanda).

Como contratar

Pela página de consultoria em tecnologia e segurança, conte o cenário (quantos sistemas, qual hospedagem, qual PHP) e respondemos com caminho e escopo. A recomendação vem do diagnóstico, não de pacote pronto.

Conclusão: a CVE-2026-109618 é um teste de governança, não só de patch

A CVE-2026-109618 vai ser corrigida na maioria dos servidores nas próximas semanas. Fica a pergunta: quanto tempo a sua empresa levou para saber onde roda PHP, em qual versão e quem responde por ele?

Resumo para levar à diretoria:

• Atualize hoje tudo em 8.2 a 8.5 e reinicie os workers.
• Trate mitigações como ponte, nunca como solução.
• Para PHP 8.1 ou anterior, isole primeiro e decida o caminho sistema por sistema.
• Planeje sair do 8.2 antes de 31/12/2026.
• Olhe os logs desde 17/10 em busca de indícios.

Se quiser um olhar externo para fazer esse inventário e montar a ordem de ataque, a consultoria da Agathas Web atende exatamente esse cenário.