Zero-Day in Cloudflare WAF Exposes Protected Origins Through Certificate Path

Understanding the Certificate Validation Context

To understand this vulnerability, we need to look at how automated certificate management works. The ACME protocol handles the heavy lifting of SSL/TLS certificate validation by requiring Certificate Authorities to verify that you actually control the domain you’re requesting a certificate for. The HTTP-01 validation method works by having CAs check for a specific one-time token at the path */.well-known/acme-challenge/{token}* on your website. This path exists on virtually every modern web server as part of the automated certificate renewal infrastructure. It’s designed as a narrow maintenance channel, meant only for a single validation bot checking one specific file, not as a general-purpose gateway to your origin server.

How the Bypass Actually Worked

Security researchers at FearsOff uncovered this vulnerability while examining applications where WAF rules were configured to block all traffic except from specific authorized sources. During their testing, they noticed something unusual: requests targeting the ACME challenge path were completely bypassing their WAF rules. Instead of receiving Cloudflare’s standard block page, they were getting direct responses from the origin server.

To eliminate the possibility of a configuration error specific to their environment, the researchers set up controlled demonstration environments at cf-php.fearsoff.org, cf-spring.fearsoff.org, and cf-nextjs.fearsoff.org. When they sent normal requests to these hosts, they encountered the expected block pages. But requests to the ACME path returned origin-generated responses, typically framework 404 errors, confirming the bypass was systemic rather than environmental.

The root cause traces back to Cloudflare’s edge network processing logic. When Cloudflare serves ACME challenge tokens for its own managed certificate orders, the system intentionally disables WAF features to prevent interference with legitimate CA validation requests. The critical flaw emerged in the conditional logic: when a request targeted the ACME path but the token didn’t match any active Cloudflare certificate order, the system would bypass WAF evaluation entirely and forward the request directly to the customer’s origin server. This transformed what should have been a tightly scoped exception into a broad security bypass affecting every protected host.

Exploitation Scenarios and Real-World Impact

The researchers demonstrated several practical attack vectors against common web frameworks. Spring and Tomcat applications proved vulnerable to servlet path traversal techniques using *..;/* notation, which allowed access to actuator endpoints that exposed process environments, database credentials, API tokens, and cloud provider keys. Next.js applications using server-side rendering leaked operational data through direct origin responses that were never architected for public internet exposure. PHP applications with local file inclusion vulnerabilities became exploitable, giving attackers file system access through malicious path parameters. Perhaps most concerning, account-level WAF rules configured to block requests based on custom headers were completely ignored for traffic targeting the ACME path.

Timeline and Remediation

The vulnerability disclosure followed a responsible timeline. FearsOff reported the issue through Cloudflare’s HackerOne bug bounty program on October 9, 2025. Cloudflare began validation on October 13, 2025, with HackerOne triaging the issue the following day on October 14, 2025. The company deployed a permanent fix on October 27, 2025, modifying the code so that security features are only disabled when requests match valid ACME HTTP-01 challenge tokens for the specific hostname being validated.

Post-fix verification confirmed that WAF rules now apply uniformly across all request paths, including the previously vulnerable ACME challenge route. Cloudflare has stated that no customer action is required and has confirmed finding no evidence of malicious exploitation during the vulnerability window.

Final Thoughts

What stands out about this vulnerability is how it exposes the complexity inherent in building exception-based security controls at scale. Cloudflare needed to create a narrow exception for legitimate certificate validation traffic, but the implementation failed to maintain that narrow scope. The vulnerability highlights a broader challenge in cloud security: when you introduce conditional logic that bypasses security controls, even for entirely legitimate reasons, you create attack surface that needs rigorous validation. The fact that this affected every Cloudflare customer using WAF rules demonstrates how a single logic error in a widely deployed security platform can have massive downstream implications. I’m particularly interested in the servlet path traversal angle here, where attackers could chain the WAF bypass with framework-specific techniques to access highly sensitive actuator endpoints. This isn’t just theoretical exposure, it represents real risk to production environments where those endpoints contain database credentials and API keys. The responsible disclosure timeline and rapid patch deployment are commendable, but this incident should prompt security teams to reconsider their assumptions about protection layers. If you’re relying entirely on Cloudflare’s WAF as your security boundary, you need defense in depth. Origin servers should implement their own authentication and access controls, sensitive endpoints should never be publicly accessible even if they’re “protected” by upstream firewalls, and monitoring needs to extend to the origin layer, not just the edge.