Cloudflare libera proteção automática contra falha php2shell no PHP

Duas falhas na própria linguagem, não em plugin

Hoje, 21 de outubro de 2026, as empresas de segurança Calif.io, Wiz, OpenAI e Quarkslab divulgaram duas vulnerabilidades no runtime do PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) →, catalogadas como CVE-2026-109618 e CVE-2026-109619 e apelidadas em conjunto de php2shell, segundo o blog da Cloudflare. As falhas afetam todo servidor web rodando PHP 5.4 ou versões mais recentes.

Isso significa praticamente qualquer instalação de PHP em produção hoje. Um atacante que envie tráfego HTTP especialmente manipulado pode causar negação de serviço, execução remota de código ou exposição de dados, dependendo de como a aplicação processa a requisição. Como o PHP move algo perto de 70% dos sites da internet e sustenta plataformas como WordPress e Magento, o raio de impacto potencial é grande.

Como a falha funciona na prática

O problema está em como o PHP gerencia memória quando algo dá errado no meio do processamento de uma requisição. Em condições normais, o PHP aloca memória para os dados da requisição e libera essa memória quando o trabalho termina. Quando o processamento é interrompido de forma inesperada, por exemplo por falta de memória, o PHP não consegue sempre limpar essa memória com segurança.

As duas CVEs exploram esse descuido de formas diferentes: uma usa dados que nunca foram inicializados corretamente, a outra acessa memória que já foi liberada. Um atacante pode forçar essas condições com requisições grandes, mas o problema vai além de apenas esgotar recursos do servidor: manipulando o conteúdo dessa memória inválida, é possível travar o processo PHP, vazar informação sensível ou, no pior caso, executar código arbitrário.

A corrida contra o relógio antes da divulgação

A Cloudflare integrou o esforço coordenado de divulgação ao lado da PHP Foundation, da OpenAI e da Wiz, entre outros, e começou a desenvolver proteções no firewall de aplicação web (WAF) desde o início de outubro de 2026. As regras foram implantadas cerca de 9 horas antes da divulgação pública, e a partir das 3h02 UTC de 21 de outubro todo cliente do WAF da Cloudflare, gratuito ou pago, passou a estar protegido por padrão.

Segundo a empresa, a vulnerabilidade vazou antes da data oficial de divulgação e já havia tráfego de ataque mirando clientes da Cloudflare nesse período. Os atacantes testavam variações do payload para tentar burlar as proteções, e a equipe acompanhou isso cruzando o volume de detecções com a lógica de cada regra.

O recurso novo por trás da proteção

Bloquear o php2shell só com regras baseadas em requisição não bastava: muitas vezes os dados da requisição sozinha não dão evidência suficiente para distinguir um exploit de tráfego legítimo. Para resolver isso, a Cloudflare criou a full transaction detection, uma capacidade nova do WAF que combina sinais da requisição e da resposta dentro da mesma transação HTTP.

Com esse recurso, uma regra pode bloquear a resposta da origem antes que ela chegue ao requisitante, caso identifique que o exploit teve sucesso do lado do servidor. As proteções do php2shell são a primeira detecção gerenciada da Cloudflare a usar essa capacidade, reduzindo falsos positivos ao olhar o contexto completo da transação.

Em resumo, a cobertura foi distribuída assim:

• Clientes gratuitos recebem 7 regras no Cloudflare Managed Free Ruleset (ID 77454fe2d30c4220b5701f6fdfb893ba), ativadas automaticamente, sem ação necessária.
• Clientes dos planos Professional, Business e Enterprise recebem 7 regras equivalentes no Cloudflare Managed Ruleset (ID efb7b8c949ac4650a09736fc376e9aee), mas devem conferir se o ruleset está em modo de bloqueio.
• Todos os planos, incluindo o gratuito, ganharam uma regra de alta confiança no novo Cloudflare Managed Response Firewall Default (ID afffe22785674c80a31875c848d2242a), que atua sobre a resposta da origem.

O que fazer agora, segundo a própria Cloudflare

Ter o WAF ativado não resolve o problema de raiz: como a falha está no runtime do PHP, atualizar o código da aplicação ou de um plugin isolado não corrige nada. Quem roda PHP direto precisa atualizar o próprio interpretador seguindo o aviso oficial do projeto; quem usa hospedagem gerenciada precisa cobrar o provedor para aplicar essa atualização.

Enquanto o patch não sai, a recomendação da Cloudflare é manter a proteção do WAF ativa como camada extra de defesa, e restringir uploads desnecessários e limitar o tamanho de upload para reduzir a superfície de ataque, sem tratar isso como substituto do conserto real. Para quem usa Cloudflare, o caminho é abrir Security > Security Analytics > Events no painel e filtrar pelos IDs de regra divulgados, para inspecionar o que já foi bloqueado e ajustar o escopo do ruleset onde fizer sentido.

O que ainda fica em aberto

A Cloudflare não publicou pontuação CVSS nem detalhou quantos de seus clientes já sofreram tentativas de exploração, nem como está o ritmo de adoção do patch entre provedores de hospedagem. A empresa também avisa que as descrições das regras "serão atualizadas em breve" e que o time de análise de segurança seguirá ajustando as proteções conforme novas variações de ataque surgirem nos próximos dias, com as mudanças registradas no changelog do produto.

Para quem desenvolve ou mantém infraestrutura PHP no Brasil, o recado prático é direto: ter WAF, seja da Cloudflare ou de outro fornecedor, reduz a janela de exposição, mas não substitui ir atrás do patch do PHP junto ao provedor de hospedagem ou à distribuição usada em produção. Dado que WordPress e Magento rodam sobre PHP, lojas e sites built nessas plataformas estão na linha de frente desse problema, mesmo sem nenhuma vulnerabilidade própria no tema ou plugin instalado.

Fonte: blog.cloudflare.com