WordPress XML-RPC: The Attack Vector UK Business Sites Should Close

What XML-RPC is and why it still exists

XML-RPC (xmlrpc.php) was WordPress's original remote interface — a protocol that allowed external applications to publish posts, upload media, and manage comments without using the admin dashboard. It was how the WordPress mobile app communicated with self-hosted sites before the REST API existed. Desktop blogging clients like Windows Live Writer used it. Third-party services used it for automated publishing.

WordPress replaced XML-RPC with the REST API in version 4.7 (2016). The mobile app moved to the REST API in 2019. Most legitimate integrations that used XML-RPC have since been updated. WordPress has kept XML-RPC active for backwards compatibility — but it remains the site operator's responsibility to disable it if it is not needed, which for most UK business sites, it is not.

How attackers exploit XML-RPC against UK WordPress sites

Brute force login amplification

The most exploited XML-RPC vulnerability uses the system.multicall method, which allows multiple authentication requests to be bundled into a single HTTP POST. An attacker can test hundreds of username and password combinations in one request — making XML-RPC an efficient credential testing tool that operates at a scale no rate-limited login page allows.

The critical problem for UK sites: most WordPress security plugins, including Wordfence, apply login attempt limits at wp-login.php. Unless XML-RPC protection is explicitly enabled, the XML-RPC endpoint is unguarded. An attacker can test thousands of credential combinations through XML-RPC while the standard login page is fully protected. This is a common attack pattern on UK business sites and consistently bypasses standard login security setups.

DDoS amplification using your site as a weapon

XML-RPC includes a pingback feature that causes WordPress to send HTTP requests to third-party URLs. Attackers who have compromised a network of WordPress sites — or who can trigger pingbacks without authentication — can direct thousands of WordPress installations to simultaneously send requests to a target URL. The traffic appears to originate from legitimate WordPress sites on ordinary hosting, making it difficult to filter.

Your site becomes a participant in a distributed attack against another organisation. Beyond the ethical dimension, this generates excessive outbound traffic that hosting providers may penalise, and your domain's IP reputation can be affected by association with the attack traffic.

Server-side request forgery

The pingback mechanism can be used to instruct your WordPress server to fetch internal URLs — addresses that are not publicly accessible but that your hosting server can reach. On certain hosting configurations, this can expose internal services, admin interfaces running on non-standard ports, or other resources on the hosting network. This is a server-side request forgery (SSRF) vector that requires XML-RPC to be exposed.

How to confirm XML-RPC is exposed on your site

Visit https://yoursite.co.uk/xmlrpc.php directly in a browser. If the response is a message saying "XML-RPC server accepts POST requests only," the endpoint is live and accessible. If you receive a 403 Forbidden or 404 Not Found, it has been blocked or disabled.

To check whether it is being actively targeted, access your server's access logs (available in cPanel under Logs, or from your hosting provider) and search for POST /xmlrpc.php. Any volume above a few entries per week warrants immediate action.

How to disable XML-RPC safely

Option 1: Block at server level via .htaccess (recommended for Apache hosting)

Add the following to your .htaccess file in your WordPress root directory:

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

This blocks access to the file at the web server level before PHP executes. It is the most complete mitigation — no request reaches the WordPress application at all.

Option 2: Block via Nginx configuration

If your hosting uses Nginx (common on cloud and VPS hosting), add to your server block:

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

Option 3: Disable via security plugin

If you do not have direct server configuration access, security plugins can disable XML-RPC at the application level. In Wordfence: Tools → All Options → Brute Force Protection → Disable WordPress XML-RPC authentication. The dedicated Disable XML-RPC plugin provides a simple toggle. Note that plugin-level blocking is less robust than server-level blocking — the request still reaches PHP — but it is significantly better than leaving XML-RPC fully open.

Option 4: Disable via functions.php

Adding add_filter('xmlrpc_enabled', '__return_false'); to your child theme's functions.php disables XML-RPC authentication but does not block all pingback functionality and still allows the file to receive HTTP requests. This is the weakest mitigation and should only be used where server-level access is not available and no security plugin is installed.

When XML-RPC might still be legitimately needed

Before disabling, verify nothing in your setup still relies on XML-RPC:

• Jetpack — some older Jetpack features used XML-RPC. Current Jetpack versions use the REST API, but if you are running an older version, check before disabling.
• Third-party publishing tools — desktop blogging clients or content scheduling tools built before 2016 may still use XML-RPC. These are increasingly rare in UK business environments but worth checking if you use any third-party publishing workflow.
• Custom integrations — bespoke integrations built specifically against the XML-RPC endpoint. If in doubt, disable and monitor — a broken integration will be immediately apparent.

In our experience across UK client sites, fewer than 5% of business WordPress installations have any legitimate dependency on XML-RPC. The remainder can disable it immediately.

XML-RPC in the context of UK GDPR obligations

If an attacker successfully compromises admin credentials via an XML-RPC brute force and then accesses customer data — order history, contact details, payment information — the resulting data breach carries UK GDPR notification obligations. The ICO must be notified within 72 hours if the breach is likely to result in a risk to individuals' rights and freedoms. Admin access to a WooCommerce or membership site typically meets that threshold.

Disabling XML-RPC eliminates one specific credential attack vector. It does not eliminate all vectors — strong passwords and two-factor authentication remain essential — but it removes an exposure that is straightforwardly closed with no downside for almost all UK business sites.