JPKCom DB
View on GitHub (opens in a new tab)

JPKCom Disable XML-RPC — Guide & Tips

Disable WordPress XML-RPC site-wide with JPKCom Disable XML-RPC — installation, requirements and security tips.

JPKCom Disable XML-RPC disables the WordPress XML-RPC interface globally. Useful when you don't need this legacy remote interface and want to close its attack surface.

Guide

Requirements

  • WordPress 6.9 or newer (tested up to WordPress 7.1)
  • PHP 8.3 or newer

Installation

  1. In your admin panel, go to Plugins → Add New and click Upload Plugin.
  2. Choose the plugin's ZIP file and click Install Now.
  3. Click Activate.

How it works

There is no settings page — once active, the plugin disables XML-RPC for the entire installation:

  • Requests to xmlrpc.php are answered with HTTP 403 and an XML-RPC fault, so clients get a parseable refusal rather than a silent empty response.
  • The xmlrpc_enabled flag is off, the method list is empty, and instantiation of the XML-RPC server class is blocked as a last resort.
  • The site stops advertising the endpoint: neither the X-Pingback HTTP header nor a <link rel="pingback"> tag is emitted any more.

Please note: pingbacks arrive over XML-RPC and are therefore no longer accepted. Because WordPress gates both mechanisms on the same pings_open() check, trackbacks are refused as well.

Tips & Tricks

  • Reduce attack surface: XML-RPC is a common entry point for brute-force and pingback attacks. If you don't use services that strictly require XML-RPC, you can safely disable the interface.
  • Check what relies on XML-RPC first: Some external services or older app integrations still talk to WordPress via XML-RPC. Make sure you don't rely on such an integration before disabling it globally.
  • Trackbacks included: If you deliberately want to keep trackbacks, this plugin is the wrong choice — since version 1.0.9 they go away together with the pingbacks.
  • 403 instead of 200 since 1.0.9: Up to version 1.0.8 xmlrpc.php answered with a bare HTTP 200 and an empty body instead of the documented 403. If you verify the shutdown via monitoring or a security scan, your test should expect a different status code from 1.0.9 on.
  • Reproducible updates: Since version 1.0.2 the plugin uses secure self-hosted updates via GitHub with SHA256 checksums, runs with declare(strict_types=1), types the callbacks and sanitizes $_SERVER access. Since 1.0.10 it also carries the Update URI header: the wordpress.org update API then no longer returns updates for this plugin, so a plugin published there under the same slug cannot pose as an update. Since 1.0.11 Dashboard → Updates shows the JPKCom logo as the plugin icon. Since 1.0.12 (updater 1.5.0) the plugin is offered updates even while deactivated — provided another JPKCom plugin with updater 1.5.0 or later is active, on multisite network-wide or on the main site: one loaded updater serves every installed JPKCom plugin with the update row, icon and "View details", and the SHA256 check applies just the same. The stored update list no longer contains JPKCom download URLs; they are added back only while a JPKCom updater is loaded, so no unverified package can be installed without one. The check also verifies packages supplied by another plugin and recognizes every GitHub address of a release file. A Git or other version-control checkout and a renamed folder (such as jpkcom-disable-xmlrpc-main) are never updated through WordPress — the update would delete the checkout or the folder. They are still told about new releases, a renamed folder only while the plugin is active. Update information is fetched only for accounts that can update plugins, in the update cron and in WP-CLI, never for anonymous visitors.
  • All in one plugin: JPKCom Harden & Trim has included a "Disable XML-RPC" switch since version 1.1.0 that behaves like this plugin in version 1.0.10 and is on out of the box there, plus 40 further settings for security, privacy and performance. Running both does no harm.

Further reading