How to disable XML-RPC in WordPress?

To disable XML-RPC in WordPress, you can install a small plugin such as Disable XML-RPC-API, add the xmlrpc_enabled filter to a custom plugin or your child theme, or block access to xmlrpc.php completely at the server level with an .htaccess rule on Apache or a location block on Nginx. Blocking it at the server is the most thorough option because requests never reach WordPress at all.

XML-RPC is an old remote publishing interface that most modern sites no longer need, yet it stays enabled by default and is a favourite target for brute-force and pingback abuse. This article explains what XML-RPC does, how to tell whether your site still relies on it, and the different ways to switch it off safely.

What Is XML-RPC in WordPress?

XML-RPC is a protocol that lets other applications talk to your WordPress site by sending XML-formatted requests over HTTP. In WordPress, all of these requests go to a single file in the root of your installation: xmlrpc.php.

Before the REST API existed, XML-RPC was the main way external tools could interact with WordPress. It allowed you to:

• Publish and edit posts from desktop blogging apps.
• Manage your site from early versions of the WordPress mobile apps.
• Send and receive pingbacks and trackbacks between blogs.
• Connect services like Jetpack to your site.

Since WordPress 4.7, the REST API has provided a more modern, flexible way to do all of this. Application passwords, added in WordPress 5.6, give external apps a safe way to authenticate with the REST API. As a result, XML-RPC is now mostly a legacy feature kept for backward compatibility.

Why Is XML-RPC a Security Risk?

XML-RPC itself isn't broken, but a few of its features make it attractive to attackers.

Amplified Brute-Force Attacks

Many XML-RPC methods require a username and password. On top of that, the system.multicall method lets a client bundle many method calls into a single HTTP request. Attackers combine the two to try hundreds of passwords in one request. Some basic security measures only count HTTP requests to the login page, so this kind of attack can slip past them.

Pingback Abuse

The pingback.ping method lets one site notify another that it has linked to it. When your site receives a pingback, it fetches the source URL to verify the link. Attackers can abuse this by sending large numbers of forged pingback requests to many WordPress sites at once, turning them into participants in a distributed denial-of-service attack against a third party. Pingbacks can also be used to probe internal network addresses from your server.

Resource Consumption

Even failed XML-RPC requests load WordPress and PHP. A bot hammering xmlrpc.php can use up CPU and memory, slowing down your site for real visitors.

For these reasons, if you don't actively use XML-RPC, turning it off is a quick win that shrinks your site's attack surface.

Do You Still Need XML-RPC?

Before disabling it, check whether anything on your site depends on it. Common cases include:

• Jetpack: Jetpack has historically relied on XML-RPC for communication between your site and WordPress.com. If you use Jetpack, test carefully after any change, or keep XML-RPC reachable for Jetpack.
• Older mobile or desktop apps: Some older publishing apps and integrations only support XML-RPC. Newer versions of the official WordPress app can connect to self-hosted sites using application passwords and the REST API.
• Third-party services: Some legacy integrations, remote management tools, or posting services may still use XML-RPC. Check their documentation.
• Pingbacks and trackbacks: If you want to receive pingbacks, you need the pingback methods available.

If none of these apply, which is the case for most modern sites, you can safely disable it.

How to Check If XML-RPC Is Enabled

The simplest check is to visit https://yourdomain.com/xmlrpc.php in a browser. If XML-RPC is reachable, you'll see the message "XML-RPC server accepts POST requests only." If you see a 403 Forbidden or 404 error, it's already blocked.

For a more detailed check, send a harmless system.listMethods request with curl, which asks the server which methods it supports:

curl -s -X POST \
  -H "Content-Type: text/xml" \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' \
  https://yourdomain.com/xmlrpc.php

If you get back a long XML list of methods such as wp.getPosts and pingback.ping, XML-RPC is enabled. Run the same command again after making changes to confirm they worked.

Method 1: Disable XML-RPC With a Plugin

If you'd rather not touch code, a plugin is the easiest route.

1. Install the plugin: Go to Plugins > Add New Plugin and search for "Disable XML-RPC-API". Click Install Now, then Activate.

2. Review the settings: The plugin adds a settings page where you can disable XML-RPC entirely, allow specific IP addresses (useful for Jetpack or trusted services), and remove related headers.

3. Test the result: Visit xmlrpc.php or rerun the curl command to confirm it's blocked.

Another long-standing option is the "Disable XML-RPC" plugin, which simply activates the xmlrpc_enabled filter with no settings at all.

Many security suites include this feature too, so you may not need an extra plugin:

• Solid Security: Has an XML-RPC setting where you can disable it completely or only block multiple authentication attempts per request.
• All-In-One Security (AIOS): Includes an option to completely block access to XML-RPC and another to disable pingback functionality.
• Wordfence: Its login security settings let you disable XML-RPC authentication, and its brute force protection covers XML-RPC login attempts.

Method 2: Disable XML-RPC With Code

If you prefer to keep your plugin count low, a few lines of PHP do the job. Add this code to a small custom plugin or a site-specific functionality plugin, rather than your parent theme, so it survives theme updates and theme switches. Your child theme's functions.php also works.

Disable Authenticated XML-RPC Methods

WordPress provides a filter specifically for this:

add_filter( 'xmlrpc_enabled', '__return_false' );

It's important to understand what this filter does. It disables XML-RPC methods that require authentication, such as publishing or editing posts, which stops brute-force password guessing through XML-RPC. However, it does not disable methods that don't require a login, such as pingback.ping and system.multicall.

Remove Pingback Methods and Headers

To close the pingback loophole as well, remove those methods and the related header and link WordPress adds to your pages:

<?php
/**
 * Plugin Name: Sajjad Disable XML-RPC
 * Description: Disables XML-RPC authentication, pingbacks, and related headers.
 * Version:     1.0.0
 */

defined( 'ABSPATH' ) || exit;

// Disable all XML-RPC methods that require authentication.
add_filter( 'xmlrpc_enabled', '__return_false' );

/**
 * Remove unauthenticated methods that can be abused.
 */
function sajjad_remove_xmlrpc_methods( $methods ) {
unset(
$methods['pingback.ping'],
$methods['pingback.extensions.getPingbacks'],
$methods['system.multicall']
);

return $methods;
}
add_filter( 'xmlrpc_methods', 'sajjad_remove_xmlrpc_methods' );

/**
 * Remove the X-Pingback HTTP header.
 */
function sajjad_remove_x_pingback_header( $headers ) {
unset( $headers['X-Pingback'] );

return $headers;
}
add_filter( 'wp_headers', 'sajjad_remove_x_pingback_header' );

// Remove the Really Simple Discovery (RSD) link from the page head.
remove_action( 'wp_head', 'rsd_link' );

Save this as wp-content/plugins/sajjad-disable-xmlrpc/sajjad-disable-xmlrpc.php and activate it from Plugins > Installed Plugins.

Block XML-RPC Requests Completely in PHP

If you want to reject every XML-RPC request, you can stop them as soon as WordPress knows it's handling one. The XMLRPC_REQUEST constant is defined by xmlrpc.php before WordPress loads your plugins:

/**
 * Reject all XML-RPC requests with a 403 response.
 */
function sajjad_block_xmlrpc_requests() {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit( 'XML-RPC is disabled on this site.' );
}
}
add_action( 'plugins_loaded', 'sajjad_block_xmlrpc_requests', 1 );

This works, but PHP and WordPress still load for every request. The server-level methods below are more efficient.

Method 3: Block xmlrpc.php With .htaccess (Apache)

If your site runs on Apache or LiteSpeed, you can deny access to xmlrpc.php in the .htaccess file in your WordPress root. Always download a backup copy of .htaccess before editing it, since a syntax error can take your site offline with a 500 error.

Add the following outside the # BEGIN WordPress and # END WordPress markers, because WordPress may rewrite anything between them:

# Block access to xmlrpc.php
<Files xmlrpc.php>
    Require all denied
</Files>

This uses Apache 2.4's Require syntax. Requests to xmlrpc.php now receive a 403 Forbidden response before PHP runs.

Allow Specific IP Addresses

If a trusted service needs XML-RPC, you can allow its IP addresses while blocking everyone else:

<Files xmlrpc.php>
    <RequireAny>
        Require ip 203.0.113.10
        Require ip 198.51.100.0/24
    </RequireAny>
</Files>

Replace the example addresses with the real ones. For Jetpack, check Jetpack's own documentation for its current IP ranges, since they can change over time.

Method 4: Block xmlrpc.php in Nginx

Nginx doesn't read .htaccess files, so you need to edit your server configuration. Add this inside your site's server block, usually in a file under /etc/nginx/sites-available/:

# Block access to xmlrpc.php
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

The exact-match location = takes priority over your general PHP location, so the request is denied before it reaches PHP-FPM. To allow specific IPs, add allow lines above deny all;:

location = /xmlrpc.php {
    allow 203.0.113.10;
    deny all;

    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

In the second version, allowed IPs still need PHP handling, so adjust the fastcgi_pass path to match your PHP version. Test and reload Nginx afterwards:

sudo nginx -t && sudo systemctl reload nginx

If you're on managed hosting with Nginx, ask your host to add the rule, or check whether they already provide an XML-RPC toggle in their dashboard.

Method 5: Block XML-RPC at the CDN or Firewall

If your site uses Cloudflare or a similar CDN or web application firewall, you can create a rule that blocks requests to the /xmlrpc.php path at the edge. This stops malicious traffic before it reaches your server at all, which is especially useful if you are seeing heavy XML-RPC attack traffic. Many managed WordPress hosts also block or rate limit XML-RPC at their firewall by default.

Which Method Should You Choose?

Each option has trade-offs:

• Plugin: Easiest for beginners and simple to undo, but requests still load WordPress.
• PHP filter: Lightweight and portable across hosts, but xmlrpc_enabled alone leaves pingbacks active unless you also remove those methods.
• .htaccess or Nginx rule: Most efficient and thorough, since requests never reach PHP. Requires access to server config files.
• CDN or WAF rule: Stops traffic at the edge, ideal during active attacks.

For most sites, a server-level block combined with nothing else is enough. If you can't edit server files, use the PHP snippet that removes both authenticated and pingback methods.

Disabling Pingbacks in the Dashboard

Separately from XML-RPC, you can stop WordPress from sending and accepting pingbacks on new posts. Go to Settings > Discussion and uncheck:

• Attempt to notify any blogs linked to from the post
• Allow link notifications from other blogs (pingbacks and trackbacks) on new posts

This only affects new posts. Existing posts keep their individual setting, which you can change in bulk from Posts > All Posts using Bulk actions > Edit. Note that this setting doesn't block the pingback.ping method from being called, so it complements rather than replaces the steps above.

Troubleshooting After Disabling XML-RPC

If something stops working after you disable XML-RPC, work through these checks:

Jetpack shows a connection error: Jetpack may need access to XML-RPC. Re-enable it, allow Jetpack's IP ranges, or use your security plugin's option to block only multiple authentication attempts rather than all XML-RPC.

A mobile or desktop app can't connect: Update the app, and connect using an application password from Users > Profile > Application Passwords, which uses the REST API instead.

A remote management tool stops syncing: Check the tool's documentation. Most modern management services use their own plugin and the REST API, but some older ones may still use XML-RPC.

Your site shows a 500 error after editing .htaccess: Restore your backup of .htaccess via SFTP or your host's file manager, then check for typos before trying again.

---

FAQ: Disabling XML-RPC in WordPress

---

Conclusion

XML-RPC was a useful bridge to the outside world in WordPress's early years, but the REST API and application passwords have long since replaced it for almost every task. Leaving it enabled when you don't need it gives attackers an extra login path and a way to abuse your site for pingback floods.

Check whether anything on your site still depends on XML-RPC, then disable it using the method that fits your setup: a plugin for simplicity, a PHP snippet for portability, or an .htaccess or Nginx rule for the most efficient block. Test with the curl command afterwards, and you'll have closed one of the most commonly probed doors on a WordPress site.