XML-RPC WordPress: Should You Disable It? 4 Safe Methods

Your security scanner just flagged xmlrpc.php, or a developer told you to “turn off XML-RPC WordPress”. Should you? Closing it blocks real attacks, but it can also break tools you rely on.

This guide explains XML-RPC WordPress in plain words, shows who must keep it, and gives you 4 safe methods to disable it. You will also learn how to test the result and how to roll back in two minutes.

What is XML-RPC WordPress and what does xmlrpc.php do?

XML-RPC WordPress is an old remote-communication feature. It lives in one file, xmlrpc.php, in the root of your site. Other apps send XML requests to that file to log in, publish posts, upload media or read comments.

It was added so that desktop blogging tools and mobile apps could talk to a site before modern APIs existed. Since WordPress 3.5 it has been switched on by default.

That default is the reason it matters today. Most sites never use XML-RPC WordPress on purpose, but it stays open and answers anyone who knocks.

To see if yours is open, visit yoursite.com/xmlrpc.php. The message “XML-RPC server accepts POST requests only” means XML-RPC WordPress is active.

Why attackers target xmlrpc.php

Attackers like XML-RPC WordPress for two reasons. It is easy to find, and it can be abused at scale. The two common abuses are brute force logins and pingback requests.

xmlrpc.php brute force attack

The login page limits how fast a bot can guess passwords, and most firewalls watch it closely. The xmlrpc.php brute force attack tries to avoid that. A single XML-RPC request can bundle many login attempts through the system.multicall method.

That means a bot can test many passwords in one request. Rate limits that count requests, not guesses, may never notice.

Pingback DDoS abuse

Pingbacks let one blog tell another “I linked to you”. Attackers misuse this feature by sending pingback requests through many WordPress sites. Each site then makes a request to the victim.

The victim receives traffic from thousands of honest-looking servers. Your site becomes an unwilling helper in a pingback DDoS, and it burns your own server resources too.

REST API vs XML-RPC: which one should you use?

The REST API is the modern replacement. It uses JSON, works with standard HTTP tools and ships with WordPress core. It also supports Application Passwords, so apps can log in without your main password.

The REST API vs XML-RPC WordPress comparison is simple: new tools should use REST, and XML-RPC WordPress stays only for legacy software. Read more in the official REST API handbook.

Should you disable XML-RPC WordPress?

For most business sites the answer is yes. If nobody on your team publishes through a remote app, XML-RPC WordPress gives you risk and no benefit. Closing it is a standard hardening step, also listed in the WordPress hardening guide.

But do not close it blindly. Some tools still need it.

Who should NOT disable it

• Jetpack users. Jetpack uses XML-RPC to connect your site to WordPress.com. Blocking xmlrpc.php completely can break that connection. This is the classic Jetpack XML-RPC problem.
• Older WordPress mobile app setups. Some remote publishing flows still use XML-RPC. Test the app before you block it.
• Remote publishing services. Old desktop editors, some automation tools and a few third-party dashboards post through XML-RPC.
• Sites that rely on pingbacks. If you want pingback notifications, keep it open or use a narrower rule.

If you are not sure, check your access log for requests to /xmlrpc.php. Real traffic from a tool you know means you need a softer approach, such as allow-listing.

Before you start: a safe checklist

Take five minutes to avoid downtime. These steps apply to every method below.

1. Make a full backup of files and the database.
2. Write down any tool that publishes remotely (Jetpack, mobile app, automation).
3. Open yoursite.com/xmlrpc.php and note the current response.
4. Plan to test again right after the change, on a staging copy if you have one.

You can find more hardening steps in our WordPress security checklist.

4 safe methods to disable XML-RPC WordPress

Pick one method, not all four. Each one blocks XML-RPC WordPress at a different layer. The earlier the block, the less load reaches WordPress.

Method 1: Use a security plugin setting

This is the easiest way to disable XML-RPC WordPress without touching code. Many security plugins, such as Wordfence, Solid Security and All In One WP Security, include an XML-RPC option.

Open the plugin settings, search for “XML-RPC”, and choose to disable it or to block only authenticated requests. Save the change and clear your cache.

Pros: no code, easy to undo. Cons: WordPress still loads for each request, so the server does a little work.

Method 2: Use the xmlrpc_enabled filter

Add one line to your child theme functions.php or a small custom plugin. This disables XML-RPC WordPress methods that need a login.

add_filter( 'xmlrpc_enabled', '__return_false' );

This filter stops authenticated calls, which protects you from login guessing. To also remove the pingback method, add this snippet:

add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Note: the file still answers, so a test shows an XML error message instead of a 403.

Method 3: Block xmlrpc.php in .htaccess

The .htaccess rule stops the request at the web server, before WordPress loads. It works on Apache and on LiteSpeed. Add it above the # BEGIN WordPress block, after you back up the file.

<Files xmlrpc.php>
    Require all denied
</Files>

This is the cleanest way to block xmlrpc.php with .htaccess on modern hosting. On very old Apache 2.2 servers, use Order deny,allow and Deny from all instead. Nginx servers need a location = /xmlrpc.php rule in the server config.

Method 4: Block it in a firewall or Cloudflare

The best layer is the edge. A web application firewall stops the request before it even reaches your server. In Cloudflare, create a custom WAF rule with this expression and set the action to Block:

(http.request.uri.path eq "/xmlrpc.php")

Need to keep Jetpack? Add a second rule that allows its servers first, or choose a managed firewall that handles this for you. See how we set this up in our WordPress firewall guide.

How to test that XML-RPC is really blocked

Do not trust the setting, test it. Use any of these checks:

1. Open yoursite.com/xmlrpc.php in a private browser window.
2. Or run curl -i https://yoursite.com/xmlrpc.php in a terminal.
3. Check the status line and the response body.

With methods 3 and 4, you should see 403 Forbidden. With method 2, you will see an XML message that XML-RPC WordPress services are disabled. With method 1, the result depends on the plugin setting.

Then log in to your dashboard, publish a draft and check the tools you listed earlier. If Jetpack or an app stops working, roll back.

How to roll back if something breaks

Rolling back is easy, because every method is a small change.

• Plugin: switch the XML-RPC option off again.
• Filter: remove the line from functions.php.
• .htaccess: delete the <Files xmlrpc.php> block or restore the backup.
• Firewall: disable the custom rule.

Clear your cache after each change, so visitors and tools see the current state.

Common mistakes to avoid

• Blocking everything without checking Jetpack or a mobile app first.
• Stacking four methods at once, which makes problems hard to trace.
• Editing .htaccess with no backup, which can cause a 500 error.
• Thinking this is the whole job. Closing xmlrpc.php does not replace strong passwords, updates and a firewall. Treat this change as one layer of protection.

Security is layered. If you want a second pair of eyes on your site, see our website security services and compare plans on the prices page.

XML-RPC WordPress FAQ

Summary

XML-RPC WordPress is a legacy feature that attackers use for brute force and pingback abuse. Most business sites can disable it safely, unless they use Jetpack or a remote publishing tool. Choose one of the 4 methods, test for a 403 response, and keep a rollback plan ready.