Critical Cloudflare Zero-Day Vulnerability in ACME Challenge Handling Enables Complete WAF Bypass and Unauthorized Origin Host Access

CyberDefender 9 mins0

A critical zero-day vulnerability in Cloudflare’s Web Application Firewall (WAF) was discovered that allowed attackers to bypass intended security protections entirely and reach backend servers, simply by targeting a special certificate-validation path.

This wasn’t just a typical WAF misconfiguration — it was a design flaw in request processing logic on Cloudflare’s edge network, affecting how customer traffic was evaluated before reaching origin servers.

How This Worked: ACME and Cloudflare’s Edge Processing

What Is ACME and .well-known/acme-challenge/?

Most websites today use SSL/TLS certificates for HTTPS — and the ACME protocol (Automatic Certificate Management Environment) is how certificates are often issued automatically.

Part of this involves a domain validation step called HTTP-01 challenge: a Certificate Authority expects to find a specific token file at a hidden path on the website:

https://example.com/.well-known/acme-challenge/{token}

That token proves ownership of the domain and gets removed once the certificate is issued.

Normally:

  • Only certificate authorities and automated validation tools should ever touch this path.
  • Other WAF protections are still in force for every other path visitors use.

But in this case, something unexpected happened.

What the Vulnerability Really Was

Security researchers found that requests hitting the /.well-known/acme-challenge/ path were being treated differently by Cloudflare’s edge logic:

Key Points of the Flaw

  1. WAF Disabled on the ACME Path
    Cloudflare’s system intentionally disabled WAF protections for requests matching valid ACME challenge tokens — so Certificate Authorities could validate without interference. But there was a logic flaw:
    • Requests to the challenge path were not fully validated
    • Even requests without valid tokens ended up bypassing WAF rules
    • This meant Cloudflare wasn’t filtering or blocking them like normal traffic
  2. Origin Server Reached Unchecked
    Because these requests sidestepped WAF evaluation entirely:
    • The edge would forward them straight to the origin server
    • Any backend application would then respond normally
    • This includes internal endpoints that should have been protected
  3. No Normal Protections Applied
    Crucially:
    • Custom firewall rules were ignored
    • Security policies based on host headers were ignored
    • Blocking rules based on headers, paths, or patterns were ignored
    All because the request went through this “special case” logic block mistakenly.

Demonstration and Proof of Concept

Researchers at FearsOff built test environments to show how this happened:

They stood up a few sites running different kinds of backends:

  • A PHP site
  • A Spring/Tomcat Java site
  • A Next.js app

On all of these, when they made a normal request, the WAF blocked malicious attempts correctly.

But when they crafted a request targeting the ACME challenge path, even with invalid tokens, Cloudflare treated it like a valid ACME validation request — and forwarded it to the server. The responses showed backend errors such as:

  • Spring/Tomcat revealing internal routing behavior
  • Next.js returning framework errors containing operational information
  • PHP code paths showing local file handling behavior

This clearly showed the WAF never ran against these requests — they reached the origin server directly.

Why This Attack Path Matters

Here’s why this was more serious than a simple WAF bypass in a lab:

  1. Trusted but Untested Path
    This wasn’t some rare edge case path that rarely gets used — /.well-known/acme-challenge/ is a path all active HTTPS sites must handle.
  2. General Exception Misapplied
    The logic was originally meant to let legitimate certificate validation traffic through. Instead it became a backdoor to bypass protections.
  3. Frameworks Leak Sensitive Info
    The unintended responses from application frameworks (Java, Next.js, PHP) often include:
    • Stack traces
    • Internal route names
    • Configuration information
    • Debug output
    This becomes attackable reconnaissance data.

Practical Impact

Because requests to this path were allowed through unrestricted:

Possible Exploits

Attackers could have used this flaw to:

  • Access internal or administrative endpoints that the WAF would normally block
  • Leak configuration or sensitive operational data from origin servers
  • Trigger code paths not designed to be public, potentially exposing logic flaws

While there was no evidence of this being actively exploited in the wild, the potential was real — especially for sites without additional access controls.

Affected Industries

Any service using Cloudflare’s WAF could have been impacted:

  • Financial institutions (admin portals)
  • Healthcare systems (internal APIs)
  • Tech & SaaS platforms (backend admin dashboards)
  • E-commerce systems (inventory/order APIs)
  • Government services (internal data portals)

The real risk isn’t just this one path — it’s that a trusted edge service stopped enforcing expected controls for certain requests.

Resolution Details

Once reported through Cloudflare’s vulnerability program:

  • The issue was triaged quickly
  • Engineers updated the edge logic so that:
    • Only valid tokens for a hostname are allowed to bypass protections
    • Every other request, even to the ACME path, is subject to full WAF evaluation
  • Tests confirmed that normal security rules now trigger on all such paths

Cloudflare stated:

  • The vulnerability was fixed at the edge — no customer action required
  • No signs of exploitation were detected

Technical Takeaways

Why This Happens

This type of flaw is essentially a logic exception gone too far:

  • Designers allowed an exception to bypass security for a specific use case (certificate validation)
  • But the code didn’t correctly distinguish valid from invalid requests
  • The exception became a general bypass vector

What It Teaches Us

Even paths that “should be allowed” need strict validation, especially when they touch origin servers.

  • Special-case routing must still enforce host rules
  • WAF logic should not be skipped simply because a path looks like a benign maintenance route
  • Application frameworks should never trust bypassed traffic blindly

CyberDefender