How to Disable XML-RPC in WordPress Safely

The xmlrpc.php endpoint lets remote applications communicate with a WordPress website. If you don’t use Jetpack, a mobile publishing app, remote content tools, or another service that relies on this interface, disabling it can cut down on unnecessary authentication attempts and pingback abuse.

Quick answer

The most complete fix is to block xmlrpc.php at the web server level. On Apache, you can deny access through .htaccess. Nginx users can add an exact-match location rule instead.

A WordPress security plugin is usually easier for beginners. The tradeoff is that PHP and WordPress may already be processing the request by the time the plugin blocks it.

Apache 2.4

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

Nginx

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

Back up the configuration file before touching it. Once the change is in place, test the endpoint, then make sure any connected publishing or management services still work.

What XML-RPC does in WordPress

XML-RPC is a remote procedure call interface that sends XML-formatted requests over HTTP. WordPress makes it available here:

https://example.com/xmlrpc.php

Historically, remote publishing clients and mobile applications have used it, along with pingbacks, trackbacks, and services such as Jetpack. The endpoint isn’t malware, and it isn’t a vulnerability on its own. It does, however, offer another route for password-guessing traffic, resource-heavy requests, and pingback abuse.

Check what depends on XML-RPC

Before blocking anything, check whether the site relies on one of these:

• Jetpack or services connected through Jetpack
• The WordPress mobile app or an older desktop publishing client
• Remote publishing and website management platforms
• Custom integrations that send XML-RPC requests
• Pingbacks or trackbacks you intentionally use

If you’re not sure, read the relevant plugin documentation and look through the server access logs for requests to /xmlrpc.php. A log entry doesn’t prove that a legitimate integration needs the endpoint. Repeated requests from unfamiliar addresses are often automated probes.

Method 1 — Use a WordPress plugin

This is generally the easiest route if you can’t edit the server configuration.

1. Sign in to the WordPress administration dashboard.
2. Open Plugins > Add New Plugin.
3. Install a reputable, actively maintained security plugin with XML-RPC controls.
4. Go to the plugin’s security or hardening settings.
5. Turn on the option that disables or blocks XML-RPC.
6. Clear the page, server, and CDN caches before testing.

Read the setting description closely. Some plugins disable only XML-RPC authentication, while others shut off the whole endpoint. If no legitimate service needs XML-RPC, blocking the endpoint completely is the better option.

Method 2 — Block xmlrpc.php on Apache

On an Apache-hosted site, open the .htaccess file in the WordPress installation directory. Add the following rule outside the automatically generated WordPress rewrite markers:

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

Save the file and test the website right away. The Require all denied directive is meant for Apache 2.4. If the edit causes a server error, restore your backup and ask the hosting provider which Apache syntax the server supports.

Because Apache rejects the request before it reaches WordPress, this method also reduces unnecessary PHP processing.

Method 3 — Block xmlrpc.php on Nginx

For Nginx, place an exact-match location block inside the relevant server block:

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

Test the configuration before reloading Nginx. Don’t skip this part.

sudo nginx -t

If the test passes, reload the service:

sudo systemctl reload nginx

Managed hosting accounts don’t always allow access to the Nginx configuration. In that case, contact the host or use its security controls rather than trying to change system files you can’t reach.

Method 4 — Disable authenticated methods with PHP

If server-level changes aren’t available, add this filter through a small site-specific plugin:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Don’t edit the active theme’s functions.php file unless you’re prepared to lose the change when the theme is replaced. A site-specific plugin or must-use plugin is more dependable.

There’s a catch here. This filter doesn’t block xmlrpc.php itself. WordPress documentation says it disables XML-RPC methods that require authentication, but other XML-RPC behavior can remain available, including pingbacks. If the endpoint needs to be inaccessible, use a server rule.

Disable pingbacks without blocking XML-RPC

Sometimes an integration still needs XML-RPC, but pingbacks aren’t wanted. In that situation, remove the pingback method and leave the rest of the interface running:

<?php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

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

This narrower approach preserves remote publishing functionality while reducing exposure to pingback abuse.

Test whether XML-RPC is blocked

Run this command, replacing the example domain with your own:

curl -i https://example.com/xmlrpc.php

A server-level block will normally return 403 Forbidden. Depending on the hosting setup, you may get 404 Not Found instead. If the response says XML-RPC server accepts POST requests only, the endpoint is still reachable.

You can also send an XML-RPC request directly:

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

If Apache, Nginx, a firewall, or a CDN is blocking the endpoint, expect a denial response. Then check the WordPress dashboard, scheduled services, mobile app, and any remote management platform connected to the site. A block that works technically can still break a real workflow.

Mistakes to avoid

• Assuming the PHP filter blocks the file. The endpoint may remain reachable even after authenticated methods are disabled.
• Breaking Jetpack without realizing it. Confirm the plugin’s requirements before blocking XML-RPC completely.
• Editing generated rewrite rules. WordPress or a deployment tool may overwrite anything placed inside generated markers.
• Reloading Nginx without checking the configuration. Always run nginx -t first.
• Treating an XML-RPC block as the whole security plan. Keep WordPress, themes, and plugins updated, and use strong authentication controls.

Which method fits

Server-level blocking is generally the cleanest choice because unwanted requests are rejected before WordPress and its plugins load. But if a verified publishing or management workflow depends on XML-RPC, leave the interface available and deal with the abusive traffic instead.