CloudSec

Em 21 de outubro de 2026, o time de segurança do PHP publicou correções emergenciais para duas vulnerabilidades críticas no próprio motor da linguagem. Elas ficaram conhecidas como PHP2Shell e estão registradas como CVE-2026-109618 e CVE-2026-109619. As duas receberam nota 9.2 (Crítica) no CVSS v4.0 e permitem execução remota de código (RCE) sem autenticação em servidores web que rodam PHP.

O problema não está em um CMS, framework ou plugin específico. Ele está no interpretador PHP. Por isso, o que define se um ambiente está exposto é a versão do PHP, e não a versão do WordPress, Magento, Laravel ou de qualquer outra aplicação.

O que são as vulnerabilidades

CVE-2026-109618 (“rawkey”)
Quando falta memória durante o processamento de uma requisição, o PHP pode deixá-la parcialmente inicializada. Depois, na finalização, ele trata esse estado incompleto como válido. Um atacante explora a falha enviando um POST de vários megabytes com um nome de campo muito grande (a partir de cerca de 1 MiB).

CVE-2026-109619 (“php2shell”)
O PHP pode manter referências a uma área de memória que já foi liberada (use-after-free), e uma requisição seguinte no mesmo processo acaba usando esses dados. A exploração passa pelo recurso session.upload_progress, que é executado em qualquer endpoint que aceite POST, antes do código da aplicação. Basta um payload de cerca de 450 bytes, por isso limites de tamanho não protegem contra essa variante.

Quem está mais exposto:

  • Apache com mod_php tem o maior risco e é o cenário em que a exploração completa já foi confirmada.
  • PHP-FPM é mais difícil de explorar, mas não está imune.
  • php-cgi, FrankenPHP e LiteSpeed também são afetados.

As falhas existem desde o PHP 5.4. Já existe uma prova de conceito pública, e várias equipes de segurança relatam tentativas de exploração ativa.

Versões afetadas e corrigidas

Todas as versões anteriores às listadas abaixo estão vulneráveis:

VersãoVersão corrigida
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

As versões sem suporte (8.1, 8.0 e 7.4) não terão atualização oficial. O time do PHP publicou apenas backports mínimos do código-fonte, e algumas distribuições Linux e fornecedores de suporte estendido já disponibilizaram pacotes. Se você ainda usa estas versões, recomendamos planejar a migração para uma versão suportada o quanto antes.

Como corrigir as falhas

1. Atualize o PHP. Essa é a única correção completa. Atualizar a aplicação ou os plugins não resolve.

php -v
Em distribuições baseadas em Debian/Ubuntu, por exemplo:
sudo apt update && sudo apt install --only-upgrade 'php8.*'
Em distribuições baseadas em RHEL:
sudo dnf upgrade 'php*'
2. Reinicie todos os processos PHP. Workers que ficam ativos por muito tempo continuam vulneráveis até serem reiniciados:
sudo systemctl restart php8.3-fpm   # ajuste para sua versão
sudo systemctl restart apache2      # ou httpd, se usar mod_php

3. Mapeie todo o parque. Inclua imagens de containers, runners de CI/CD, appliances, painéis como cPanel e Plesk, e softwares Windows que trazem php.exe ou php-cgi.exe embutidos.

Mitigações temporárias (se não puder atualizar agora)

Essas medidas reduzem o risco, mas não substituem a atualização. Confirme também que nenhuma configuração de pool, diretório ou aplicação as sobrescreve.

No php.ini:

; Contra a CVE-2026-109619. Recomendado manter desativado mesmo após a atualização, se o recurso não for usado
session.upload_progress.enabled = 0

; Somente PHP 8.5
fatal_error_backtraces = 0

; Contra a CVE-2026-109618. Avalie o impacto antes: remove o limite de memória por requisição
memory_limit = -1
Outras recomendações:
  • Limpe o diretório definido em session.save_path. Arquivos de sessão contaminados antes da correção continuam sendo um risco até expirarem.
  • Bloqueie multipart/form-data na borda para aplicações que não recebem upload.
  • No WAF ou proxy reverso, bloqueie nomes de campo de formulário com 1.000 bytes ou mais. Bloqueie também partes multipart chamadas PHPSESSID e nomes de arquivo que contenham <?php, <?= ou sintaxe de objeto serializado.
  • Aplique rate limit em POSTs grandes vindos de um mesmo IP.

Cloudflare já aplicou regras de WAF

A Cloudflare publicou regras de WAF contra o PHP2Shell cerca de 9 horas antes da divulgação pública. A proteção padrão está ativa desde as 03h02 UTC de 21 de outubro, e a empresa já registrou tráfego de ataque, inclusive tentativas de contornar as regras.

As regras “Generic Rules – Anomalous Execution” (1 a 7) foram incluídas em:

  • Cloudflare Managed Free Ruleset, para o plano Free;
  • Cloudflare Managed Ruleset, para os planos Pro, Business e Enterprise;
  • além da regra “Default block for High confidence Signatures”, que analisa também a resposta da origem e vale para todos os planos.

Se você usa um plano pago da Cloudflare, confirme se o Managed Ruleset está em modo Block. Os eventos bloqueados podem ser consultados em Security > Security Analytics > Events.

A própria Cloudflare reforça que o WAF é uma camada extra de defesa e não substitui a atualização do PHP. WAFs em nuvem também analisam só os primeiros KB do corpo da requisição, o que torna a correção na origem indispensável.

Como identificar sinais de exploração

Recomendamos revisar os logs a partir de 20 de outubro de 2026, e não apenas da data em que a correção foi aplicada:

  • erros PHP Fatal error ... tried to allocate ... in Unknown on line 0;
  • rajadas de POSTs de 1 MB ou mais vindas do mesmo IP (no Apache, acompanhadas de AH00052);
  • shells (sh, bash) iniciados por apache2, httpd, nginx ou php-fpm executando id, whoami, curl, wget, base64 ou nc;
  • arquivos novos em /tmp, /dev/shm, /var/tmp ou em diretórios web graváveis;
  • novas entradas em authorized_keys, cron jobs do usuário web ou arquivos PHP desconhecidos no web root.

Infraestrutura da Neture

Assim que as correções foram publicadas, a Neture atualizou o PHP em todas as suas estruturas e reiniciou os serviços afetados.

Para os clientes do serviço CloudOps, nossa equipe já está aplicando as atualizações nos ambientes sob nossa gestão. O trabalho inclui:

  • Inventário das versões de PHP em uso;
  • Atualização para as versões corrigidas e reinício dos workers;
  • Mitigações temporárias onde a atualização imediata não for possível;
  • Revisão das regras de WAF e monitoramento de sinais de exploração.

Entraremos em contato caso algum ambiente precise de janela de manutenção ou de alguma decisão específica.

Se o seu ambiente ainda não é gerido pela Neture e você quer ajuda para avaliar a exposição ou aplicar as correções, nosso time está à disposição, entre em contato com nosso comercial.

Referências