Cloudflare Zero-day: Accessing Any Host Globally

by

Author: FearsOff (@k_firsov / @FearsOff; no individual byline stated in the article metadata)
Published: October 28, 2025
Source: https://fearsoff.org/research/cloudflare-acme

Summary

FearsOff disclosed a global Cloudflare WAF bypass in which requests to the certificate-validation path /.well-known/acme-challenge/{token} were served by the customer’s origin even when customer and account-level WAF rules were configured to block all traffic. Because that ACME (HTTP-01) path appears to have been evaluated on a separate code path — an implicit exception intended to ease certificate issuance that ran before customer blocking controls — the trust boundary silently shifted from Cloudflare’s edge to the origin for that one route. No CVE was assigned; the issue was reported through HackerOne on October 9, 2025 and Cloudflare deployed a fix on October 27, 2025. The finding is significant because a single “boring” maintenance path became a side door to origins worldwide, giving otherwise-blocked applications a direct network path from the public internet.

Technical Details

Root cause (working hypothesis): Requests under /.well-known/acme-challenge/ were processed on a different evaluation path than ordinary traffic. This implicit exception — meant to let ACME domain-control validation bots read a one-time token — executed ahead of customer blocking rules, so the WAF “stepped aside” and the origin answered directly. Everywhere else the WAF behaved correctly; only the ACME path leaked.

Reproduction and detection: The researchers stood up three controlled demo hosts behind Cloudflare, all defaulting to blocked for normal traffic (cf-php, cf-spring, and cf-nextjs.fearsoff.org), plus a custom rule blocking any hostname containing cf- to simulate the common “allow only corporate VPN egress” posture. Under ordinary paths these hosts returned Cloudflare’s block page; aimed at the ACME challenge path with any token they returned an origin-generated response (typically a framework 404). The identity of the responder — Cloudflare interstitial versus origin framework — was the tell, visible even without inspecting headers. Appending a harmless suffix to the token (e.g. /ae) showed no real ACME file was required for the behavior to appear.

Obtaining a stable token: To avoid racing a real certificate authority, they used Cloudflare’s SSL/TLS Custom Hostnames feature, adding cf-well-known.fearsoff.org with HTTP validation explicitly selected but deliberately creating no DNS record, so issuance stayed in Pending Validation indefinitely. In that state Cloudflare surfaces the HTTP-01 URL a validation bot would request, giving a deterministic, long-lived token shape to anchor the WAF-behavior tests. No challenge file was ever placed and validation was never completed.

Account-level rules skipped, including header rules: To show this was more than a detour to a framework 404, the researchers configured account-level WAF rules to block requests carrying a sentinel header. At the root path a request with X-middleware-subrequest was blocked as intended; the identical request aimed at the ACME path was allowed and served by the application. Because the ACME path skipped header-policing rules, whole classes of header-dependent issues regained a route to the origin: header-driven SQL concatenation in legacy code, SSRF/host confusion via X-Forwarded-Host or X-Original-URL, cache-key poisoning when caches vary on headers, method-override tricks via X-HTTP-Method-Override, and debug toggles wired to custom headers.

Impact

Once the origin was directly addressable — even for a single route — ordinary origin bugs acquired a public network path and ordinary pages became reconnaissance. The researchers demonstrated the consequences (not the cause) on their own demo hosts:

  • Spring / Tomcat: Using the well-known servlet-stack traversal quirk ..;/, a request could reach /actuator/env and return process environment and configuration — data that often includes database URLs, API tokens, and cloud keys, materially raising blast radius.
  • Next.js: Server-side rendering routinely ships server-derived values to the client for hydration; with the origin answering directly, those operational details became reachable from the public internet.
  • PHP routing: Apps that route all requests through index.php and select views via query parameter turn an LFI bug into a public file read — e.g. requesting ../../../../etc/hosts — once the origin is reachable.

The scope was global across Cloudflare-fronted hosts for the affected path. These demonstrations are consequences of the single root issue: the WAF’s decision on that special path.

Mitigation

Fixed at the vendor. On October 27, 2025 Cloudflare deployed a fix; FearsOff re-tested and confirmed the WAF now applies customer rules uniformly, including on /.well-known/acme-challenge/*. No customer action is required to remediate the bypass itself, as the correction was made in Cloudflare’s platform.

Defense-in-depth (recommended regardless): Do not treat a WAF as the sole security boundary — harden origins as if they are internet-reachable. Restrict or disable exposed management surfaces such as Spring Boot Actuator endpoints, patch servlet traversal (..;/) and path-normalization quirks, remediate LFI/routing bugs, and avoid trusting request headers (X-Forwarded-Host, X-Original-URL, X-HTTP-Method-Override, custom debug toggles) for security decisions. The researchers note that AI-driven tooling can enumerate and chain exposed paths like this at scale, which raises the urgency of layered origin defenses.

Disclosure timeline: Oct 9, 2025 — submitted via HackerOne; Oct 13 — vendor validation started; Oct 14 — triaged by HackerOne; Oct 27 — final fix deployed and re-test confirmed fixed. FearsOff credits collaboration with the Crypto.com Security Team (Jason Lau, CISO) for independent verification and with Matthew Prince (Cloudflare CEO) and the Cloudflare team on the patch.

References

Leave a Comment