What is XML-RPC? Security Risks, Best Practices, and How to Disable It

XML-RPC is a protocol that lets remote applications send commands to your site using XML and HTTP. In WordPress, it works through the xmlrpc.php file and was first created so tools like early mobile apps, desktop blogging clients, and remote publishing services could connect to your site without logging into /wp-admin.

For a long time, XML-RPC allowed people to publish content from anywhere. But WordPress has changed. Now, most remote connections work better with the WordPress REST API, which is more flexible, widely used, and designed for today’s development needs.

Do you still need XML-RPC? Sometimes you might, since some older tools or plugins still depend on it. But for most sites, it’s no longer needed. Keeping it enabled without a clear reason can make your site more vulnerable, especially if you’re not using it.

How the xmlrpc.php file works

You can think of xmlrpc.php as a special API entry point for WordPress. A remote app sends an HTTP POST request to https://example.com/xmlrpc.php with an XML message that tells WordPress what to do, such as publishing a post, logging in a user, getting comments, or sending a pingback.

WordPress reads the XML, matches the request to a function on the server, and tries to carry it out. If the action needs a login, the request includes credentials, which WordPress checks first. Then, WordPress sends back an XML response showing if it worked, failed, or if there was an error.

A key detail, and a reason attackers often target it, is that XML-RPC allows batching. This means a client can ask WordPress to do several things in one request. While this helps some tools work faster, it also makes it easier for bots to abuse the system.

Top security risks associated with XML-RPC

If you feel uneasy about XML-RPC, you have good reason. The endpoint is open to the public on many WordPress sites, and its design makes it a popular target for attackers.

Since XML-RPC can handle many commands in one HTTP request, attackers can use it to ramp up malicious activity quickly, especially for login attacks and boosting traffic. In reality, two main threats stand out:

• Brute force attacks that hammer credentials more efficiently than the standard login page
• DDoS-style abuse tied to pingbacks that can overwhelm a target with reflected traffic

Let’s look at both threats in detail, since understanding how they work can help you decide whether to block, limit, or turn off the endpoint.

Brute force attacks via system.multicall

An XML-RPC brute force attack usually relies on a method called system.multicall. This feature lets someone combine many actions into one request, such as sending hundreds of username and password attempts in a single POST to xmlrpc.php.

This matters because most security measures focus on /wp-login.php and limit failed login attempts. XML-RPC can get around these rules. Instead of sending hundreds of separate login tries, an attacker can send fewer requests, each packed with many login attempts.

Bots commonly abuse XML-RPC methods that require credentials (for example, publishing or retrieving site data) as a proxy for “is this password valid?” When one attempt succeeds, the response pattern changes, and the attacker learns they’ve found a working combination.

Even if the attacker fails, the server still uses CPU power to read the XML, check logins over and over, and send responses. This means there’s a risk of both account compromise and server overload, especially on busy sites.

DDoS attacks

Another major risk comes from XML-RPC’s pingback feature. Pingbacks were designed to let a site know when another site links to it. This was helpful in early blogging, but is less important today.

Attackers use pingbacks to create reflected traffic. They send special requests to many WordPress sites with pingbacks turned on, telling those sites to ping a target URL. If enough sites do this at once, the target gets flooded with requests and may slow down or go offline.

This works well for attackers because the attack comes from many real servers, making it hard to block by IP address. Also, every WordPress site involved uses resources to handle and send pingbacks, so you might notice slowdowns even if your site isn’t the main target.

Best practices for securing website data against XML-RPC attacks

If you don’t need XML-RPC, turning it off is usually the simplest and safest choice. But good security is more than just switching it off, especially if your business depends on certain integrations or older workflows.

Begin by checking what actually needs XML-RPC. If you can switch to the WordPress REST API, make the change. REST-based connections are usually easier to secure, monitor, and manage, and they fit with how WordPress is built today.

Next, strengthen your site’s defenses. A Web Application Firewall (WAF) is very effective at blocking harmful XML-RPC traffic, stopping known threats, limiting abuse, and catching bots before they reach your server.

Using the Sucuri Website Firewall, you can find this option in your Security settings where XML-RCP is blocked by default:

If you need to keep xmlrpc.php open, try to limit access by IP address or block certain XML-RPC features, like pingbacks, instead of leaving everything open.

Finally, keep a close eye on your site. Check your server logs for repeated POST requests to /xmlrpc.php, large request sizes, or sudden bursts from one IP address. These signs often appear before a brute force attack turns into a real problem.

How to disable XML-RPC

There’s no single best way to disable XML-RPC in WordPress. The right method depends on whether you want to use a plugin, have access to your server, or need to keep some services working.

If you’re new to this, start with a plugin that lets you turn XML-RPC on or off easily. Advanced users can block xmlrpc.php at the server level for better protection and less server strain. No matter which method you use, always test afterward, since some setups may still allow requests even if they seem blocked.

Method 1: Disable XML-RPC via plugin filter

To manually disable XML-RPC on your WordPress website, you can create a custom filter by writing your own site-specific plugin (or adding it to an existing one). In the plugin, include the following line of code:

add_filter( 'xmlrpc_enabled', '__return_false' );

While it’s possible to add this code to your theme’s functions.php file instead, it’s a better idea to create a plugin. This is because any modifications made to the functions.php file may be lost when updating or changing your theme.

Method 2: Disabling via .htaccess or Nginx config

Blocking xmlrpc.php at the server level is usually the most secure choice because it stops requests before WordPress runs any code.

Before making any changes, back up your configuration files. Even a small mistake can cause your site to go down.

Apache (recommended for Apache 2.4+):

Add this to your site’s .htaccess file:

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

If you’re on an older Apache 2.2 environment (less common today), this legacy syntax is sometimes used:

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

Nginx

In your server block configuration, add:

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

After that, reload Nginx. Usually, you should run nginx -t to test your configuration first, then use the right reload command for your hosting setup.

If you want to block only pingbacks but keep other XML-RPC features, you’ll usually need a WAF rule or an application-level setting. Nginx can’t block specific XML-RPC methods without more advanced tools.

How to verify XML-RPC is successfully disabled

It’s important to check your work. Mistakes are common, and some sites seem blocked but still accept POST requests.

Begin with an easy check by visiting https://example.com/xmlrpc.php in your browser. If you see a “403 Forbidden” or “404 Not Found” message, it usually means the file is blocked at the server level.

If you see a message like “XML-RPC server accepts POST requests only,” the file is still accessible and WordPress is responding. This doesn’t mean you’re being attacked, but it shows you haven’t fully blocked access yet.

For a more direct test, run a quick header check:

curl -I https://example.com/xmlrpc.php

You want to see a 403 or 404 error. Finally, check your logs. After disabling XML-RPC, you shouldn’t see successful POST requests to xmlrpc.php from random IP addresses, especially repeated bursts that look automated.

Prioritizing your website’s security

For most modern WordPress sites, XML-RPC is more of a risk than a benefit. Turning it off, especially the pingback feature, is a practical step that can lower brute force attacks and reduce your site’s exposure.

Still, security is not just about flipping a switch. Keep WordPress, themes, and plugins up to date, use strong authentication, and check your logs regularly for early warning signs. If your site is critical for your business, adding extra protection at the edge can mean the difference between quietly blocking attacks and having to deal with a major incident.

If you want extra protection, think about adding a dedicated WAF and monitoring to filter out bad traffic before it reaches your site. Tools like the Sucuri Firewall are made to cut down on attack attempts and help your site stay strong when attackers try to break in.