How to Disable XML-RPC (xmlrpc.php) in WordPress: Risks and Jetpack

This article is a localized edition of the Japanese original. Read the Japanese original

XML-RPC is an older mechanism that lets external apps and services publish and retrieve content in WordPress. Its endpoint is xmlrpc.php in the site root. Since WordPress 3.5 it is enabled by default, and there is no admin setting to turn it off.

Today the REST API and application passwords can do the same job, so if no service on your site uses XML-RPC, disabling it removes one point of attack.

Problems caused by XML-RPC

• Password brute forcing. xmlrpc.php accepts a username and password and logs in, so attackers can use it to bypass protections that only cover the login screen (wp-login.php). One technique packs multiple login attempts into a single request with system.multicall, but since WordPress 4.4, once one attempt fails, all remaining attempts in the same request fail too.
• Pingback abuse. pingback.ping makes your site fetch a given URL. Attackers can send large numbers of these requests to use your site as a relay for attacks on third-party sites.
• Server load. Even for attack requests, all of WordPress is loaded each time, which adds PHP processing.

Before disabling it, check whether anything uses XML-RPC

If you use none of these, blocking access to xmlrpc.php itself (Method 1 or Method 2) is the simplest option and also reduces server load.

Method 1: Block it with Apache (.htaccess)

Add this to the .htaccess file in the directory where WordPress is installed. Place it outside (before) the # BEGIN WordPress to # END WordPress block that WordPress writes.

# Deny all access to xmlrpc.php (Apache 2.4)
<Files "xmlrpc.php">
    Require all denied
</Files>

Order Deny,Allow and Deny from all are Apache 2.2 syntax. On Apache 2.4 they cause a 500 error unless mod_access_compat is loaded, so use Require.

Requests now return 403 Forbidden.

If you use Jetpack, allow only Jetpack’s IP addresses

Jetpack's support page describes allowing xmlrpc.php only from Jetpack's server IP ranges and blocking everything else. Using the ranges as of November 2026, it looks like this:

<Files "xmlrpc.php">
    Require ip 122.248.245.244/32 54.217.201.243/32 54.232.116.4/32
    Require ip 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20
    Require ip 195.234.108.0/22 192.0.64.0/18
</Files>

These ranges can change. Jetpack publishes the current list at https://jetpack.com/ips-v4.txt, so compare against it regularly. Also, if your site sits behind a proxy such as Cloudflare, Apache sees the proxy's IP address as the client, so this method will not work as-is.

Method 2: Block it with Nginx

Add this to your site's server block.

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

An exact-match location = takes precedence over regex locations such as location ~ \.php$, so the order does not matter. Test the configuration and reload:

sudo nginx -t
sudo systemctl reload nginx

If you use Jetpack, add Jetpack's ranges one per line before deny all;, for example allow 192.0.64.0/18;.

Method 3: Block it with PHP (when you cannot change the server configuration)

If you cannot use .htaccess, for example on shared hosting, block it in PHP. So that it keeps working when you switch themes, use a must-use plugin in wp-content/mu-plugins/ instead of functions.php. Create the folder if it does not exist and save the following as wp-content/mu-plugins/disable-xmlrpc.php.

<?php
/*
 * Plugin Name: Disable XML-RPC
 */

// For requests to xmlrpc.php, return 403 and stop
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
    status_header( 403 );
    header( 'Content-Type: text/plain; charset=utf-8' );
    exit( 'XML-RPC is disabled.' );
}

// Remove X-Pingback from the response headers of regular pages
add_filter( 'wp_headers', function ( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

xmlrpc.php defines the XMLRPC_REQUEST constant before loading WordPress, so a must-use plugin can check it. WordPress itself is still loaded, though, so this reduces load less than Method 1 or Method 2.

About the xmlrpc_enabled filter

The following commonly shared code does not disable XML-RPC entirely.

add_filter( 'xmlrpc_enabled', '__return_false' );

As the WordPress source code documents, this filter only disables methods that require authentication (creating and retrieving posts, for example). Methods that do not require login, such as pingbacks, keep working. It stops password brute forcing, but pingback abuse and the load remain.

Method 4: Disable only pingbacks (to keep using Jetpack or the app)

Keep XML-RPC itself and remove only the pingback methods. Put this in a must-use plugin as above.

<?php
/*
 * Plugin Name: Disable Pingback Methods
 */

add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

add_filter( 'wp_headers', function ( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

X-Pingback is a response header WordPress sends when it displays a post that accepts pingbacks. Some themes also output a rel="pingback" link in the HTML head; if yours does, check the theme's output as well.

Check that it is blocked

Replace example.com with your domain and run:

# Print only the status code
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.php

To check whether Method 4 removed pingbacks, list the available methods:

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

If nothing is printed, the pingback methods are gone.

Things to watch for

• If Jetpack shows a connection error after blocking, allow Jetpack's IP addresses or switch to Method 4.
• Some hosting companies restrict access to xmlrpc.php from the start. In that case, check the setting in your host's control panel.
• Disabling XML-RPC does not protect wp-login.php from brute forcing; that needs separate measures.

Summary

• If nothing uses XML-RPC, the simplest option is to block access to xmlrpc.php with Apache's Require all denied or Nginx's deny all.
• The xmlrpc_enabled filter only disables methods that require authentication; it does not stop pingbacks.
• If you use Jetpack, allow only Jetpack's IP addresses or remove just the pingback methods.

To move external publishing to the REST API, see application passwords; to protect the login screen, see protecting against brute force attacks.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)