Cloudflare Bypass via Exposed Origin IP: A Deep Dive Into Smit Gharat’s Discovery

Disclaimer

This article is for educational and defensive cybersecurity purposes only. All testing techniques shown here must be used only on systems you own or have explicit permission to audit. Unauthorized testing is illegal and unethical.

Introduction

Cloudflare is widely trusted as the front-line shield for millions of websites. It provides DDoS mitigation, caching, WAF filtering, SSL termination, and many more layers of protection. Yet, all of this security can be bypassed if the origin server itself is exposed.

This blog post analyzes a real-world discovery by security researcher Smit Gharat, who found an elegant yet impactful Cloudflare bypass caused by a commonly overlooked DNS configuration issue. The vulnerability allowed direct communication with the origin server, effectively sidestepping Cloudflare’s defenses.

This article walks through the entire thought process, methodology, root cause, safe validation techniques, potential impact, and recommended remediations. It’s written to be beginner-friendly while still providing deep technical understanding for security engineers.

Understanding the Problem: Cloudflare Protects Only What It Sees

Cloudflare sits between users and a website’s backend server. But it can only filter traffic that passes through it. If an attacker finds a way to communicate with the origin server directly, Cloudflare becomes irrelevant.

This bypass is possible when:

• The website’s real server IP is publicly exposed
• DNS is misconfigured (common in apex/root domains)
• Firewall rules on the origin allow unrestricted traffic

In such cases, an attacker simply connects to the origin server’s raw IP with a spoofed Host header. If the origin responds, Cloudflare is bypassed completely.

This is exactly what Smit discovered.

The Discovery Begins: A Routine Recon Turning Into a Breakthrough

During wide-scope reconnaissance across thousands of domains, Smit noticed something interesting: the apex domain of a target resolved to an IP that didn’t belong to Cloudflare.

The thought process was simple:

• The website uses Cloudflare
• But the apex domain (example.com) returns a non-Cloudflare IP
• If that IP belongs to the real origin server…
• Then Cloudflare’s protections can be bypassed

This observation alone isn’t surprising - but what came next was crucial.

Smit forced the domain to resolve to the exposed IP using a common curl trick. When he did this, the server responded without Cloudflare headers, confirming he had reached the origin server directly.

This meant:

• Cloudflare → bypassed
• WAF → bypassed
• Rate limiting → bypassed
• DDoS mitigation → bypassed
• Security rules → bypassed

A direct line to the backend was open.

Why Apex Domains Expose Real IPs (A Common Misconfiguration)

Many organizations proxy their www subdomain through Cloudflare, but leave the apex/root (example.com) in DNS-only mode.

Reasons include:

• Legacy DNS setups
• Mail routing depending on apex records
• Old cPanel systems
• Migration-in-progress domains
• Misconfigured hosting panels
• Partial Cloudflare integration

This results in:

• www.example.com → protected by Cloudflare
• example.com → leaking real origin IP

Attackers love this pattern because it’s incredibly common and easy to exploit.

Confirming the Exposure: Safe Curl Tests

Smit used three simple curl tests to confirm Cloudflare bypass safely and without causing harm. These techniques are industry-standard for origin exposure detection.

Test 1 - Direct Origin Access

Forces the domain to resolve to the suspected origin IP:

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

If Cloudflare is bypassed, the response will:

• Load directly from origin
• Show no Cloudflare headers
• Possibly reveal server technology or custom responses

This is often the first sign of misconfiguration.

Test 2 - Testing www on the Same Origin IP

If the www variant also responds directly through the origin IP:

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

Then the organization unintentionally exposed the entire website.

Test 3 - Host/SNI Mismatch Test

Checks how the origin handles mismatched hostname/SSL:

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

If TLS still negotiates and serves content, the origin does not validate SNI strictly.

This is another serious misconfiguration.

Going Deeper: Cloudflare 403 vs Origin 404

Cloudflare’s WAF is strict about malicious payloads.

For example:

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

Will typically return:

• 403 Forbidden
• Server: cloudflare

But bypassing Cloudflare via the origin IP:

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

Returns:

• 404 Not Found
• No Cloudflare headers

This proves the request did not pass through Cloudflare infrastructure.

Cloudflare Trace Method

Cloudflare provides a diagnostic endpoint:

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

Returns:

• Cloudflare metadata
• Confirmation of protective routing

But hitting the origin IP directly:

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

Produces:

• 404
• No Cloudflare headers
• No security layer

Another strong confirmation.

Browser-Level Verification via Burp Suite

To avoid repeated curl commands, Smit used Burp Suite to route browser requests directly to the origin:

Burp → Proxy → Options → Network → Hostname Resolution

Add mapping:

• Hostname: www.target.cn
• IP: 41.196.11.11

Now the browser accesses the origin directly.

This is useful for testing UI behavior that curl cannot fully replicate.

The Real Impact: XSS Leading to Employee Panel Takeover

Once Smit reached the origin directly, Cloudflare’s WAF protections no longer blocked suspicious payloads. This allowed him to test harmless XSS reflection behavior safely.

On the origin server:

• Payloads executed
• Input validation failed
• Reflected JavaScript rendered
• Session handling was weaker
• Sensitive endpoints were reachable

This eventually enabled:

• XSS execution
• Privilege escalation
• Access to employee-only interfaces
• Authentication bypass opportunities
• Potential ATO on internal accounts

None of this would have been possible through Cloudflare because Cloudflare would have intercepted and blocked the payloads immediately.

This highlights why misconfigured origin servers are one of the highest risk Cloudflare setup mistakes.

Why This Misconfiguration Is Extremely Common

Origins often leak IPs because organizations:

• Enable Cloudflare only for www
• Maintain legacy services on apex
• Run CPANEL or WHM with autogenerated DNS
• Host email systems using root domain
• Forget to migrate apex DNS to Cloudflare
• Assume Cloudflare auto-protects everything
• Use “grey cloud” for MX/SRV/A records
• Misinterpret Cloudflare’s DNS proxying rules

Security teams may not realize that DNS-only = origin exposed, even if Cloudflare is enabled elsewhere.

This is why origin exposure is widespread and regularly exploited.

Why Direct Origin Access Is Dangerous

Directly accessing the origin server means:

• Cloudflare’s DDoS protection is bypassed
• Cloudflare WAF rules are bypassed
• Cloudflare rate limiting is bypassed
• Cloudflare bot filtering is bypassed
• Real server IP is revealed
• Attack surface expands dramatically

If the origin server:

• allows direct traffic
• has open ports
• has weak TLS config
• has misconfigured routing
• hosts vulnerable endpoints

…then the attacker bypasses the most important layer of defense.

Smit Gharat’s Practical Testing Tips

1. --resolve must match the host exactly

If it doesn’t match, curl ignores the override.

2. To connect to IP with different Host/SNI

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

or:

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

This is useful for probing origin behavior that depends on Host header.

3. TLS reveals configuration leaks

Origin servers may present:

• Wrong certificates
• Development-stage certificates
• Multi-tenant certificates
• Internal-only certificates

Each reveals important clues.

Defensive Perspective

To eliminate Cloudflare bypass risk, organizations must protect the origin server properly.

Once these measures are in place, Cloudflare bypass becomes nearly impossible.

Troubleshooting Common Pitfalls

Even experienced teams overlook these issues:

• Apex/root left in DNS-only mode
• Email routing tied to apex
• MX/SPF/DKIM records interfering with proxying
• Legacy systems still resolving old DNS entries
• CDN migration halfway done
• Hosting panels auto-adding public A records
• Multiple subdomains with inconsistent protection
• IP leaks via certificate transparency logs
• API endpoints mapped directly to origin IPs

Every one of these can expose origin servers accidentally.

Final Thoughts

Smit Gharat’s research demonstrates an important lesson:

Cloudflare protects you only if ALL traffic flows through Cloudflare.

If the origin server is reachable directly:

• Cloudflare can be bypassed
• Vulnerabilities become exploitable
• XSS becomes dangerous
• Admin panels become reachable
• DDoS protection becomes irrelevant
• Attack surface expands massively

Organizations must take origin protection seriously. Misconfigurations like DNS-only apex domains may seem harmless, but they can break the entire security posture.

The fix is simple:

• Lock down origin servers
• Proxy all public records
• Enable firewall allowlists
• Audit DNS regularly

A small configuration mistake can create a massive security gap. But with careful checks and regular audits, this can be prevented entirely.

Happy hacking - and stay safe.