Cloudflare WAF Bypass: Reaching the Origin Behind the Edge
A Cloudflare block page is not a wall. It is a filter sitting between you and an origin that usually trusts whatever reaches it. Two questions decide whether you have a finding: can you talk to the origin directly, and can you smuggle a payload the managed ruleset misses? Answer either one and the WAF stops mattering.
Let me start with the part everyone forgets.
The origin is often unlocked
Cloudflare only protects traffic that actually goes through Cloudflare. If the origin IP is reachable, an attacker skips the edge entirely and the WAF becomes decorative.
Hunt the real address before you touch a single payload:
- Old DNS records in SecurityTrails, DNSDumpster, or crt.sh certificate history
- Mail servers, staging subdomains, and
dev.hosts that never moved behind the proxy - SPF and MX records pointing at the same box
- A verbose error, a
Locationheader, or a favicon hash that ties an IP back to the brand
If you find a candidate, request the site by IP with the correct Host header. A matching response that carries none of Cloudflare's cf-ray or server: cloudflare markers means you are talking to the origin. That alone is reportable: the program paid for edge protection and isn't getting it.
When you must go through the edge
Sometimes the origin genuinely locks down to Cloudflare IP ranges. Now the game is the managed ruleset itself. WAF rules match patterns, and patterns have blind spots.
Things I test in order:
- Case and encoding:
SeLeCt, double URL-encoding, mixed%2fand/, overlong UTF-8 - Body vs query placement — a rule may inspect one and skip the other
Content-Typeswaps, especiallyapplication/jsonwhere the app also accepts form data- Chunked transfer encoding and oversized bodies that push payloads past an inspection size cap
- Comment and whitespace injection inside SQL or XSS payloads
The classic win is a payload that the origin parses one way and the WAF another. Send {"q":"' OR 1=1--"} where the ruleset only tuned itself for form-encoded SQLi, and the JSON path may sail through untouched.
Prove it lands, not just that it passes
A payload getting past the WAF is half a report. The other half is the origin doing something with it. Chain the bypass to a real behavior — a reflected marker, a boolean SQL difference, an authenticated action — using your own account and a unique canary string so triage can trace the request.
Keep volume low. Cloudflare rate-limits and challenges aggressively, and a thousand rapid probes will get your session flagged long before you learn anything. A dozen well-chosen requests beat a scanner run.
What triage will push back on
"I bypassed the WAF" is not an impact statement. If the origin sanitizes input correctly, the bypass is at most an informational note. Report the underlying vulnerability with the WAF bypass as the delivery method: "reflected XSS reachable despite Cloudflare Managed Rules via double-encoded payload," with the exact request and the cf-ray header proving it traversed the edge.
When you report a direct-origin exposure, include the IP, the Host header you used, and a response diff against the proxied site. Recommend firewalling the origin to Cloudflare IP ranges (Authenticated Origin Pulls help), rotating the IP after exposure, and treating WAF rules as one layer rather than the fix.
Cloudflare's own WAF documentation explains how managed rules and rule ordering work — worth reading, because knowing which ruleset a program runs tells you which blind spots are even worth probing.