WordPress XML-RPC Security: How to Prevent Abuse Without Breaking Integrations

Why XML-RPC Can Be a Problem for WordPress

XML-RPC itself is not a vulnerability, but an exposed endpoint adds another channel through which requests can reach your site. If it is available without restrictions, attackers can send large numbers of POST requests and test user credentials.

A separate risk is associated with the <code>system.multicall</code> method, which can combine multiple XML-RPC calls into a single HTTP request. This can make brute-force activity harder to detect with basic protection rules.

Pingback has a different purpose: the feature is designed to notify websites about links, but it can also be used for unwanted requests and reflected attacks. Disabling pingbacks is therefore often a compromise between security and compatibility.

• Do not confuse XML-RPC with the WordPress REST API: blocking one mechanism does not disable the other.
• A large number of requests to <code>/xmlrpc.php</code> does not always indicate a successful attack, but it is a reason to review your logs and security rules.
• XML-RPC protection does not replace WordPress updates, strong passwords, 2FA, or access restrictions for the administrative area.

First Determine Whether You Need XML-RPC

Before blocking XML-RPC, check which services are connected to your site. Completely disabling it may disrupt publishing or site management from a mobile application, Jetpack, or an external system.

If your site does not use any of these scenarios, completely disabling XML-RPC is usually the simplest solution. For a corporate website or online store, also check all automated processes, including imports, publishing, synchronization, and backups.

Do not rely on assumptions alone. After changing the settings, make a test publication, open the mobile client, and check the integrations that have access to WordPress.

• Create a list of plugins and services that interact with the site.
• Review the documentation for each integration: some use XML-RPC, while others use the REST API or a custom webhook.
• If possible, test the changes on a staging copy of the site first.
• After blocking XML-RPC, review error logs and integration notifications.

A Safer Compromise: Disable Pingbacks

If XML-RPC is required for legitimate integrations, you do not necessarily need to block the entire endpoint. You can remove the methods associated with pingbacks while keeping other XML-RPC calls available.

Add the filter to a custom plugin or mu-plugin. It removes the methods relevant to this scenario from the list of available XML-RPC commands:

<?php
/**
 * Disable pingbacks in WordPress.
 */
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);

    return $methods;
});

What This Code Changes

After the filter is enabled, WordPress will not process the two specified pingback methods. Other XML-RPC functions remain available, so compatibility with some services will be higher than with complete endpoint blocking.

This does not stop all brute-force requests to XML-RPC. If the endpoint continues to be targeted heavily, add rate limiting, WAF rules, or separate authentication protection.

Completely Disable XML-RPC

If XML-RPC is not used, you can disable it at the WordPress level with the <code>xmlrpc_enabled</code> filter:

<?php
/**
 * Completely disable XML-RPC.
 */
add_filter('xmlrpc_enabled', '__return_false');

Where to Place the Code

Do not add security code directly to the files of the active theme if it needs to work independently of the design. The code may be lost when the theme is changed or updated.

A practical option is an mu-plugin in the <code>wp-content/mu-plugins/</code> directory. For example, create a file named <code>xmlrpc-hardening.php</code> containing the PHP code and make sure the directory exists. Another option is a small custom plugin that does not depend on the theme.

• Create a backup before making changes.
• Do not add two different rules unless you understand how they interact.
• After activation, test the site using the workflows followed by editors and integrations.

Protection at the Server and WAF Levels

A WordPress filter runs after the request has already reached PHP. To reduce server load, also use your web server, CDN, or WAF. The best approach is to limit the frequency of POST requests to <code>/xmlrpc.php</code> rather than blindly blocking the entire endpoint.

Rate limiting must account for legitimate integrations. An overly strict rule can interrupt synchronization or publishing, especially when several editors or services are working at the same time.

At the server level, you can also allow access only from known IP addresses if the integration uses stable addresses. This approach is often unsuitable for public mobile clients and services.

• Create a separate rule for POST requests to <code>/xmlrpc.php</code>.
• Enable logging for blocked requests and review it periodically.
• Do not use universal User-Agent blocking: User-Agent values are easy to spoof.
• Make sure the rule does not block internal health checks or legitimate integrations.
• Do not edit Nginx or Apache configuration without a backup and a way to quickly roll back the changes.

How to Check the Result Without Breaking the Site

After implementing the protection, check more than the availability of the home page. Make sure that the workflows you need still operate and that the logs do not show authentication errors or repeated mass requests.

It is best to perform the checks in the following order:

• Sign in to the WordPress mobile application if it is in use.
• Check Jetpack and other services connected to the site.
• Make a test publication or update through every important integration.
• Review the web server access log and the WordPress error log.
• Confirm that the site pages, administrative panel, and REST API work as expected.
• If a service stops working, temporarily roll back the rule, identify the mechanism it requires, and configure an exception.

Common Mistakes When Securing XML-RPC

The most common mistake is to block XML-RPC completely without checking the site's dependencies. This quickly removes unwanted requests, but it may silently break publishing from a mobile client or the operation of an external service.

Another mistake is assuming that disabling pingbacks automatically protects against brute-force attacks. It removes one class of functions, but it does not replace rate limiting or account protection.

You should also avoid installing multiple plugins with overlapping functionality without a clear need. Conflicting filters or server rules make troubleshooting more difficult when an integration stops working.

• Do not insert PHP code into the editor for posts or pages.
• Do not keep critical protection only in theme files.
• Do not block <code>/xmlrpc.php</code> blindly if the site uses Jetpack or a mobile client.
• Do not treat the absence of errors on the home page as proof that integrations are working correctly.
• Do not neglect 2FA, unique passwords, and updates simply because XML-RPC has been disabled.