An XML-RPC pingback attack is a Layer 7 (application) reflection and amplification vector that turns thousands of legitimate websites into unwitting attack sources, one of the reflection classes a thorough DDoS test is built to exercise. The attacker sends each reflector a single small XML-RPC request that names the victim's URL as a pingback target; every reflector then makes a real HTTP request to the victim to "verify" the link. The victim sees a flood of GET requests arriving from a large pool of reputable, well-behaved server IPs.
How pingback reflection works
The vector abuses the pingback.ping method exposed by the XML-RPC endpoint (/xmlrpc.php) that older WordPress installs enable by default. The method takes a source URL and a target URL, and the server dutifully fetches the source to confirm it links back. An attacker supplies the victim's address as the source, so the reflector's "verification" fetch lands on the victim instead.
Unlike a UDP reflection attack, pingback rides on TCP and HTTP, so it needs no IP spoofing: the reflector opens a genuine connection to the victim from its own address. The amplification is modest per host, but the reflector pool is enormous and every member is a real, patched, reputable web server. Append a unique query string to the source URL and each reflected request also defeats caching, forcing a full origin hit.
Why it matters under attack
The traffic profile is the whole problem. Requests arrive from thousands of legitimate reflectors with clean IP reputation and plausible geography, so reputation lists and geo-blocking have little to grip. Each one is a well-formed GET, indistinguishable from an organic visitor, which makes this an HTTP flood wearing a crowd of respectable disguises.
If the origin is reachable directly, the flood skips any CDN or scrubbing layer entirely, the same origin-IP exposure weakness that undoes edge protection generally. And because the sources are real servers rather than a rented botnet, blocking one address accomplishes nothing; the next request comes from a different reputable host in the pool.
What a DDoS test measures
There are two questions, pointing in opposite directions. Outbound: is your own XML-RPC endpoint an open reflector that an attacker can enlist against someone else. Inbound: when a reflected flood lands on you, does anything distinguish it from real traffic. A test measures whether the pingback User-Agent can be filtered, whether cache-busting query strings punch through to the origin, and whether rate controls key on anything the reflector pool does not trivially spread across its members.
Crucially, validating this vector must not conscript real third-party servers into a live attack, which is exactly the discipline covered in DDoS testing without disrupting production: the reflection is modeled against your own controlled infrastructure, never fired through the open reflector population on the internet.
Closing the reflector, and why it is not enough
On the source side, the fix is direct: disable XML-RPC where it is unused, remove or filter the pingback.ping method, or gate /xmlrpc.php behind authentication so the endpoint cannot be enlisted. Doing so also shrinks the internet's total reflector pool, which is the neighborly thing to do even when you are not the target.
On the receiving side there is no single switch, because the traffic is real HTTP from real servers. The defenses that hold up are the ones that treat the flood as the HTTP flood it is rather than a reputation problem: caching that survives cache-busting query strings, request budgets per resource, and challenges that a headless verification fetch cannot answer. Identifying the pingback User-Agent buys a round, but a determined operator forges it, so the control that lasts is one keyed on behavior, not on a string.
The pingback attack is a reminder that reflection does not require a broken protocol or a spoofed packet. It only requires a helpful feature that fetches a URL on request, and the web is full of those. Disabling pingback.ping closes one door; the class of "make a trusted server fetch this for me" stays open across every service that offers link previews, webhooks, or callbacks.