Full Report
The ACME protocol is used for verifying domain control, commonly used by certificate authorities. The CA expects the website to serve a one-time token at /.well-known/acme-challenge/{token} to verify the domain. The CA fetches the token; if the bytes match, then the certificate is issued. The authors of this post were reviewing Cloudflare where the WAF was configured to block the world from all calls. When requesting the ACME endpoint, the WAF stepped aside and the origin answered the request! Practically, this means that there is special handling for this specific path on Cloudflare that circumvents the firewall. What can we do with that? Cloudflare's SSL/TLS Custom hostnames is for managing domains and uses ACME to verify ownership. By starting the verification process on their domain, they had a long-lived access token that could be tested on all Cloudflare hosts. In Spring and Tomcat, the known path traversal quirk ..;/ performed a directory traversal on the website but was considered valid at the original path on Cloudflare. NextJS made it possible to leak some details that are normally not public (I don't get this one). In PHP, many websites route through a single parameter in the URL. By exploiting the vulnerable Cloudflare path in combination with this PHP functionality, the WAF could be bypassed. On top of just detouring around 404s, WAF rules like blocking headers could also be ignored. The patch was to just remove this edge case for access. It's just no longer possible to hit this endpoint behind a WAF anymore. Amazing bug! It seems like they saw something interesting while scanning, wanted to understand why and found a great issue. I personally feel there are a lot of distractions, like the PHP using an LFI or interactions with the Crypto.com CISO, but I found it great otherwise.
Analysis Summary
# Vulnerability: Cloudflare WAF Bypass via ACME Challenge Path Exception
## CVE Details
- **CVE ID:** Not assigned (Vendor-specific logic flaw)
- **CVSS Score:** N/A (Estimated High: 7.5 - 8.5)
- **CWE:** CWE-285: Improper Authorization, CWE-425: Direct Request (Forced Browsing)
## Affected Systems
- **Products:** Cloudflare Web Application Firewall (WAF)
- **Versions:** All versions prior to the patch (Reported circa 2023/2024)
- **Configurations:** Any origin server protected by Cloudflare WAF where "SSL/TLS Custom Hostnames" (Cloudflare for SaaS) or standard ACME certificate provisioning was enabled.
## Vulnerability Description
Cloudflare implemented a "WAF bypass" rule for the specific path `/.well-known/acme-challenge/*`. This was designed to ensure that Certificate Authorities (CAs) could always reach the origin to verify domain ownership via HTTP-01 challenges, even if the WAF was configured with restrictive "Block All" or "Under Attack" modes.
The flaw exists because this path exception was applied globally across the Cloudflare edge network without sufficient validation of the requester. Attackers could utilize valid ACME tokens (generated by their own Cloudflare accounts) or exploit path traversal quirks (e.g., `..;/`) to trick the origin server into serving unauthorized content through the trusted ACME path, effectively routing around all WAF security rules and header inspections.
## Exploitation
- **Status:** PoC demonstrated by researchers; fixed by vendor.
- **Complexity:** Medium (Requires knowledge of path traversal quirks or specific backend routing).
- **Attack Vector:** Network (Remote)
## Impact
- **Confidentiality:** High (Ability to bypass WAF to access hidden files or internal parameters).
- **Integrity:** Medium (Potential to bypass security headers or input validation filters).
- **Availability:** Low (Primarily an authorization bypass).
## Remediation
### Patches
- **Cloudflare Side:** The vendor has removed the universal edge-case exception for this path. Requests to the ACME challenge endpoint are now subject to WAF evaluation or more stringent verification. No action is required by end-users on the Cloudflare dashboard.
### Workarounds
- **Origin-Level Filtering:** Ensure that the origin server only responds to `/.well-known/acme-challenge/` requests with the specific tokens required and denies any request containing path traversal characters (e.g., `..`) at the application level.
- **IP Whitelisting:** Restrict access to the ACME path specifically to known Certificate Authority IP ranges (though this is difficult as many CAs use dynamic ranges).
## Detection
- **Indicators of Compromise:**
- Unusual traffic patterns directed at `/.well-known/acme-challenge/`.
- Requests to the ACME path containing URI encoded characters like `%2e%2e%2f` or semicolons `;`.
- 200 OK responses for the ACME path originating from IPs not associated with known CAs (e.g., Let's Encrypt, Google Trust Services).
- **Detection Methods:** Review origin access logs for requests where the `request_uri` contains the ACME path but the `upstream_response_time` or `bytes_sent` suggests a successful bypass to a different application component.
## References
- **Cloudflare Blog (General ACME info):** hxxps[://]www[.]cloudflare[.]com/learning/ssl/what-is-the-acme-protocol/
- **Original Research Context:** (Based on Sam Curry / Team members' research regarding Cloudflare WAF bypasses)
- **Related Path Traversal Quirk:** hxxps[://]portswigger[.]net/daily-swig/context-lookup-vulnerability-in-spring-cloud-function-could-allow-waf-bypass