If you look at your server logs, you will probably find repeated requests to a file called xmlrpc.php. Possibly thousands of them.
XML-RPC in WordPress is a remote-access interface that has been enabled by default for years. Most sites do not use it. Attackers use it constantly.
What it was for
XML-RPC lets external applications interact with WordPress remotely — publishing posts, fetching content, managing the site without logging into the dashboard.
It made a lot of sense when it was introduced. Desktop blogging clients, mobile apps and cross-site publishing all needed a way in, and this was it.
Then WordPress introduced the REST API, which does the same job with modern authentication and finer-grained permissions. XML-RPC became the legacy option — still present, still enabled, largely unused.
Why attackers like it
Two specific properties make it more useful to an attacker than the normal login page.
Amplified brute force
This is the significant one. Through the standard login form, an attacker tries one password per request. Rate limiting notices that pattern quickly.
XML-RPC supports a method called system.multicall, which bundles many operations into a single request. An attacker can attempt hundreds of username and password combinations in one HTTP request.
Your rate limiter sees one request. The attacker got five hundred password attempts out of it. That asymmetry is the whole appeal.
Pingback abuse
The pingback feature makes your site fetch a URL to verify a link. An attacker can ask thousands of WordPress sites to all fetch the same target simultaneously, turning them into an unwitting distributed attack.
In that scenario you are not the victim. You are the weapon, and your server resources pay for it.
Do you actually need it?
For most sites, no. Check whether any of these apply before disabling.
You probably do not need it if you manage the site through a browser, do not use the WordPress mobile app, and do not run Jetpack or a remote management service.
You may need it if you use the official WordPress mobile app for publishing, run Jetpack (though it increasingly uses other methods), use a multi-site management tool that depends on it, or have a custom integration built against it.
The honest test is simply to disable it and see whether anything breaks. Almost nothing will.
How to disable it
Block it at server level — best option
The requests never reach PHP, so they consume almost no resources. In Apache, add to .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
On Nginx, your host adds a location block returning 403. Ask them — it is a routine request.
Via a filter
Add to your theme's functions.php:
add_filter('xmlrpc_enabled', '__return_false');
Simpler, but the request still reaches WordPress before being rejected, so it uses more resources than blocking at server level.
Via your firewall or security plugin
Most security plugins have a one-click option. Convenient, and equivalent to the filter approach in terms of resource cost.
Disable pingbacks only
If you need XML-RPC for the mobile app but want to stop the pingback abuse, you can disable just that method rather than the whole interface. A reasonable middle position.
Being honest about how much this matters
Some perspective, because this gets over-sold in security checklists.
Disabling XML-RPC does not make your site secure. It closes one amplification route for password guessing. If your passwords are strong and two-factor authentication is on, that route was not going to succeed anyway.
What it genuinely delivers:
- Less wasted server load — on a heavily probed site this is measurable, and sometimes the reason a small server keeps hitting resource limits
- Cleaner logs, which makes real problems easier to spot
- One less amplification vector if a weak password does exist somewhere
- No longer participating in pingback-based attacks on others
It is a sensible, low-cost tidy-up. It is not a substitute for the items in our hardening checklist that actually matter most — patching quickly and enabling two-factor.
The signal worth watching
Heavy XML-RPC traffic in your logs tells you something useful regardless of whether you disable it: your site is being actively probed.
That is normal background noise on the internet and not a cause for alarm on its own. But it does mean automated tools have found you and are testing what works. If your passwords are weak or a plugin is outdated, those same tools will find that too.
Our guide to WordPress login security covers what to do about the attempts themselves, and why WordPress sites get hacked covers why this is happening to a site nobody has heard of.
What to do about it
- Check your logs for
xmlrpc.phprequests to see the current volume - Confirm nothing you use depends on it — mobile app, Jetpack, management tools
- Block it at server level if you can, or via a filter if not
- Confirm publishing and any integrations still work
- Watch your logs for a week to confirm the traffic is being rejected
Fifteen minutes of work, and one fewer thing consuming your server.
If you would rather not touch server configuration
Editing .htaccess on a live site makes plenty of people nervous, reasonably so — a mistake there takes the whole site down.
Our security monitoring service includes a managed firewall that handles this and a good deal more, filtering abusive traffic before it reaches WordPress at all.
Get in touch if you would rather have the whole traffic-filtering layer handled properly rather than assembled from individual tweaks.
Get Shielded
We build, host, secure and monitor business websites — cleaning up hacks and keeping sites online for clients across the UK, USA, Australia and the UAE.
