Cloudflare-Bypass: Origin server deserves some love too

Cloud-Flare-Under-Control-Kit

[C.F.U.C.K]

Late one night, something caught my eye during a routine recon sweep: the apex (root) domain of a wildcard SSL cert resolved to an IP address that wasn’t Cloudflare’s. Out of curiosity, I pinged the IP directly. The server bounced me to www, but when I tried again using a curl trick to spoof the original host, I got a 200 OK response—without any Cloudflare headers in sight. This meant I’d likely hit the origin server itself, bypassing the usual protection.

I’d always encountered random IPs while probing, but it wasn’t until then that I realized how simple it was to accidentally reveal them. The culprit? Many organizations place only the www subdomain behind the Cloudflare orange cloud, leaving the apex set to DNS-only (grey cloud). The result: a DNS lookup on the apex reveals the real origin IP, exposed to anyone nosy enough to check. If that server isn’t locked down, attackers can go straight to the source, sidestepping Cloudflare’s security features entirely.

Cloudflare DNS Modes: Orange vs. Grey

Cloudflare DNS records can be set in two ways:

• DNS-only (Grey Cloud): DNS responses return real A/AAAA/CNAME records. Traffic heads directly to the origin. Your real IP is public.
• Proxied (Orange Cloud): DNS returns Cloudflare IPs, routing all traffic through Cloudflare’s infrastructure (CDN, WAF, SSL, etc.). Origin IPs stay hidden.

My Recon Script (and What I Found)

I wrote a script to scan thousands of domains, checking whether apex and www resolve to different IPs (clue: one is exposed, one is behind Cloudflare). You can use any DNS source . The script:

• Resolves both apex and www IPs.
• Flags domains where the apex IP looks unProxied.
• Runs some curl tests for confirmation.
• Sends results to my Discord for review.

After running this on around 40,000 targets, over 30 showed clear exposure patterns. A recurring theme: big, old organizations keeping apex DNS on legacy platforms for email/routing reasons but shifting only www to Cloudflare. This split-DNS isn’t necessarily wrong, but it’s an easy mistake to expose the origin if security controls aren’t reinforced.

Three Curl Tests to Confirm Exposure

Disclaimer: Only test this on assets you own or have explicit permission for.

curl -vk --resolve example.com:443:52.44.185.177 https://example.com/

Forces example.com to resolve to the given IP, simulating direct origin access. If you get a response without Cloudflare headers, the origin is exposed.

curl -vk --resolve www.example.com:443:52.44.185.177 https://www.example.com/

Checks if www can also be hit directly via the origin IP. If it works, the subdomain is exposed outside Cloudflare too.

curl -vk --resolve example.com:443:52.44.185.177 https://www.example.com/

Connects to the IP but asks for www’s host header. Shows how the origin responds to potentially mismatched host/SNI.

More cases to test

If you already have the target server’s IP address, you can focus on bypassing Cloudflare’s protections.

Try running this command to see a Cloudflare 403 Forbidden response (access denied):

curl “https://www.target.cn/en/%3Cscript%3Ealert()%3C/script%3E" -I

Now, bypass Cloudflare by connecting directly to the origin server IP using curl’s — resolve option:

curl -vk — resolve www.target.cn:443:41.196.11.11 “https://www.target.cn/en/%3Cscript%3Ealert()%3C/script%3E" -I

You should see a 404 Not Found response. This indicates that you have bypassed Cloudflare because the request no longer passes through Cloudflare’s network.

Another check you can perform is to access Cloudflare’s unique endpoint:

curl “https://www.target.cn/cdn-cgi/trace" -I

This returns a 200 OK response with Cloudflare headers.

Now connect directly to the origin IP again:

curl -vk — resolve www.target.cn:443:41.196.11.11 “https://www.target.cn/cdn-cgi/trace" -I

This time, you will get a 404 response without the “server: cloudflare” header. This clearly shows you are connecting directly to the origin, bypassing Cloudflare.

(Optional) To confirm in a browser, you can configure Burp Suite to resolve the hostname manually:

Open Burp Suite → Proxy → Options → Network → Hostname Resolution.

Add a manual mapping for:

Hostname: www.target.cn

IP Address: 41.196.11.11

Reload the page in your browser. Now you are connected straight to the origin server, fully bypassing Cloudflare’s protections.

Here is Clear Bypass and XSS to ATO on Employee only

Practical Tips

• --resolve matches curl’s host string exactly; mismatched host means it’s ignored.
• To connect to an IP but specify a different Host/SNI:

curl -vk --connect-to ::52.44.185.177:443 https://www.example.com/ 
curl -vk https://52.44.185.177/ -H "Host: www.example.com"

• SNI matters for TLS: origin servers serve different certs based on the SNI sent; mismatches cause warnings.

Why Is This Setup So Common?

Organizations split DNS for legitimate reasons:

• Mail/Service Records: MX, SPF, DKIM, and various verifications often require apex flexibility.
• Legacy Infrastructure: Old DNS platforms host apex for routing/internal reasons, with only www on Cloudflare.
• Migration Caution: Gradual migration (apex last) helps avoid outages.
• Redirect Patterns: apex→www redirects are common, but if you only Cloudflare the www, the apex remains exposed.

These are logical choices, but any public-facing origin IP must be access-controlled.

The Real Risk: Unrestricted Origin Access

Here’s the critical flaw: if your origin IP is public and accepts arbitrary connections, Cloudflare’s protections can be bypassed. An attacker just hits the IP directly. It’s a classic origin exposure gap.
Public origin IP + no firewall allowlist = bad news.

How To Fix and Prevent Misconfigurations

• Lockdown the origin: Only allow Cloudflare’s IPs in your firewall. Their list is public — use it.
• Authenticated origins: Require mTLS/origin certs so only Cloudflare can connect.
• Migration hygiene: Document, monitor, and set controls from day one — even if split-DNS is temporary.
• Regular audits: Test if apex and www resolve differently and if origins answer directly. Fix immediately if so.

Ethics & Disclosure (And a Common XSS PoC)

If you find an exposed origin, don’t explore further than necessary to verify exposure. Document response headers, status codes, and SSL details for your report. Disclose to the site owner or their security team, or use their bug bounty program.

For those with permission or in your own testing, classic XSS PoCs (as with any open origin) can be tested to verify payload reflection. For example, a simple SVG-based XSS payload for logging can be:

Always use such payloads only on authorized scopes, and never as proof for exploitation beyond initial verification.