Disable XML-RPC

The Problem

XML-RPC (xmlrpc.php) was built so desktop blogging clients and the WordPress mobile app could publish posts remotely, but very few sites still use it that way. Meanwhile it's one of the most heavily abused endpoints on WordPress: attackers use its `system.multicall` method to test hundreds of username/password combinations in a single request, bypassing normal rate limits, and use `pingback.ping` to turn your site into part of a DDoS amplification attack against someone else's server. WordPress ships XML-RPC enabled by default with no admin toggle, so unless a plugin (like Jetpack or the WordPress app) explicitly needs it, it's exposed attack surface with no upside for most sites.

The Code

add_filter( 'xmlrpc_enabled', '__return_false' );

// Also remove the X-Pingback header and pingback methods specifically.
add_filter( 'wp_headers', function ( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

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

How It Works

The first line uses the `xmlrpc_enabled` filter, which WordPress core checks before allowing any XML-RPC request to be processed — returning `false` makes every request to xmlrpc.php fail immediately, before any authentication attempt is even parsed. That alone stops the brute-force and amplification abuse. The second block removes the `X-Pingback` HTTP header that WordPress normally sends on every page, which some scanners use to detect that XML-RPC is present at all — hiding the header means fewer automated tools even bother probing further. The third block goes one step further and explicitly deregisters the two pingback-related XML-RPC methods from the method list, which matters if you're using a security plugin or CDN rule that re-enables XML-RPC for other legitimate methods (like Jetpack's own sync calls) — this way pingbacks stay blocked even if the endpoint itself is reopened later.

Where To Add This

A snippet manager plugin (e.g. WPCode, Code Snippets). Because this doesn't touch anything in your theme (it's an application-level security policy, not a presentation change), keeping it in a snippet manager means you can disable it instantly if a specific plugin later needs XML-RPC re-enabled — no need to dig through functions.php under time pressure.

Common Customizations

add_action( 'xmlrpc_call', 'devmubs_block_xmlrpc_with_403' );

function devmubs_block_xmlrpc_with_403() {
    status_header( 403 );
    wp_die(
        'XML-RPC services are disabled on this site.',
        'Forbidden',
        array( 'response' => 403 )
    );
}

<Files xmlrpc.php>
    Require all denied
</Files>

location = /xmlrpc.php {
    deny all;
}

add_filter( 'xmlrpc_enabled', 'devmubs_allow_xmlrpc_from_trusted_ips' );

function devmubs_allow_xmlrpc_from_trusted_ips( $enabled ) {
    $trusted_ips = array( '203.0.113.10', '203.0.113.11' ); // Replace with your own IPs.

    return in_array( $_SERVER['REMOTE_ADDR'], $trusted_ips, true );
}

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

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

add_filter( 'xmlrpc_enabled', 'devmubs_log_and_block_xmlrpc' );

function devmubs_log_and_block_xmlrpc( $enabled ) {
    if ( $enabled ) {
        error_log( sprintf(
            'XML-RPC request blocked from %s at %s',
            $_SERVER['REMOTE_ADDR'],
            current_time( 'mysql' )
        ) );
    }

    return false;
}

Common Errors

Best Practices

• Apply this through a snippet manager rather than editing wp-config.php or server config directly, so you can verify the change on staging and roll it back with one click if an integration later needs XML-RPC.
• Pair this with login rate limiting (see Limit Login Attempts) — disabling XML-RPC closes one brute-force path, not the standard wp-login.php one.
• Re-check this snippet whenever you add a plugin that advertises remote publishing, mobile sync, or "connect your site" functionality — several legitimate integrations still depend on XML-RPC being reachable.
• Prefer the .htaccess/Nginx alternative over the PHP filter when you have server-config access — it rejects the request before WordPress even bootstraps.
• Don't treat this as a complete security posture on its own — it closes one specific, well-documented attack surface, not a substitute for keeping WordPress core, plugins, and themes updated.

FAQ