If you've ever opened your access logs and seen a wall of POST /xmlrpc.php requests hitting your site every few seconds, you're not imagining things. xmlrpc.php is one of the oldest, most abused files in WordPress core, and on a lot of sites it's doing nothing useful except giving attackers a door to knock on. Here's what it actually does, why it causes CPU spikes and lockouts, and how to shut it down without breaking anything you actually use.
What xmlrpc.php Is Actually For
xmlrpc.php implements the WordPress XML-RPC API — a remote-procedure-call interface that lets external apps talk to your site over HTTP instead of the regular admin dashboard. It's been part of core since WordPress 3.5, mainly to support things like:
- The old WordPress mobile apps (some still use it)
- Jetpack (uses XML-RPC for a chunk of its features, even now)
- Legacy blog clients like Windows Live Writer or MarsEdit
- Some third-party publishing and syndication tools
Most sites built and managed entirely through wp-admin with the REST API (which handles the block editor, Gutenberg, and most modern plugins) don't need it at all. That's exactly why it's such an easy thing to disable — but you do need to check Jetpack first.
Symptom: What You'll See When It's Being Abused
Two attack patterns show up over and over:
1. Brute-force login via wp.getUsersBlogs
XML-RPC supports a method called system.multicall, which lets an attacker bundle hundreds of username/password guesses into a single HTTP request. Instead of hundreds of separate login attempts (which fail2ban or a login-limit plugin would catch), it's one request trying hundreds of combinations internally. This is why xmlrpc.php abuse slips past normal wp-login.php brute-force protection — it's a completely different endpoint doing the same job faster.
2. DDoS pingback abuse
XML-RPC's pingback feature (pingback.ping) can be weaponized to make your server send HTTP requests to thousands of other sites, using your server as an unwitting participant in a distributed attack. You'll notice this as sudden outbound traffic spikes and, often, your server's IP getting blacklisted by other hosts.
Either way, the practical symptoms are the same: CPU usage pinned near 100%, MySQL connections maxed out, cPanel's Resource Usage showing repeated warnings, and sometimes your account getting suspended for excessive server load.
Check Before You Disable Anything
Before you block xmlrpc.php outright, confirm you're not relying on it:
- Jetpack users: Jetpack's connection to WordPress.com still depends on XML-RPC for some functionality (especially on older Jetpack versions). Check Jetpack's status page in wp-admin before fully blocking the file — a hard block can disconnect Jetpack entirely.
- Mobile app users: if you or an editor publishes posts from the WordPress mobile app, some older app builds still call XML-RPC. Test after disabling.
- Third-party integrations: some marketing/CRM tools that pull blog content still poll XML-RPC. If you're not sure, check your access logs for legitimate-looking XML-RPC traffic from a known IP before you block everything.
If none of that applies — which is true for the vast majority of self-managed WordPress sites — go ahead and disable it.
Fix 1: Block It at the Web Server (Recommended)
Blocking at the server level stops the request before WordPress even loads, which saves you PHP and MySQL overhead — this matters a lot when you're actively under attack.
For Apache/LiteSpeed on cPanel, add this to your site's .htaccess, above the WordPress block:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
If you're on Jetpack and still need limited XML-RPC access, allow specific WordPress.com IP ranges instead of a blanket deny — check Jetpack's current documented IP list before hardcoding it, since it does change.
For Nginx (common on SkyServer VPS setups running WordPress behind a reverse proxy), add this inside your server block:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 403;
}
Reload Nginx after saving: sudo nginx -t && sudo systemctl reload nginx.
Fix 2: Disable via a Plugin (No File Editing)
If you'd rather not touch server config — or you're on shared cPanel hosting without SSH — a plugin is the easiest route. Security plugins like Wordfence, iThemes Security, or a dedicated "Disable XML-RPC" plugin all expose a simple toggle. Wordfence in particular blocks XML-RPC brute-force attempts specifically, without fully disabling the file, which is useful if you still need it for Jetpack.
Fix 3: Filter It in functions.php (If You Manage Your Own Theme)
For a code-level fix without editing server config, add this to your child theme's functions.php:
add_filter('xmlrpc_enabled', '__return_false');
This disables the XML-RPC API cleanly through WordPress itself, but note it doesn't stop the HTTP requests from reaching PHP — it just makes them fail faster once WordPress loads. For sites under active heavy load, the .htaccess/Nginx block in Fix 1 is more effective because it never invokes PHP at all.
Verify It's Actually Blocked
After applying a fix, test from your own machine:
curl -I https://yourdomain.com/xmlrpc.php
You want to see 403 Forbidden (server-level block) or a WordPress error response about XML-RPC being disabled (plugin/filter block). If you still get a 200 OK with an XML response, the block didn't take — check for caching (Cloudflare, LiteSpeed Cache, or a CDN edge cache can serve a cached 200 from before your change) and purge it.
Prevention: Keep It From Coming Back
| Layer | What to do |
|---|---|
| Server | Block xmlrpc.php in .htaccess or Nginx config — cheapest way to stop the load before PHP runs |
| WAF/Firewall | If you're on Cloudflare, add a firewall rule blocking POST requests to /xmlrpc.php at the edge, before it even reaches your server |
| Security plugin | Wordfence or similar to catch anything that gets through, and to alert you to new attack patterns |
| Monitoring | Watch cPanel's Resource Usage graphs weekly — a sudden CPU pattern that repeats on a schedule is often automated abuse, not real traffic |
One thing worth remembering: disabling xmlrpc.php doesn't fix a compromised site, it just closes one entry point. If you were already seeing signs of a breach — unfamiliar admin users, injected scripts, outbound spam — that needs a proper cleanup on top of this.
Frequently Asked Questions
Will disabling xmlrpc.php break my WordPress site?
For most sites, no. It only affects features that specifically use the XML-RPC API — mainly older mobile app publishing, Jetpack (partially), and some legacy blogging clients. The block editor, plugins, and normal wp-admin login are unaffected because they use the REST API or standard admin-ajax, not XML-RPC.
How do I know if something on my site actually needs XML-RPC?
Check your raw access logs for XML-RPC requests from IPs or user agents you recognize (like Jetpack's servers or your own mobile device), over a period of normal use — not during an attack. If everything is from unfamiliar IPs hitting it repeatedly, it's safe to block.
Is blocking xmlrpc.php the same as WordPress security hardening in general?
No — it closes one specific, commonly abused entry point. It should be one item in a broader checklist that also covers strong passwords, two-factor authentication, keeping plugins updated, and a web application firewall.
I use Jetpack — what should I do instead of a full block?
Don't hard-block the file. Either use a security plugin that specifically rate-limits or filters malicious XML-RPC calls (like Wordfence's XML-RPC protection) while leaving Jetpack's legitimate calls working, or allowlist Jetpack/WordPress.com's current IP ranges in your server block instead of denying everything.
Can I tell if I've already been targeted by an XML-RPC attack?
Grep your access logs for xmlrpc.php and system.multicall. A high volume of POST requests to xmlrpc.php from many different IPs, especially with repeated 200 responses, is a strong sign of an active or past brute-force attempt. Check your WordPress users list afterward for any admin accounts you don't recognize.
