Turning Cloudflare Into an SSRF Engine, Reaching What You Were Never Meant to See

[Editor note: Raymond identified a potential SSRF issue within Cloudflare infrastructure. While initially difficult to exploit due to limitations and unexpected behavior, further investigation confirmed real impact. By leveraging Cloudflare’s SSRF, we were able to access internal services otherwise unreachable, including bypassing certificate-based authentication. This post shares Raymond’s insights into using Cloudflare as a proxy to internal systems not normally accessible. ~ Chris Dale]

When “working as designed” still creates real security risk: a Cloudflare SSRF case study

Together with Chris, I recently reported a potential Server-Side Request Forgery (SSRF) issue to Cloudflare’s public bug bounty program.

After a long technical back-and-forth, Cloudflare ultimately closed the report as Informative, stating that the behavior is expected and intentional.
While we respect the decision, we feel the community needs to know about the risks of using Cloudflare’s solution.

Using this finding we were able to bypass other security restrictions, accessing systems that are otherwise not accessible from the internet.

What we found

When accessing certain sites over cleartext HTTP, it is possible to:

  • Send a request to a Cloudflare IP
  • Override the Host header or use Absolute form request
  • Have Cloudflare fetch content from an arbitrary HTTP hostname
  • Receive the response back through Cloudflare

In practice, this allows Cloudflare’s infrastructure to be used as an SSRF proxy:

Why Cloudflare says this is not a vulnerability

Cloudflare’s position is essentially:

  • Their anycast architecture relies on the Host header or Absolute Form Requests for routing
  • Any Cloudflare edge IP can serve any customer
  • Forwarding requests based on Host and Absolute Form Request is fundamental proxy behavior
  • No guaranteed access to Cloudflare internal services was demonstrated

From a pure infrastructure perspective, this is true – the system behaves exactly as designed and according to the RFC for proxy http requests.

Why we believe this is a real security problem

The issue is not theoretical routing behavior, it’s rather how customers actually deploy Cloudflare.

In the wild, we demonstrated that this can be used to:

  • Access HTTP services that are not internet-reachable
  • Bypass IP-based allowlists that trust “only Cloudflare”
  • Reach systems where Cloudflare IPs bypass authentication
  • Access services even when Cloudflare proxying is disabled (DNS-only mode)

This is a very common configuration:

“Only allow Cloudflare IPs, block everything else.”

Many organizations assume with this setup:

  • If proxying is disabled → Cloudflare is not in the request path
  • If access is limited to Cloudflare IPs → the service is effectively private

Both assumptions turn out to be wrong for HTTP:

We set up a web service following cloudflares instructions of IP whitelisting: https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/ . We did so with the intent that this server should only be accessible from cloudflare WHEN we the Proxy status as “Proxied”.

Requesting the “cloudflaretest” webservice from the internet:

Using Cloudflare as a SSRF engine:

Target host is set ut Riversecurity.eu, but can be any DNS that is pointet at Cloudflares Loadbalancer.

Using the Absolute Form Request: “GET http://cloudflaretest.REDACTED.no” (using GET h://cloudflaretest.REDACTED.no also works)

Using this method we are able to access the service, even though the configuration in Cloudflare is not set to proxy the traffic.

We also found using our River Security`s Active Focus , a service on the internet that let us bypass client certificate auth when accessing them using the SSRF in Cloudflare.

Why we think this matters

  • Cloudflare unintentionally becomes “SSRF as a service” to systems considered to be private
  • Customers may expose internal or semi-internal systems without realizing it
  • The issue is systemic, not customer-specific
  • The risk is amplified where Cloudflare IPs are trusted more than external traffic

Even if this is “by design”, the impact is real, especially given how widely these firewall deployment patterns are used.

What we think should change

  • Clear warnings to customers that DNS-only ≠ not reachable
  • Explicit documentation that Cloudflare, and then external users, can still fetch HTTP content
  • Prevent proxying to hostnames that are not marked as Proxied
  • Or acknowledge that Cloudflare provides a de-facto HTTP SSRF surface to anything pointed to in Cloudflare’s DNS

Final thoughts

Bug bounties often focus on what a platform guarantees.
Security, however, is also about how platforms are actually used.

This is a good example of how “working as intended” can still create real-world risk, and why shared responsibility needs very clear boundaries.

Happy to discuss, debate, or dive deeper with anyone interested.