Curated summary
How we mitigated a vulnerability in Cloudflare’s ACME validation logic
CloudflareNetwork SecurityWeb Application FirewallSsl TlsAcme ProtocolHttp 01 ChallengeDomain Validation
Cloudflare disclosed and patched a vulnerability in its ACME HTTP-01 validation logic. Certain challenge requests could disable Web Application Firewall (WAF) protections even when Cloudflare was not serving the requested validation token, allowing the request to reach the customer’s origin without normal WAF processing. The issue was reported through Cloudflare’s bug bounty program, and Cloudflare found no evidence of exploitation; customers do not need to take action.
ACME HTTP-01 Validation
- ACME automates the issuance, renewal, and revocation of TLS certificates.
- For HTTP-01 validation, a certificate authority checks for a token at:
/.well-known/acme-challenge/{token}
- When Cloudflare manages the certificate order, it serves the expected token directly.
- If the token is not associated with a Cloudflare-managed order, the request may be forwarded to the customer’s origin for validation by another system.
The Logic Flaw
- Cloudflare temporarily disabled certain WAF features for matching ACME challenge requests.
- This was necessary because WAF processing could interfere with certificate authorities retrieving valid challenge tokens.
- The flaw occurred when a request matched an active token associated with a different zone rather than the requesting hostname.
- In that case, Cloudflare disabled WAF protections but forwarded the request to the origin instead of serving an ACME response.
- This created a path where requests could bypass applicable WAF rulesets.
Mitigation
- Cloudflare released a code change restricting security-feature bypasses.
- WAF features are now disabled only when:
- The request matches a valid ACME HTTP-01 token for the requested hostname, and
- Cloudflare has the corresponding challenge response to serve.
- Requests that do not meet these conditions continue through normal security processing.
Disclosure and Customer Impact
- FearsOff researchers reported the vulnerability on October 13, 2025, through Cloudflare’s bug bounty program.
- Cloudflare patched the issue and reported no evidence of malicious exploitation.
- Customers require no configuration changes or other action.
Cloudflare’s recommended outcome is continued use of the platform without customer intervention, while its security team emphasizes responsible disclosure and rapid, transparent remediation.
Related reading
Continue with another curated summary.
Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave
Read originalCloudflare WAF protects WordPress applications from two high-severity vulnerabilities
Read originalRoute public traffic to private applications with Cloudflare
Read originalDefend against frontier cyber models: Cloudflare's architecture as customer zero
Read original