Abrir o painel da Cloudflare e encontrar o domínio já coberto por uma proteção que ninguém ativou naquela manhã resolve uma parte do problema e esconde a outra. Se o seu site é publicado por Cloudflare Tunnel, o hostname que responde hoje passa pelo firewall de aplicação web (WAF) da Cloudflare porque a aplicação publicada herda a configuração do hostname. Foi assim que as proteções contra php2shell chegaram a muitos domínios a partir de 21 de outubro, às 3h02 UTC, sem nenhuma configuração do seu lado.
A parte escondida é a que mais importa para o seu caso. O PHP que atende esse domínio continua exposto até a atualização chegar ao interpretador. A camada da borda barra o que reconhece como tentativa de exploração. O interpretador segue como estava. Prefiro tratar essa proteção como camada que compra tempo, porque o encerramento do assunto depende da versão instalada no servidor.
Direto ao ponto
Desde 21 de outubro de 2026, a Cloudflare aplica por padrão as proteções contra as duas falhas php2shell do PHP, incluindo no plano gratuito e sem ativação manual. Em sites publicados por Tunnel, o tráfego já passa por essa camada antes de chegar ao servidor.
A proteção barra tráfego que reconhece como tentativa de explorar o interpretador. Ela não troca o PHP instalado. Quando a atualização não sai nesta semana, manter o WAF ativo reduz a janela de exposição enquanto a solicitação de correção caminha na hospedagem. Meu parâmetro para acompanhar é a versão do interpretador que atende o seu domínio.
O que a Cloudflare aplica desde 21 de outubro
As proteções foram publicadas desde o início de outubro de 2026, cerca de nove horas antes da divulgação pública das falhas. A empresa informa que a falha já circulava antes da data oficial, com tráfego de ataque contra clientes. A partir de 21 de outubro, às 3h02 UTC, elas entraram por padrão em todos os planos com WAF.
A diferença técnica desta publicação está na detecção de transação completa, uma capacidade nova que combina sinais da requisição e da resposta dentro da mesma transação HTTP. Uma checagem baseada apenas no que o cliente envia não separa exploração de tráfego legítimo com segurança suficiente. A resposta do servidor de origem acrescenta a informação que falta. Com isso, uma proteção de resposta pode barrar a resposta da origem antes de chegar ao solicitante. Segundo a Cloudflare, as proteções de php2shell são as primeiras detecções gerenciadas publicadas com esse recurso.
A empresa também registra que os analistas acompanharam tentativas de alterar o payload para escapar das proteções, comparando o volume de correspondências com a lógica aplicada. Isso importa para a leitura do seu painel, porque significa que a cobertura muda conforme as técnicas aparecem.
Por que o Tunnel já recebe a camada da borda
A documentação do Tunnel afirma que aplicações publicadas herdam a configuração da Cloudflare para o hostname, incluindo cache, proteções de WAF e outras configurações de Rules. A mesma documentação explica que o cloudflared abre uma conexão de saída e que a origem não precisa de endereço público para responder. O tráfego chega pela rede da Cloudflare, que é onde a camada da borda atua.
Três condições acompanham essa conclusão, então vale conferir cada uma no seu domínio. O hostname precisa estar publicado pelo Tunnel em um domínio atendido pela Cloudflare, porque um registro de DNS fora do proxy não recebe a camada da borda e a origem volta a ser alcançada por outro caminho. O conjunto gerenciado precisa estar ativo e com ação aplicada às requisições, o que nos planos pagos exige conferir a implantação e a ação configurada. E o túnel precisa estar em execução, porque um Tunnel parado devolve erro de conexão e o registro de DNS sozinho não comprova serviço ativo.
Uma proxy reversa na frente do servidor não muda esse arranjo. O que muda a conclusão sobre exposição é o caminho do tráfego e a versão do interpretador, não o nome da ferramenta que aparece na tela do painel. Quando você já usa outros recursos da Cloudflare no mesmo domínio, a leitura sobre serviços da Cloudflare que não prendem a stack separa o que é configuração de borda do que precisa existir na aplicação.
O que o WAF da Cloudflare não faz
O próprio anúncio da Cloudflare recomenda atualizar o PHP mesmo com a proteção ativa e descreve o WAF como camada adicional de mitigação. A correção das duas falhas está no interpretador, então atualizar o código do site ou um plugin, isoladamente, não resolve o problema. O comunicado do PHP traz as versões corrigidas. O artigo sobre quais versões estão corrigidas detalha como conferir a sua.
A proteção também não informa qual versão do PHP roda no servidor. Ela barra tráfego que reconhece como tentativa de exploração com o conjunto de assinaturas daquele momento. A ausência de eventos no painel não comprova que o domínio esteja atualizado. A detecção de transação completa foi criada para reduzir falsos positivos ao olhar os dois lados da requisição, embora ainda possa barrar tráfego legítimo. Sites com fluxo de upload, painel administrativo ou integração que envia requisições grandes precisam de acompanhamento dos eventos depois da ativação.
Por último, o WAF cobre o tráfego HTTP que passa pela Cloudflare. Uma conexão direta à origem, feita fora dessa rede, não é inspecionada por ele.
Como conferir o que foi barrado
No painel, abra a seção Security e siga para Security Analytics e Events. Você filtra pelos identificadores das proteções e inspeciona a requisição correspondente com a ação aplicada. O evento indica se a ação veio de uma proteção gerenciada ou de uma proteção própria. A leitura vale mais quando você compara o período anterior e o posterior à ativação e observa se o volume de eventos acompanha o tráfego normal do site.
Nos planos pagos, a conferência começa na implantação do conjunto gerenciado e na ação configurada para as requisições. Se o escopo foi restringido a uma parte da aplicação, a cobertura segue essa restrição. No plano gratuito, a publicação é automática e não exige ação, o que não dispensa a mesma revisão de eventos.
Quando a atualização não sai nesta semana
Há instalações que não conseguem resolver isso de imediato. Na hospedagem compartilhada, a versão do PHP é definida pelo provedor. Uma aplicação presa a uma série antiga do interpretador depende de pacote com correção retroativa ou de migração. O provedor que demora para publicar a atualização deixa o domínio exposto por mais tempo, então é nesse intervalo que a camada da borda faz diferença. Nos três casos, a solicitação de atualização precisa registrar data, protocolo e versão informada pelo provedor, porque essa sequência permite cobrar a resposta. O caso de uma aplicação presa à versão antiga mostra como a compatibilidade da aplicação define o caminho possível.
A conferência do PHP instalado exige cuidado. O resultado de php -v no terminal corresponde ao executável chamado ali. O serviço web pode usar outro interpretador e outro arquivo de configuração. Relacionar o domínio ao processo que recebe as requisições é o que confirma a versão em uso. Como você administra esse processo no dia a dia, a Formação DevOps cobre a leitura de serviço, container e configuração que essa conferência exige.
Enquanto a atualização não chega, restringir uploads desnecessários e limitar o tamanho dos arquivos reduz a exposição. Nenhuma das duas medidas substitui a correção no interpretador.
O que fica depois do anúncio
A proteção por padrão é um ganho real para sites publicados por Tunnel e para qualquer domínio que passa pela Cloudflare, porque reduz a janela entre a divulgação da falha e a atualização no servidor. O erro de leitura é tratar esse ganho como fim do trabalho. Eu encerro o assunto quando duas condições estão verdadeiras ao mesmo tempo: o domínio coberto pela camada da borda e o interpretador que atende esse domínio em uma versão corrigida. Enquanto isso não acontece, a pendência continua aberta e o acompanhamento dos eventos faz parte da rotina.
