Em resumo: A Cloudflare tem, segundo as suas próprias declarações, desde 21 de outubro de 2026, às 03:02 UTC, regras de proteção ativas contra o PHP2Shell, também para clientes do plano gratuito. As regras reduzem o risco para o tráfego que passa pela Cloudflare. Não atuam se o servidor de origem for diretamente acessível e não substituem a atualização do PHP. Quem usa a Cloudflare deve verificar o modo das regras, a proteção da origem e o nível de patch.
O ponto de partida: proteção antes do patch
A Cloudflare estava invulgarmente adiantada no caso do PHP2Shell. Segundo o blogue da Cloudflare, as regras de proteção já estavam ativas várias horas antes da publicação oficial das atualizações do PHP, às 14:00 UTC. A Cloudflare relatou ainda ter observado tentativas de ataque a clientes e que os atacantes alteravam os seus padrões para contornar as regras.
Muitos operadores concluíram daí: “Estamos atrás da Cloudflare, por isso estamos protegidos.” Isso só é verdade em parte. Este artigo explica o que as regras realmente cobrem. Uma ponderação geral entre firewall e atualização é oferecida pelo artigo WAF ou atualização?.
O que a Cloudflare lançou contra o PHP2Shell
Segundo o blogue da Cloudflare, há três elementos:
| Plano | Proteção segundo a Cloudflare | O que deve fazer |
|---|---|---|
| Free | novas regras no Managed Free Ruleset, ativas automaticamente | verificar que o domínio passa pela Cloudflare |
| Pro, Business, Enterprise | regras adequadas no Managed Ruleset | garantir que o ruleset está em “Block” |
| todos os planos | regra por defeito na nova firewall de respostas | não desativar nada, observar os eventos |
O terceiro elemento é novo. A Cloudflare chama-lhe “full transaction detection”: a WAF analisa não só o pedido, mas também a resposta do servidor. O motivo, segundo a Cloudflare: só o pedido nem sempre basta para distinguir com segurança um ataque do tráfego normal. O PHP2Shell é a primeira utilização desta funcionalidade nas regras geridas.
Os limites das regras da Cloudflare
Por muito úteis que sejam, as regras têm limites claros, que a Cloudflare em parte indica ela própria:
- Apenas tráfego através da Cloudflare: As regras verificam o que passa pela Cloudflare. Se o servidor de origem for diretamente acessível pelo seu endereço IP, um atacante pode contornar a proteção.
- Sem reverter: Segundo a Cloudflare, uma regra do lado da resposta pode reter a resposta, mas não desfazer o que já aconteceu no servidor.
- Padrões de ataque mutáveis: A Cloudflare ajusta as regras continuamente porque os atacantes alteram os seus pedidos. Entre uma nova variante e a nova regra pode haver uma lacuna.
- Não substitui a atualização: A Cloudflare recomenda expressamente atualizar o PHP apesar da WAF. Também uma atualização do código da aplicação ou dos plugins não corrige as vulnerabilidades.
- Caso especial CVE-2026-115560: Segundo o complemento da Cloudflare de 23 de outubro, a regra não atua se o nome do session upload progress tiver sido alterado na configuração. Mais sobre este aviso em CVE-2026-115560.
O que dizem os pedidos bloqueados e o que não dizem
Depois do aviso, muitos clientes olham para os seus eventos de segurança e encontram lá pedidos bloqueados. Isso só mostra, para já, que o seu domínio foi analisado e que a regra atuou. Não prova uma intrusão. Inversamente, uma lista de eventos vazia não é um alívio: se um ataque foi dirigido diretamente ao servidor de origem ou ocorreu antes de 21 de outubro, nem sequer aparece na Cloudflare.
Mais fiável é o confronto com os registos do próprio servidor web. Pedidos que ali chegam mas não provêm de endereços da Cloudflare indicam um acesso direto. Guarde esses registos desde 20 de outubro, como aconselha a imprensa especializada. A Cloudflare chama ainda a atenção para o facto de restrições aos uploads poderem reduzir o risco, mas não substituírem a atualização do PHP.
A fraqueza mais frequente por trás da Cloudflare não é a regra, mas o caminho que a contorna: um servidor de origem que responde diretamente pelo seu endereço IP ou através de um subdomínio não protegido.
Lista de verificação para clientes da Cloudflare
Estes passos podem ser concluídos por si ou pelo seu prestador de serviços a curto prazo:
- Verificar o plano e o modo das regras: Nos planos pagos, confirmar no painel que o Managed Ruleset está ativo no modo “Block”.
- Ver os eventos de segurança: Em Security Events, verificar se aparecem pedidos bloqueados. Isso mostra se os seus domínios já foram alvo.
- Percorrer as entradas DNS: Qualquer entrada que aponte para o servidor web mas não passe pela Cloudflare é um possível desvio. Típicos são subdomínios para staging, FTP ou correio no mesmo servidor.
- Isolar a origem: Configurar o servidor web para aceitar HTTP e HTTPS apenas da Cloudflare, por exemplo por firewall com os intervalos de endereços publicados pela Cloudflare ou através de um túnel. Como se faz isto em geral é descrito no artigo Firewall para servidores web.
- Testar o acesso direto: Verificar a partir do exterior se a origem responde sem a Cloudflare.
- Atualizar o PHP e reiniciar: As regras são a segunda linha. A primeira é o PHP numa versão corrigida, com reinício de todos os processos PHP.
Para o passo 5 basta um teste inofensivo que consulta apenas os cabeçalhos. O endereço IP é um marcador para o seu servidor de origem:
# O servidor de origem responde diretamente, sem passar pela Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Se aqui vier uma resposta normal do seu site, a origem é diretamente acessível e a proteção da Cloudflare pode ser contornada.
Como ajuda concretamente a PHP SOS?
- Verificação da configuração: Verificamos o modo das regras, as entradas DNS e o acesso direto ao servidor de origem.
- Proteger a origem: Restringimos o servidor web ao tráfego através da Cloudflare, sem interromper o seu site.
- Patch e comprovativo: Atualizamos o PHP, reiniciamos todos os processos e documentamos o estado.
- Avaliar eventos: Analisamos os pedidos bloqueados e comparamo-los com os registos do servidor.
Como combinamos regras WAF e medidas provisórias é descrito em WAF e patching virtual.
Conclusão
As regras da Cloudflare contra o PHP2Shell são um verdadeiro ganho, sobretudo porque chegaram cedo e também no plano gratuito. São, no entanto, um escudo diante da porta, e não uma fechadura na porta. Quem está atrás da Cloudflare deve garantir três coisas: regras no modo Block, nenhum caminho que contorne o proxy e o PHP numa versão corrigida.
Perguntas frequentes
Estou protegido contra o PHP2Shell com o plano gratuito da Cloudflare?
Segundo a Cloudflare, também os clientes do plano Free recebem automaticamente as regras de proteção. Funcionam, no entanto, apenas para o tráfego que passa pela Cloudflare e não substituem a atualização do PHP no servidor. Se o servidor de origem for diretamente acessível, a proteção não atua.
O que tenho de configurar nos planos pagos da Cloudflare?
A Cloudflare aconselha os clientes dos planos Pro, Business e Enterprise a verificar que o Managed Ruleset está no modo Block. Se estiver apenas em Registar, os ataques são registados, mas não são travados.
O que é a full transaction detection?
Uma nova funcionalidade da WAF da Cloudflare que analisa não só o pedido, mas também a resposta do servidor. Assim é possível reconhecer se uma tentativa de ataque tem efeito e a resposta pode ser retida. O que já foi executado no servidor não é revertido, segundo a Cloudflare.
A Cloudflare cobre também a CVE-2026-115560?
A Cloudflare completou o seu artigo a 23 de outubro com a CVE-2026-115560. Segundo a Cloudflare, a regra correspondente não atua se o nome do session upload progress tiver sido alterado na configuração do PHP. Independentemente disso, o php.net recomenda definir session.upload_progress.enabled=0.