Resumo
Pesquisadores da FearsOff descobriram uma vulnerabilidade em que requisições ao caminho /.well-known/acme-challenge/ eram encaminhadas ao origin mesmo quando regras de WAF configuradas pelo cliente bloqueavam todo o tráfego. A falha foi corrigida pela Cloudflare, que afirma não ter encontrado evidência de exploração.
Descoberta e reprodução
Durante testes em aplicações com regras de bloqueio estritas, a equipe da FearsOff observou que requisições dirigidas ao caminho de validação ACME HTTP‑01 retornavam respostas do origin em vez da página de bloqueio do Cloudflare. Para confirmar que não era um erro de tenant, os pesquisadores criaram hosts de demonstração: cf-php.fearsoff.org, cf-spring.fearsoff.org e cf-nextjs.fearsoff.org, onde reproduziram o comportamento.
Por que a falha ocorria
A lógica de processamento na borda da Cloudflare tratava o fluxo de validação ACME de forma diferenciada: quando o sistema precisava servir tokens para ordens de certificado gerenciadas pela Cloudflare, os recursos de segurança eram temporariamente desabilitados para não interferir com a validação do CA. O defeito crítico foi que, se o token solicitado não correspondesse a uma ordem de certificado gerenciada, a requisição ainda assim pulava a avaliação do WAF e ia direto ao origin — transformando uma exceção legítima em um bypass de segurança amplo.
Vetores demonstrados
FearsOff demonstrou múltiplos vetores exploráveis em frameworks comuns. Em aplicações Spring/Tomcat, técnicas de traversal de caminho (..;/) permitiram acesso a endpoints de actuator que expunham variáveis de ambiente e credenciais operacionais. Em apps Next.js, respostas diretas do origin vazaram dados operacionais não destinados à internet pública. Aplicações PHP com vulnerabilidades de inclusão local tornaram‑se exploráveis via parâmetros de caminho, e regras de WAF a nível de conta foram ignoradas para tráfego do caminho ACME.
Correção e postura da Cloudflare
A vulnerabilidade foi reportada por FearsOff via HackerOne em 9 de outubro de 2025; a Cloudflare validou o caso em 13 de outubro e publicou correção permanente em 27 de outubro de 2025. A correção altera a lógica para que os recursos de segurança sejam desativados apenas quando o pedido corresponder a um token ACME HTTP‑01 válido para o hostname em questão. A Cloudflare informou que não é necessária ação por parte dos clientes e declarou que não há evidências de exploração maliciosa conhecida.
Impacto para clientes e recomendações
Embora a empresa afirme ausência de evidências de exploração, o vetor representava um risco sério em hosts que dependem exclusivamente de regras de WAF para restringir acesso a origens sensíveis. Operadores de aplicações atrás da Cloudflare devem:
- Verificar endpoints sensíveis e reduzir a exposição direta do origin, usando origin‑pull authenticated ou IP‑allowlist quando aplicável.
- Revisar logs históricos para requisições incomuns a /.well-known/acme-challenge/ e investigar respostas atípicas do origin.
- Aplicar defesa em profundidade: não confiar unicamente no WAF para proteção de endpoints de gerenciamento e administração.
Evidências e limites
O relatório público fornece provas de conceito controladas, mas não lista explotação ativa em ambiente real. As demonstrações destacam riscos operacionais concretos (exposição de credenciais e dados por endpoints de framework); no entanto, não há métricas públicas sobre alcance nem identificação de vítimas específicas. A atribuição do achado é de FearsOff; a correção e comunicado foram publicados pela Cloudflare.
Fontes: FearsOff (pesquisa técnica citada) e Cyber Security News (síntese da investigação e cronologia).