PHP2Shell: PHP lança correção para duas falhas críticas — veja como atualizar

O que são as duas falhas

• CVE-2026-109618, "RCE por corrupção em falta de memória": se o PHP fica sem memória no meio do processamento de uma requisição, dados internos podem ficar pela metade, e a limpeza no fim da requisição trata esse lixo como válido. O processamento de requisições multipart é um dos gatilhos.
• CVE-2026-109619, "RCE por estado global obsoleto": dados internos da requisição sobrevivem depois de a memória ser liberada, e uma requisição seguinte no mesmo processo pode usá-los. Um dos caminhos confirmados é o acompanhamento de progresso de upload por sessão (session.upload_progress).

O changelog do PHP trata as duas na mesma correção, "Avoid state corruption via bailout". A exploração exige acertar detalhes de cada build e vencer uma disputa de memória; quando erra, o processo costuma cair. Por isso, uma onda de respostas 5xx vindas do PHP pode ser sinal de tentativa de ataque.

Quem está exposto

Qualquer PHP que atenda requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP ou LiteSpeed. O PHP aponta o mod_php como o de maior risco, porque a requisição pode agir antes de o código da aplicação rodar. A existência de um endpoint de upload na sua aplicação não é pré-requisito.

Se não dá para atualizar hoje

O PHP é claro: atualizar é a única correção completa. As medidas abaixo reduzem a exposição, mas não tornam o servidor seguro.

• session.upload_progress.enabled = 0 (já vem ligada por padrão) reduz o risco da CVE-2026-109619. Aplique no php.ini ou no pool, reinicie todos os processos e não confie em ini_set() nem em .user.ini com o PHP-FPM. Não cobre outras variantes.
• Para a CVE-2026-109618, o PHP sugere memory_limit = -1 imposto pelo servidor (php_admin_value), junto com limites baixos de post_max_size e do tamanho de requisição no Nginx, Apache ou proxy.
• No PHP 8.5, defina também fatal_error_backtraces = 0.
• Isole ou retire do ar aplicações expostas à internet que rodem versões sem suporte.

Como atualizar

Em servidor próprio, atualize os pacotes da distribuição (ou da imagem Docker, com docker compose build --pull) e reinicie o PHP-FPM, o Apache ou o Nginx: o pacote novo em disco não protege nada enquanto os processos antigos estiverem rodando. Em hospedagem compartilhada, confira com o provedor se o patch já foi aplicado e, quando a versão corrigida aparecer no painel, selecione-a. Os pacotes das distribuições costumam chegar com atraso em relação ao lançamento oficial.

Como saber se alguém tentou

• Procure nos logs por POSTs multipart contendo o campo PHP_SESSION_UPLOAD_PROGRESS. O nome é configurável e o analisador aceita cabeçalhos fora do padrão, então uma busca simples de uma linha pode deixar passar variações.
• Observe processos do PHP (php-fpm, php-cgi, apache2) iniciando shells ou ferramentas como curl, wget e nc, ou comandos como whoami, id e uname -a executados pelo usuário do servidor web.
• Se suspeitar de invasão, isole o servidor, preserve os logs e procure arquivos novos no diretório público, tarefas agendadas e contas novas.

Há ataques em andamento?

As fontes divergem. A Sansec relata tentativas iniciais vistas pela Cloudflare em 21 de outubro; o NCSC-NL diz não haver indício de exploração ativa, mas espera ataques em larga escala; a Huntress não viu nada até 20 de outubro. Existe prova de conceito pública, o que torna a atualização urgente de qualquer forma.

Matéria atualizada com base no comunicado do PHP e em análises de mercado; a data exata do lançamento aparece como 21 ou 22 de outubro conforme a fonte.