WordPress XML-RPC: what it is and whether to disable it

For most sites, block XML-RPC's system.multicall abuse without killing the whole file: use a security plugin's XML-RPC toggle, or block it at the server level if you don't use Jetpack or the WordPress mobile app. If you use Jetpack, leave XML-RPC on. Jetpack depends on it for the connection to WordPress.com, and disabling it breaks Jetpack's sync, stats, and backup features.

XML-RPC is a remote procedure protocol WordPress ships with by default, at /xmlrpc.php in your site root. It predates the modern REST API and lets external apps talk to WordPress: publish a post, upload media, manage comments, check a user's credentials. That's useful for a handful of real features, and it's also the single most abused entry point on a default WordPress install.

What actually uses it

Legitimate XML-RPC traffic is narrower than most site owners expect:

• Jetpack uses it for the connection between your site and WordPress.com, including remote publishing, stats, and backups.
• The WordPress mobile app (iOS/Android) uses it to let you post and manage your site from your phone.
• Some third-party publishing tools (old desktop blog clients, certain automation and cross-posting services) still call it instead of the REST API.

If none of that applies to you, you're carrying attack surface for a feature you don't use.

Why it gets targeted

The specific method that causes trouble is system.multicall. It lets a single XML-RPC request bundle hundreds of method calls together, including hundreds of login attempts. That turns XML-RPC into a brute-force multiplier: instead of one password guess per HTTP request (which rate limiting and login-attempt plugins can throttle), an attacker can test hundreds of username and password combinations in one request. Automated scanners probe /xmlrpc.php on nearly every public WordPress site, constantly, whether or not anything is misconfigured. It's background noise on server logs, but it's real load, and a weak password behind it is a real risk.

XML-RPC can also be abused for pingback-based amplification, where your site is used to send pingback requests to a third-party target, making your server an unwitting participant in someone else's attack.

How to check if you need it

Before disabling anything, confirm what you're actually running:

1. Check whether Jetpack is installed and connected. Open wp-admin → Plugins. If Jetpack is active, keep XML-RPC enabled.
2. Check whether you or your team use the WordPress mobile app to manage the site. If so, keep it enabled.
3. If neither applies, you're clear to disable it, or at minimum to lock down system.multicall.

How to disable or restrict it

You have a few options, from least to most aggressive:

• Security plugin toggle (recommended for most sites). If you're running Wordfence, it has a dedicated option to disable XML-RPC entirely, or to block only system.multicall while leaving single calls available. See WordPress plugins we recommend for the security plugins we suggest. This is the safest route because it's reversible from wp-admin if something breaks.
• Block at the web server level. If you're comfortable editing server config, you can deny requests to xmlrpc.php directly. On Flashcloud's LiteSpeed stack, an equivalent to the common Apache/Nginx snippet is a rewrite rule denying the file, added via an .htaccess block in your document root. This stops the request before WordPress even loads, which is lighter on server resources than a plugin-level block.
• Disable via functions.php filter. Adding add_filter('xmlrpc_enabled', '__return_false'); to your theme's functions.php (or a site-specific plugin) turns off XML-RPC functionality in WordPress itself. Note this disables the feature but doesn't stop the file from being requested, so you'll still see hits in logs, they won't do anything.

Whichever method you use, test after: if Jetpack or the mobile app stop syncing, you blocked more than intended.

What this doesn't fix

Disabling XML-RPC removes one attack surface, not your whole security posture. It won't stop brute-force attempts against wp-login.php itself, and it's not a substitute for strong passwords, two-factor authentication, or a firewall. It's one item on a broader hardening checklist, covered along with plugin and login security in WordPress plugins we recommend.

When to contact support

If you disable XML-RPC and Jetpack, a publishing integration, or the mobile app breaks unexpectedly, or if you're seeing unusual load and aren't sure whether xmlrpc.php is the cause, open a ticket from the portal under Support → New ticket. A real person can check your server logs and confirm whether XML-RPC traffic is behind it before you change anything else.