Many developers believe that putting a site behind Cloudflare is enough to secure it. However, if your origin IP is exposed, your security posture can crumble quickly. In a recent investigation, I found that an exposed origin IP led directly to a Blind Server-Side Request Forgery (SSRF) via WordPress's legacy XML-RPC pingback feature.

The Vulnerability Chain

This attack wasn't a single "silver bullet" but a chain of two distinct issues:

  1. Origin IP Exposure: The server's direct IP (162.240.7x.8x) was reachable. Because Cloudflare's WAF only protects the public-facing domain, hitting the origin IP directly allowed me to bypass all perimeter defenses.
  2. XML-RPC Pingback (CVE-2013–0235): The WordPress xmlrpc.php endpoint was active and accepting pingback.ping requests. This is a legacy feature that tells a server to "check" a link; effectively making the server request on your behalf.

The Proof of Concept (PoC)

By sending a specially crafted POST request to the origin IP, I directed the server to resolve an attacker-controlled domain.

The Evidence:

  • The Request: A curl command sent a pingback.ping method call to the origin IP.
  • The Response: The server returned a faultCode: 0, indicating it successfully processed the request.
  • The Callback: An Out-of-Band (OOB) DNS callback was confirmed on my interactsh listener. The DNS query originated from Google/hosting infrastructure (172.25x.19x.147), proving the server made the outbound connection.
None
None
Out-of-Band (OOB) DNS callback, Auto Download for the call back reponse to be downloaded directly to my comptuer.

Why "Blind" SSRF is Still a High Risk

This is considered "Blind" because while I can make the server reach out, I cannot read the content it receives back. However, the severity remains High for several reasons:

  • Internal Reconnaissance: The server can be used to port scan internal services and probe the internal network.
  • Cloud Metadata Access: If the environment migrates to cloud providers (AWS/GCP/Azure), this provides a direct path to hit metadata endpoints (like 169.254.169.254) to steal temporary credentials.
  • WAF Ineffectiveness: Even though Wordfence was installed, it failed to block the request because the traffic was hitting the origin IP directly, bypassing the primary defense.

How to Fix It

If you're running WordPress, you should take these steps immediately:

  • Disable XML-RPC: If you don't use the WordPress mobile app or remote posting, disable xmlrpc.php entirely.
  • Block Pingbacks: If you need XML-RPC, at least block the pingback.ping method specifically.
  • Protect the Origin: Ensure your origin IP only accepts traffic from Cloudflare's IP ranges at the firewall level.

Closing Tip

When testing for SSRF, always look for timing differences. Even in a blind scenario, if a request to an internal port takes 5 seconds to fail but a request to an external one takes 1 second, the server is still "leaking" information about the internal network state.