How to Disable XML-RPC in WordPress to Reduce Security Risk

WordPress ships with a feature called XML-RPC — a remote access protocol that lets external applications communicate with your site over HTTP. It was originally designed for tools like Windows Live Writer, the Jetpack mobile app, and third-party blogging clients to publish content remotely.

Most WordPress sites no longer use it. But it stays active by default, and that makes it a persistent target. Bots scan for xmlrpc.php constantly, using it to run brute-force login attempts and amplification attacks — often bypassing the login protections you’ve already put in place.

Disabling XML-RPC is a five-minute change that removes an attack surface your site almost certainly doesn’t need.

Quick Answer

To disable XML-RPC in WordPress, install the free Disable XML-RPC plugin, add a filter to your functions.php file, or block access to xmlrpc.php at the server level. The plugin is the simplest option and works immediately on activation.

Why This Matters

WordPress’s XML-RPC endpoint — the file xmlrpc.php in your root directory — accepts requests from any IP address on the internet by default. Even if you’ve set up login attempt limits or a security plugin, XML-RPC can sidestep those protections by design.

One particularly effective attack is the multicall exploit: an attacker bundles hundreds of login attempts inside a single XML-RPC request. Because it appears as one request to the server, brute-force limiting tools may not trigger. A single crafted XML-RPC call can test thousands of username and password combinations without raising the usual alarms.

Beyond brute-force, open XML-RPC endpoints have been used in DDoS amplification attacks — where attackers send forged requests to xmlrpc.php that cause your server to flood a third-party target with traffic. If you’re not using Jetpack, the WordPress mobile app, or a tool that specifically requires XML-RPC access, there’s no practical reason to leave it running.

How to Disable XML-RPC in WordPress

There are three methods, from simplest to most thorough. In most cases, Method 1 is all you need.

Method 1 — Disable via Plugin

The Disable XML-RPC plugin by Dave McHale handles this cleanly with no configuration required.

1. Go to Plugins → Add New in your WordPress dashboard
2. Search for “Disable XML-RPC”
3. Install and activate the plugin by Dave McHale
4. No further configuration needed — XML-RPC is disabled immediately on activation

The plugin hooks in early in the WordPress load process, before xmlrpc.php handles any incoming requests. It’s lightweight, actively maintained, and does exactly one thing.

Method 2 — Disable via functions.php

If you prefer not to add a plugin for a one-line fix, add this to your child theme’s functions.php file:

add_filter( 'xmlrpc_enabled', '__return_false' );

This uses WordPress’s built-in xmlrpc_enabled filter to return false whenever the system checks whether XML-RPC should respond. It works at the application level — xmlrpc.php still exists and PHP still loads, but WordPress refuses to process any XML-RPC requests.

This is fine for most sites. If you want to prevent the file from loading entirely, Method 3 gives you a tighter block.

Method 3 — Block at the Server Level

Blocking xmlrpc.php at the server level means the file never loads — no PHP runs, no WordPress boots. This is the most resource-efficient approach and the one I use on sites where I have full server access.

Apache (.htaccess) — add this above your WordPress rewrite rules:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Nginx — add this inside your server block:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

On shared hosting, you can usually edit .htaccess via cPanel’s File Manager but won’t have access to the Nginx config. Use the plugin or functions.php approach in that case.

Practical Tips

Check your access logs before making the change. If you’re seeing hundreds of requests hitting xmlrpc.php, you’ll notice an immediate drop in server load once it’s disabled. Most hosts expose access logs through cPanel or your hosting dashboard — worth a look before and after.

Verify the block worked. After disabling, visit yourdomain.com/xmlrpc.php directly in a browser. If the page still returns “XML-RPC server accepts POST requests only,” the method didn’t take effect. A correctly disabled or blocked endpoint returns a 403, 404, or blank response.

Treat this as part of a layered setup. Disabling XML-RPC removes one attack vector — it works best alongside a WordPress firewall and a full security audit. In the sites I build, I treat these as a standard first-day security checklist.

Common Mistakes

Partially blocking XML-RPC. Some guides suggest disabling only the system.multicall method while leaving the rest of the endpoint accessible. This reduces one specific attack type but keeps the file open. Unless you have a clear reason to keep certain XML-RPC methods available, disable it entirely.

Adding the filter to a parent theme. If you add add_filter( 'xmlrpc_enabled', '__return_false' ) to a parent theme’s functions.php, the next theme update will overwrite it. Always use a child theme for any custom code — or use the plugin, which is entirely theme-independent.

Assuming Jetpack is fine without checking. Older versions of Jetpack relied on XML-RPC to connect to WordPress.com. If you’re running Jetpack, verify which version you have and what it requires before disabling — newer versions use the REST API, but it’s worth confirming first.

Plugin, Code, or Server Block — Which to Choose

Use the plugin if you want a simple, update-proof solution that works across all hosting environments. It’s the most accessible option and doesn’t require touching theme files or server config.

Use the functions.php filter if you’re managing a deliberately lean plugin list and are comfortable working in a child theme. It’s a reliable one-liner with no plugin overhead.

Block at the server level if you manage your own server or have access to your hosting’s config files. Combined with HTTP security headers and firewall rules, this gives you the most efficient security posture with no application-layer overhead.

Conclusion

Disabling XML-RPC takes less than five minutes and removes a real attack surface. Choose the plugin for the simplest setup, the functions.php filter for a code-only approach, or the server-level block for the most efficient outcome. It’s a standard step in the step-by-step process of building and securing a WordPress website — and if you need to check whether any of your integrations still rely on it, WordPress’s XML-RPC documentation lists what currently depends on the protocol.