What Is WordPress XML-RPC and Should You Disable It?

XML-RPC is one of those WordPress features most business owners have never heard of — but hackers know it extremely well. It's a frequent target for brute-force attacks and DDoS amplification.

What Is XML-RPC?

XML-RPC (xmlrpc.php) is a protocol allowing external applications to communicate with WordPress remotely. Originally built for desktop blogging tools and the WordPress mobile app. It accepts authenticated requests to perform almost any WordPress action.

Why Is It a Security Risk?

Brute-force amplification: XML-RPC allows testing hundreds of username/password combinations in a single HTTP request via system.multicall. Attackers can try thousands of passwords with a single request — far more efficient than the login page. DDoS amplification: The pingback.ping method can use your site to attack other sites without your knowledge, making your business an unwitting participant in cybercrime.

Who Actually Needs It?

Very few businesses. You need it only if you: use the WordPress mobile app via XML-RPC (modern versions use the REST API instead), use desktop blogging clients like MarsEdit, or have a specific custom application requiring it. When in doubt, disable it for a week and see if anything breaks.

How to Disable XML-RPC

Security plugin: One checkbox in Wordfence or similar security plugin. Easiest. .htaccess (Apache): Add: <Files xmlrpc.php> Deny from all </Files> Nginx config: Add: location = /xmlrpc.php { deny all; } WordPress filter: Add to functions.php: add_filter('xmlrpc_enabled', '__return_false');

What About the REST API?

Do NOT disable the WordPress REST API. It's required by the Gutenberg editor, Jetpack, and many plugins. The REST API is a modern, more secure replacement for XML-RPC — disable XML-RPC, keep the REST API.

How to Tell If You're Already Being Targeted

Most small business owners have no idea whether their XML-RPC endpoint is actively being attacked, because the traffic looks unremarkable in normal analytics — it's server-level, not visible in Google Analytics. The clearest signal is in your server or security plugin's access logs: repeated POST requests to /xmlrpc.php, often in rapid bursts, frequently from a rotating set of IP addresses. A security plugin like Wordfence will typically flag and log these attempts directly, sometimes showing dozens or hundreds of blocked attempts per day on a site that's never been specifically targeted by anyone you'd know about — this is automated, opportunistic scanning that hits nearly every public WordPress site eventually, not something personal.

The Jetpack Exception

One common wrinkle: sites running Jetpack, one of the most widely installed WordPress plugins, rely on XML-RPC for part of how the plugin authenticates and communicates with WordPress.com’s servers, even though the actual vulnerable methods described above aren’t the ones Jetpack uses. Completely blocking xmlrpc.php at the server or .htaccess level, as described above, can break Jetpack’s connection and any features that depend on it, like downtime monitoring or the mobile stats app.

The more precise fix, if you run Jetpack, is disabling only the risky methods rather than the entire file: system.multicall (used for brute-force amplification) and pingback.ping (used for DDoS amplification) specifically, while leaving the rest of XML-RPC’s functionality intact for Jetpack to use. A security plugin like Wordfence typically offers this as a separate option from a full XML-RPC block, sometimes labeled something like "disable pingback" rather than "disable XML-RPC entirely" — worth checking for before assuming a full block is safe.

If you don’t run Jetpack or another plugin that depends on XML-RPC, this distinction doesn’t matter, and a full block is simpler and strictly safer. The practical rule: disable XML-RPC completely by default, and only step back to the selective version if something you’re actively using turns out to depend on it.

If Jetpack is already installed, a quick way to sanity-check this is to look at its connection status under Jetpack → Settings before and after disabling XML-RPC entirely. If the connection stays healthy afterward, the specific set of modules you have active likely doesn’t depend on it, and a full block is fine to leave in place. If the connection drops or a feature like downtime monitoring stops reporting, switching to the selective, pingback-only block resolves it without giving up the plugin’s other functionality.

Common Questions