You have installed a login protection plugin on your WordPress site. You have limited failed login attempts. You may have even changed your login URL. Your site is secure from brute force attacks, right?

Not necessarily. There is a largely forgotten feature of WordPress called XML-RPC, and it accepts login credentials too — without any of the protections you have applied to your main login page.

What Is WordPress XML-RPC?

XML-RPC is a remote procedure call protocol — an API that allows external applications to interact with your WordPress site. It was originally created to support:

  • The WordPress mobile app for publishing and managing posts
  • Jetpack connecting to WordPress.com services
  • Third-party desktop blogging tools like Windows Live Writer
  • Pingback and trackback notifications between blogs

It is accessible at a single URL: https://yourwebsite.co.uk/xmlrpc.php

Unlike your login page, XML-RPC is a full API endpoint. It accepts usernames and passwords in every request. And in most WordPress installations, it is enabled by default.

Why Is XML-RPC a Security Problem?

Brute force attacks that bypass login protection. Most login protection plugins — including Wordfence, Loginizer, and Solid Security — apply their lockout rules to /wp-login.php. But requests to xmlrpc.php often bypass these rules entirely.

An attacker can send thousands of authentication attempts to your XML-RPC endpoint and never trigger the lockout on your login page. Each XML-RPC request can include multiple username and password combinations in a single HTTP request using the system.multicall method — massively amplifying the attack. This issue is closely related to the wider WordPress brute force attack problem.

DDoS amplification using your site. The pingback functionality in XML-RPC allows WordPress to automatically notify other sites when you link to them. Attackers abuse this to use your WordPress site as an unwitting participant in Distributed Denial of Service attacks. By sending a single request to your xmlrpc.php, an attacker can cause your site to flood another site with HTTP requests. Your server load, hosting bandwidth, and IP reputation all suffer as a result.

Server Side Request Forgery (SSRF). XML-RPC can be exploited to make your server fetch arbitrary URLs, potentially accessing internal network resources or metadata services on cloud hosting platforms.

The Real-World Scale of the Problem

In 2015, Sucuri identified a botnet of over 162,000 WordPress sites being used to launch DDoS attacks via XML-RPC pingback abuse — with each site participating unknowingly.

Wordfence has consistently documented large-scale brute force campaigns targeting WordPress XML-RPC endpoints. The widely used WordPress vulnerability scanner wpscan specifically checks for and attempts to exploit XML-RPC endpoints, and its presence in a security scan is treated as a significant finding requiring action.

Do You Actually Need XML-RPC?

For most small business websites, the answer is no. You need XML-RPC only if you:

  • Use the WordPress mobile app to manage your site (many people use the browser-based admin instead)
  • Use Jetpack with it connected to WordPress.com for features like remote backup or social sharing
  • Use a third-party desktop blogging client

If none of those apply, XML-RPC serves no useful purpose and should be disabled. Even if you use Jetpack, modern versions have reduced their reliance on XML-RPC and increasingly use the newer WordPress REST API. Check whether your specific Jetpack features still require it.

How to Disable WordPress XML-RPC

Via a plugin (easiest): The “Disable XML-RPC” plugin from the WordPress plugin repository disables XML-RPC with a single toggle. Alternatively, Wordfence and Solid Security both have XML-RPC settings.

Via .htaccess (Apache):

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

Via Nginx:

location = /xmlrpc.php {
    deny all;
}

What to Do Next

  • Test that https://yourwebsite.co.uk/xmlrpc.php returns a 403 or 404 after making changes. If it returns a 200 with XML content, the block has not worked.
  • Check that anything you depend on still works — mobile app access, Jetpack functionality, and any posting tools should be tested after disabling.
  • Combine this with your other login protections — disabled XML-RPC, a custom login URL, strong passwords, and two-factor authentication together form a robust defence.

For most businesses, disabling XML-RPC will have no noticeable effect on functionality and removes a significant attack surface.

W3IT’s free security check checks whether WordPress XML-RPC is enabled on your site as part of a broader WordPress security assessment. Run it now to see if this backdoor is open.