xmlrpc.php Under Attack: Brute Force, Pingback Abuse & the Fix
By Glenn Lyvers · Updated · 5 min read
If you've opened your server logs and found thousands of POST requests hitting /xmlrpc.php, you're looking at one of the oldest and still most common automated attacks against WordPress. It isn't a mysterious new hack — it's a twenty-year-old API file being used the way it was designed to be used, just by someone who shouldn't have access. The good news is it's cheap to shut down once you understand what it's actually being used for.
What xmlrpc.php actually does
xmlrpc.php is WordPress's remote procedure call interface — it lets external software authenticate and perform actions on your site without going through the wp-admin dashboard. Historically that meant the official WordPress mobile app, blog-to-blog pingbacks and trackbacks, and third-party publishing tools. It's been part of WordPress core since long before REST API existed, and it's never been removed, mostly because removing it would break integrations nobody wants to be blamed for breaking.
The two ways attackers abuse it
Brute-force login via system.multicall. Normal wp-login.php brute forcing sends one username/password guess per HTTP request, which is slow and easy to rate-limit. xmlrpc.php's system.multicall method lets an attacker bundle hundreds of login guesses into a single POST request, tested server-side in one pass. That's the whole appeal: it turns a plugin like Wordfence's login rate limiter, which watches wp-login.php, into something an attacker can route around entirely — because from the outside, it looks like one request, not hundreds of attempts.
Pingback abuse for DDoS and reconnaissance. The pingback.ping method lets your server be told "notify this other URL about a link." Attackers abuse it two ways: as a distributed reflection attack, using thousands of vulnerable WordPress sites (possibly including yours) to flood a target with pingback requests it never asked for, and as a port-scanning tool, using your server's own outbound pingback request to probe internal network addresses it can reach but the attacker can't.
How to tell it's happening to you
The signature in your access logs is unmistakable once you know to look: a burst of POST /xmlrpc.php requests, often hundreds or thousands within minutes, frequently from a rotating set of IPs (a botnet, not one attacker), sometimes correlating with a spike in server load or your host's resource-usage warning. If you're on shared hosting, this kind of flood is a common trigger for a host suspending your account for "excessive resource usage" — see my hosting suspension guide if that's already happened. It's also worth checking whether the attack succeeded: look for the signs covered in my how sites get hacked guide, particularly new admin accounts and unexpected plugin or theme files.
Fixing it without breaking anything that needs it
Three approaches, from least to most disruptive:
Restrict access, don't remove the file. Block requests to xmlrpc.php at the web server level (.htaccess on Apache, a location block on Nginx) except from IPs you trust, or from Jetpack's published IP ranges if you rely on it. This keeps the file intact for WordPress core but closes it to the internet at large.
Disable system.multicall specifically. If you need pingbacks or another XML-RPC method to keep working but want to kill the brute-force vector, a small filter on the xmlrpc_methods hook can remove just that method rather than the whole file. This is the surgical option.
Use a security plugin's built-in toggle. Wordfence, iThemes Security and similar plugins ship a one-click "disable XML-RPC" or "block XML-RPC pingbacks" setting, which is the least effort and fine for sites that don't use the mobile app or Jetpack's legacy connection.
Whichever route you pick, don't literally delete the file from the filesystem — the next WordPress core update restores it, and you'll lose whatever protection you'd built around it. Configure around the file, not against it.
Will disabling it break anything?
For most sites, no — the WordPress mobile app and current Jetpack primarily use REST API authentication now, not XML-RPC. But "most sites" isn't "your site": if you or a client publishes through a third-party tool, an old blogging client, or a legacy Jetpack connection, test after you change anything rather than assuming. Disable, then actually try the workflow that might depend on it, before you consider the job done.
It's rarely the whole story
A flood of xmlrpc.php requests means someone found your site and is actively probing it — worth treating as a signal to check the rest of your security posture, not just this one file. If the attempts succeeded, you're looking at the same recovery path as any other compromise: find what they planted, close how they got in, and confirm nothing came back with my reinfection guide. If you'd rather I just handle the whole thing — the file, the check for success, and the hardening — that's exactly what my malware removal service covers.
Common questions
Is xmlrpc.php itself a security vulnerability?
Not on its own — it's a legitimate WordPress API file used by the mobile app, Jetpack, and some third-party integrations. The problem is what it lets an attacker do efficiently: bundle hundreds of login attempts into one request via system.multicall, or use pingback methods to bounce traffic at other sites. It's a feature that's convenient for attackers, not a bug in the traditional sense.
Should I just delete xmlrpc.php?
Don't delete it — WordPress core will simply recreate it on the next update, and deleting core files instead of configuring around them tends to cause confusing problems later. Block or restrict access at the web server or with a plugin instead, which survives updates and is easy to reverse if something turns out to need it.
How do I tell if xmlrpc.php brute forcing actually got in?
Check for the same signs as any successful login compromise: admin users you didn't create, changed admin email or password, new plugins or theme files you didn't install, and scheduled tasks that weren't there before. A flood of xmlrpc.php requests in your access logs tells you an attack was attempted, not that it succeeded — you have to check the account and file state separately to know which.
Does Jetpack need xmlrpc.php to work?
Older Jetpack versions did rely on XML-RPC for the connection to WordPress.com; current versions primarily use REST API authentication instead, but some legacy features can still fall back to it. If you run Jetpack, test your connection after any change rather than assuming — a plugin that whitelists Jetpack's own requests while blocking everything else is the safer route than a blanket disable.
Can xmlrpc.php abuse get my hosting account suspended?
Yes. Even failed brute-force attempts and pingback floods consume CPU and database connections, and shared hosts routinely suspend accounts for 'excessive resource usage' without distinguishing an attack from legitimate traffic. If a host has flagged or suspended you, see my guide to hosting account suspensions for how to get reinstated.