XML-RPC is enabled on your WordPress site right now — and you almost certainly didn't turn it on.
It ships enabled by default. It has for years. And while most site owners have never opened xmlrpc.php, attackers run automated scripts that probe it thousands of times per hour across the web.
This isn't hypothetical exposure. This is how credential-stuffing attacks, botnet amplification, and brute-force login attempts get launched against WordPress sites at scale — through a single endpoint you probably forgot existed.
What XML-RPC Actually Is (and Why It Still Exists)
XML-RPC is a remote procedure call protocol that WordPress implemented to allow external applications — think the old WordPress mobile app, Jetpack remote connections, and third-party publishing tools — to communicate with your site without using the admin dashboard.
It predates the REST API by nearly a decade.
The REST API now handles everything XML-RPC used to do, better and more securely. But WordPress left XML-RPC enabled for backward compatibility. That's a reasonable default for a platform serving 43% of the web. It's a poor default for your specific site if you're not actively using it.
The endpoint lives at yoursite.com/xmlrpc.php. It accepts POST requests. It requires no browser session. No cookie. No authenticated UI flow. Attackers love it because it's a machine-to-machine interface with no native rate limiting baked in, and it sits at a predictable, unchanging URL on every WordPress install.
The Actual Attack Mechanics
Here's what makes XML-RPC dangerous in practice — not in theory.
Brute Force at Scale
Standard login brute force through wp-login.php is rate-limited by most security plugins and WAFs. One request, one login attempt. It's slow.
XML-RPC doesn't work that way.
The system.multicall method allows multiple method calls in a single HTTP request. A single POST to xmlrpc.php can attempt hundreds of username/password combinations simultaneously. You could be taking 500 brute-force login attempts per second while your server logs show a trickle of requests.
Most IP-based rate limiting misses this entirely because the volume of HTTP requests looks normal. The damage happens inside each request — invisible to tools built to count request frequency rather than inspect payload.
DDoS Amplification via Pingbacks
XML-RPC handles WordPress pingbacks — the mechanism by which one WordPress site notifies another that it linked to it.
An attacker can send a forged pingback request to your xmlrpc.php, instructing your server to make an outbound HTTP request to a target URL. If attackers weaponize thousands of WordPress sites this way simultaneously, your site becomes the origin of a distributed denial-of-service attack — not the victim.
Your server fires the requests. Your IP takes the reputation hit. Your host flags your account. And you find out when your hosting provider sends a suspension notice.
Credential Harvesting
If XML-RPC is enabled and an attacker finds valid credentials through multicall brute force, they gain authenticated API access to your site. They can publish posts, modify content, extract user data, and install plugins — all without ever touching wp-admin.
In most compromised site recoveries, the access vector isn't always the admin login page. XML-RPC is a persistent alternate entry point most site owners never think to close — because the dashboard never mentions it exists.
The Default Behavior Problem
WordPress enables XML-RPC by default. Your hosting panel doesn't flag it. Your dashboard doesn't warn you. It just sits there — publicly accessible, POST-accepting, and probed constantly by automated bots.
Most security audits we run on sites find xmlrpc.php fully exposed with zero rate limiting, no IP restrictions, and no monitoring in place. It's not a surprise anymore. It's the baseline.
The core issue isn't that XML-RPC is catastrophically broken. It's that it's unnecessary for most sites, yet it carries real attack surface. That's a bad trade — and it's one you never consciously agreed to.
Do You Actually Need XML-RPC?
Before disabling it, check whether anything on your site depends on it.
Active XML-RPC dependencies include:
- Jetpack — Some Jetpack modules use XML-RPC for remote site management. Jetpack has moved much of this to its own API, but older configurations may still hit
xmlrpc.php. - WooCommerce legacy integrations — Some older third-party WooCommerce inventory or ERP integrations hit XML-RPC endpoints.
- Mobile publishing apps — The legacy WordPress mobile app required XML-RPC. Modern versions use the REST API.
- IFTTT / Zapier automations — Some older automations that post content to WordPress still use XML-RPC.
If you run any of the above, test in a staging environment before disabling. Apply changes there first, confirm nothing breaks, then push to production. Never test security changes directly in production on a live site with real traffic.
If none of these apply — and for most WordPress sites, none of them will — you don't need XML-RPC. Disable it.
How to Disable XML-RPC in WordPress
Three reliable methods. Choose based on your level of access and risk tolerance.
Method 1: Disable via .htaccess (Recommended for Most Sites)
Block access at the server level before WordPress even loads. Add this to your .htaccess file:
# Block XML-RPC
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
This returns a 403 Forbidden to any request hitting xmlrpc.php. No PHP execution. No WordPress bootstrap. Clean and lightweight.
.htaccess hardening beats plugin-based blocking because a plugin disables XML-RPC after WordPress loads — .htaccess stops the request before PHP runs. During a bot flood, that difference matters for server resource consumption.
Method 2: Disable via wp-config.php Filter
Manage this at the WordPress layer through a must-use plugin — not a regular plugin, which anyone with admin access can deactivate:
add_filter('xmlrpc_enabled', '__return_false');
Place it in a file inside /wp-content/mu-plugins/. It runs automatically on every request, cannot be deactivated from the admin panel, and anyone reviewing the codebase can see it.
Establish a rollback strategy before pushing to production — if this breaks a Jetpack connection or a third-party integration, you need a clean path back. A working backup you've tested matters more than a backup that just exists.
Method 3: Disable via WP-CLI
For managing multiple sites or automating this across an environment:
wp eval 'add_filter(\"xmlrpc_enabled\", \"__return_false\");'
For persistent enforcement, push this to a must-use plugin. But WP-CLI makes it fast to test and confirm the filter works before committing it to code. Use wp eval to verify the filter fires:
wp eval 'var_dump(apply_filters(\"xmlrpc_enabled\", true));'
If it returns bool(false), the filter is active. If it returns bool(true), something's overriding it — usually another plugin re-enabling XML-RPC, which happens more often than you'd expect.
What Disabling XML-RPC Won't Fix
Disabling XML-RPC removes one attack vector. It doesn't constitute a security posture.
REST API exposure — WordPress's REST API (/wp-json/) exposes user enumeration endpoints by default. /wp-json/wp/v2/users returns usernames publicly. Locking XML-RPC while leaving user enumeration open via REST API is locking the front door while the window stays open. Attackers use enumerated usernames to target brute-force attacks with higher precision.
wp-login.php brute force — The standard login page still accepts brute-force attempts. XML-RPC's multicall amplification disappears once you block it, but individual login attempts continue until you implement rate limiting or two-factor authentication. Both are necessary.
Plugin vulnerabilities — Most WordPress hacks in the wild trace back to abandoned or unpatched plugins. Outdated plugins with known CVEs represent a higher-probability attack vector than XML-RPC for most sites. Plugin abandonment risk is real — if the author stopped pushing updates six months ago, your site runs unpatched code indefinitely, and no amount of XML-RPC hardening compensates for that.
wp_options table abuse — Compromised sites frequently use the wp_options table to persist malicious code through injected transients or autoloaded malware payloads. Once an attacker gains access through any vector, that's where the persistence mechanism often lives. Regular audits of autoloaded data in wp_options catch this pattern early — before cleanup becomes a full site recovery.
Cron job abuse — WordPress cron jobs (wp-cron.php) can run scheduled malicious tasks post-compromise. Attackers register cron entries that re-infect files or beacon to external hosts on a schedule. Auditing your cron job entries after any security incident — and monitoring for unexpected additions — is standard practice in any serious hardening workflow.
A real security posture covers all of these. If you want a structured view of what complete WordPress hardening looks like, see our full WordPress maintenance checklist.
The Audit Pattern We See Consistently
Across dozens of WordPress security audits, the pattern is consistent: XML-RPC exposed, REST API user enumeration open, wp-login.php without rate limiting, PHP version compatibility lagging two major releases behind, and the last plugin update sitting three months back.
No single item here is catastrophic in isolation. Together, they represent a site maintained reactively — you fix things when they break. Meanwhile, the attack surface accumulates quietly in the background.
Sites that get compromised aren't always running ancient WordPress versions. They often run current core versions — with plugins untouched for months, endpoints never reviewed, and no monitoring to catch anomalies before they escalate into a full incident. The breach isn't dramatic. It's methodical.
What a Real Hardening Workflow Looks Like
Here's the sequence for hardening a site properly:
- Audit current exposure — XML-RPC, REST API endpoints, login page rate limiting, user enumeration via
/wp-json/ - Set up a staging environment — All changes get tested on staging before touching production. Non-negotiable.
- Apply .htaccess hardening — XML-RPC block, directory browsing disabled, sensitive file access restricted
- Enforce authentication hardening — Two-factor authentication on all admin accounts, login attempt limits, admin URL change where applicable
- Review and patch plugins — Identify abandoned plugins, replace or remove, audit for known CVEs. Check PHP version compatibility while you're in there.
- Set up monitoring — File integrity monitoring, login anomaly alerts, uptime checks. You need to know when something changes, not find out after the fact.
- Document and test the rollback path — A tested backup restore procedure, not just "backups exist." There's a significant difference between the two.
If your current maintenance workflow skips the staging environment or lacks a verified rollback strategy, steps 3–6 carry real production risk. You can break a Jetpack integration, disrupt a custom connection, or trigger a white screen — and without a rollback, you debug in production under pressure, with real users watching.
Where Vimsy Fits
If you manage a WordPress site with real traffic or revenue attached to it, security hardening isn't a one-time task. The attack surface shifts as plugins update (or don't), as WordPress core evolves, and as new CVEs emerge in tools you're running right now.
Our WordPress support services include ongoing hardening reviews — not one-time fixes. Staging workflows, anomaly monitoring, plugin audits, and the incremental security work that prevents the emergency calls at 2am.
If you want to see what managed maintenance costs versus emergency recovery, review our pricing. The math is straightforward — proactive is always cheaper than reactive.
For sites already showing signs of an active attack or compromise, our emergency WordPress support runs 24/7.
The Bottom Line
Disabling XML-RPC takes five minutes and removes a meaningful attack vector from your site. There is no reasonable argument for leaving it enabled if you're not using it.
But XML-RPC is just the most visible part of a broader default-exposure problem in WordPress. Most sites ship with multiple attack surfaces open because that's how the platform defaults work. Closing them requires deliberate, informed action — not just installing a security plugin and calling it done.
Look — I'm writing this because this is a problem I see constantly, and it's also exactly what we built Vimsy to solve. If you want professionals handling this instead of hoping nothing breaks, book a free call.
Your site doesn't announce when bots probe it. By the time you see it in the logs, the attempt count already sits in the thousands.
