Why XML-RPC Should Be Disabled on Your WordPress Host

If you have ever opened a server access log and seen thousands of POST requests hitting one file, there is a good chance that file was xmlrpc.php. That is the main reason XML-RPC should be disabled on your WordPress host: it is a legacy remote publishing protocol that most sites no longer use, yet it remains one of the most reliably abused endpoints in WordPress. Turning it off at the server level removes an entire category of brute force and amplification traffic.

What XML-RPC Actually Does

XML-RPC is a remote procedure call protocol that lets external applications talk to WordPress over HTTP using XML payloads. It shipped with WordPress long before the REST API existed, back when people published posts from desktop clients like Windows Live Writer and early mobile apps.

The endpoint lives at yourdomain.com/xmlrpc.php and it has been enabled by default since WordPress 3.5. Every install has it, whether you use it or not, and that is the core of the problem.

The protocol supports a long list of methods: publishing posts, uploading media, editing users, fetching options and accepting pingbacks. In 2026, almost all of that work is handled better by the WordPress REST API combined with application passwords.

The Three Ways Attackers Abuse xmlrpc.php

Attackers do not target XML-RPC because it is broken. They target it because it is predictable, unauthenticated until the final step, and it does not respect the login page protections most site owners install.

• Brute force amplification via system.multicall. A single HTTP request can carry hundreds or even thousands of username and password guesses in one XML payload. What would take 500 separate login attempts on wp-login.php becomes one request that your firewall counts as one request.
• Pingback DDoS reflection. The pingback.ping method makes your server fetch a URL the attacker supplies. Thousands of innocent WordPress sites can be pointed at one victim, turning ordinary blogs into an unwitting attack network.
• Resource exhaustion. Even failed XML-RPC requests spin up PHP, load WordPress, hit the database and burn CPU. On shared or entry-level plans, a sustained flood can push response times past 3 seconds before any real visitor arrives.

The OWASP guidance on brute force attacks makes the same underlying point: rate limiting only works when each guess costs the attacker a request. Multicall breaks that assumption completely.

How to Tell If XML-RPC Is Being Hit Right Now

You do not need special tooling to check. Open your raw access logs and search for the string xmlrpc, then look at the volume and the source IPs.

1. Filter the last 24 hours of logs for POST requests to /xmlrpc.php.
2. Count unique IP addresses. Legitimate use comes from a handful of known services, not 400 residential IPs across a dozen countries.
3. Check the response codes. A wall of 200s with large request bodies usually means multicall payloads are being processed.
4. Compare that traffic against your real pageviews. We regularly see sites where XML-RPC requests outnumber human sessions by a factor of five or more.

If your host surfaces request-level data, this takes about two minutes. Our WordPress hosting analytics dashboard breaks traffic down by endpoint, so you can see junk requests separated from genuine visitors without touching the command line.

What You Might Break by Disabling It

This is the honest part, because blanket advice to “just block it” has burned people before. A small number of integrations still speak XML-RPC, and you should check before you flip the switch.

• Older Jetpack setups that have not been reconnected in years, though modern Jetpack uses its own authenticated connection.
• Legacy desktop publishing clients and a few third-party automation tools that never migrated to the REST API.
• Pingbacks and trackbacks between blogs, which most publishers disabled years ago because of comment spam.
• Very old mobile apps, since the official WordPress app switched to REST endpoints and application passwords.

If none of those apply, and for the vast majority of business sites they do not, disabling XML-RPC costs you nothing. Sites that publish through a deployment pipeline or Git-based WordPress hosting workflow have even less reason to keep it, because content and code already move through authenticated channels.

Server Level vs Plugin Level: Where to Block It

A plugin that disables XML-RPC still lets the request reach PHP and load WordPress before it returns an error. That protects your passwords, but it does not protect your CPU. Blocking at the web server or edge stops the request before any application code runs.

Edge or firewall rule (best)

A WAF or CDN rule that drops requests to /xmlrpc.php means the traffic never touches your origin at all. This is the only approach that fully neutralises a high-volume flood, and it pairs naturally with the rest of your WordPress hosting security stack.

Web server rule (very good)

On Nginx or LiteSpeed, a location block returning 403 for that path costs almost nothing in resources. On Apache, a <Files xmlrpc.php> directive with Require all denied does the same job.

Filter in WordPress (acceptable fallback)

Adding add_filter('xmlrpc_enabled', '__return_false'); turns the protocol off inside WordPress. Use it when you have no server access, and understand that PHP still boots for every request.

What a Good Host Should Do by Default

Disabling XML-RPC is a five-second job for a platform and a recurring headache for an individual site owner. We think the host should handle it, with an override available for the rare account that genuinely needs the endpoint.

• Blocked by default at the edge, with a toggle rather than a support ticket.
• Rate limiting on wp-login.php too, because attackers simply move there once XML-RPC closes.
• Logged and visible, so you can see what was blocked instead of guessing.
• Application password support for the integrations that actually need programmatic access.

Store owners should go further, since checkout endpoints and customer data raise the stakes considerably. Our rundown of essential WooCommerce security features covers what belongs in that layer. If you handle EU or California customer data, the overlap with GDPR and CCPA hosting compliance is worth reading alongside it, because logging and breach exposure are part of the same conversation.

A Quick Hardening Sequence

Do these in order and the whole job takes under fifteen minutes on most sites.

1. Check logs for current XML-RPC volume and confirm nothing legitimate is calling it.
2. Block /xmlrpc.php at the firewall or web server, then request the URL yourself and confirm a 403.
3. Disable pingbacks in Settings, Discussion, so you stop participating in reflection attacks.
4. Create application passwords for any tool that needs API access, and remove unused ones quarterly.
5. Recheck logs a week later to see where the attack traffic moved.

Portfolio and small publisher sites benefit just as much as large ones, which is why blocking it is standard on our WordPress hosting for creatives plans rather than an upgrade.

Frequently Asked Questions

Does disabling XML-RPC break the WordPress mobile app?

No, not since the app moved to the REST API with application passwords, which has been the default path for several years. Generate an application password under Users, Profile, and the app connects normally with XML-RPC fully blocked.

Is XML-RPC still enabled by default in WordPress?

Yes, XML-RPC has been enabled by default since WordPress 3.5, released in December 2012, and core has not removed it. The protocol remains in core for backward compatibility, so every fresh install exposes xmlrpc.php until you or your host blocks it.

How much traffic does XML-RPC abuse actually generate?

On an average small business site we commonly see 2,000 to 20,000 automated requests to xmlrpc.php per day, entirely unrelated to real visitors. Sites with any search visibility tend to sit at the higher end, since scanners work through public URL lists continuously.

Should I use a plugin or a server rule to disable it?

Use a server or firewall rule whenever you have access, because it stops the request before PHP loads and saves roughly 30 to 60 milliseconds of processing per hit. A plugin filter is a reasonable fallback on locked-down hosting, but it still pays the resource cost.

Does blocking XML-RPC affect SEO or Google crawling?

No, search engine crawlers never request xmlrpc.php, so blocking it has zero effect on indexing or rankings. The indirect benefit is real though: less junk traffic usually means faster server response times, which Google does measure.

Want XML-RPC handled for you?

We block xmlrpc.php at the edge on every plan, log what gets stopped, and keep application passwords available for the integrations you actually use. Start a free trial or send us your current site and we will show you exactly how much of its traffic is noise.