For most WordPress sites, yes, you should disable XML-RPC. It’s a legacy remote-communication protocol that predates the REST API, and while it was essential in its era, almost every modern use case has been replaced by the REST API (/wp-json/). Meanwhile, XML-RPC is one of the most abused WordPress endpoints: it’s exploited for brute force amplification (the system.multicall method bundles hundreds of password guesses into a single request that bypasses login rate limiting), DDoS attacks through pingback abuse, and username enumeration. Most WordPress security plugins don’t even monitor it. The main exception is Jetpack, which still uses XML-RPC for some features. With WP Ghost, disable it at WP Ghost > Change Paths > API Security with a single toggle, and whitelist Jetpack IPs in .htaccess if you need Jetpack compatibility.
What XML-RPC Actually Does
XML-RPC (XML Remote Procedure Call) is a protocol that lets external applications communicate with your WordPress site remotely. It’s WordPress’s original API, predating the REST API, and it handles requests through a single file: xmlrpc.php. By default, the file sits at https://yourdomain.com/xmlrpc.php.
XML-RPC was designed for legitimate uses: publishing posts from mobile apps, managing multiple WordPress sites from a single dashboard, trackbacks and pingbacks, and third-party tools interacting with your site. Functions available through XML-RPC include publishing posts, editing posts, deleting posts, uploading files, getting a list of comments, and editing comments. For the complete function list, see XML-RPC WordPress API on the WordPress Codex.
Today, almost everything XML-RPC does has been replaced by the REST API, which is more secure, more flexible, and better supported. But xmlrpc.php is still active on every default WordPress installation, and unlike the REST API, it has almost no built-in security controls. No rate limiting. No CAPTCHA. No login attempt tracking.
Why Disable XML-RPC
XML-RPC is one of the most abused WordPress endpoints. The KB documents four specific attack patterns:
Brute force amplification via system.multicall. The system.multicall method allows multiple XML-RPC calls to be bundled into a single HTTP request. Attackers exploit this to send hundreds or even thousands of username/password guesses in one request. Publicly available exploit tools can send up to 1,999 authentication attempts per HTTP request. Login rate limiters on wp-login.php don’t see thousands of requests, they see one, so the protection is bypassed entirely.
Most security plugins don’t monitor it. The majority of WordPress security plugins focus their protection on /wp-login.php while leaving xmlrpc.php completely unmonitored. Attackers shifted from targeting the login page to targeting XML-RPC specifically because it flies under the radar.
DDoS amplification through pingbacks. The pingback.ping method can be abused to launch distributed denial-of-service attacks. An attacker sends fake pingback requests to thousands of WordPress sites, all pointing back to a single target. Each site then makes a request to the target. Your site becomes an unwitting participant in a DDoS attack against someone else.
Username enumeration. Attackers can use methods like wp.getUsersBlogs to verify whether a username exists. Combined with author ID enumeration and REST API user discovery, XML-RPC provides another channel for username harvesting.
What You’ll Lose by Disabling XML-RPC
The potential downside is app and plugin compatibility. If you use a third-party application that communicates with your site through XML-RPC, it will stop working after disabling. Example: if you have an app that moderates WordPress comments through XML-RPC, disabling XML-RPC means the app can no longer talk to your site.
That said, the list of modern software that genuinely depends on XML-RPC is short:
| Software | Still Uses XML-RPC? |
|---|---|
| Current WordPress mobile app | No, uses REST API (older versions used XML-RPC, update to latest) |
| WordPress block editor (Gutenberg) | No, uses REST API |
| Admin dashboard, plugin updates, theme customization | No, uses REST API |
| WooCommerce | No, uses REST API |
| Jetpack | Yes, for some features (whitelist WordPress.com IPs in .htaccess) |
| Older remote publishing tools and multisite management dashboards | Some, test before disabling |
How to Disable XML-RPC With WP Ghost
- Go to WP Ghost > Change Paths > Level of Security. Select Safe Mode or Ghost Mode. Click Save.
- Go to WP Ghost > Change Paths > API Security.
- Switch on Disable XML-RPC Access.
- Click Save. The
xmlrpc.phpfile now returns a 404 for all requests. - Run a Security Check at WP Ghost > Security Check to confirm.
Manual check: visit yourdomain.com/xmlrpc.php in a private browser window. If you see a 404 instead of the “XML-RPC server accepts POST requests only” message, protection is active. Full walkthrough in the Disable XML-RPC Access guide.
Whitelisting Jetpack IPs (If Needed)
If you use Jetpack and need to keep XML-RPC accessible to its servers while blocking everyone else, add Jetpack’s IP ranges to your .htaccess file. Add the following at the beginning of your .htaccess:
<Files xmlrpc.php>
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from *.wordpress.com
Allow from 192.0.64.0/18
Allow from 185.64.140.0/22
Allow from 2a04:fa80::/29
Allow from 76.74.255.0/22
Allow from 192.0.65.0/22
Allow from 192.0.80.0/22
Allow from 192.0.96.0/22
Allow from 192.0.123.0/22
Satisfy All
ErrorDocument 404 /
</Files>This blocks all access to xmlrpc.php except from Jetpack’s servers and localhost. If you don’t use Jetpack, you don’t need this, just disable XML-RPC entirely through WP Ghost.
What Happens After You Disable XML-RPC
Brute force amplification attacks stop completely. The system.multicall method is no longer accessible. Attackers can’t bundle password guesses into single requests. Every amplified brute force tool targeting your site fails instantly.
DDoS pingback abuse ends. Your site can no longer be used as a node in pingback-based DDoS amplification attacks.
CMS detection through xmlrpc.php fails. Scanners that check for a responsive xmlrpc.php file get a 404 instead of the tell-tale “XML-RPC server accepts POST requests only” response.
Server resources are freed up. XML-RPC attacks consume CPU and database resources even when they fail. Each authentication attempt triggers a database query. Disabling XML-RPC eliminates this load entirely.
Your normal WordPress functions are unaffected. The REST API handles everything XML-RPC used to do. The block editor, admin dashboard, plugin updates, theme customization, and all admin functions work through the REST API, not XML-RPC. Visitors see no change at all.
Frequently Asked Questions
Should I disable XML-RPC on WordPress?
For most sites, yes. XML-RPC is a legacy protocol that has been replaced by the REST API for virtually all modern use cases. It’s heavily exploited for brute force amplification, DDoS pingback abuse, and username enumeration. Unless you use Jetpack or an older third-party tool that specifically requires XML-RPC, disable it.
What is system.multicall and why is it dangerous?
system.multicall is an XML-RPC method that bundles multiple calls into one HTTP request. Attackers exploit it to send up to 1,999 password guesses per request. Standard login protections see it as one request, not thousands. That’s brute force amplification, and it bypasses login rate limiters on wp-login.php.
Do I need XML-RPC for anything?
Almost certainly not. The REST API has replaced XML-RPC for every modern use case: remote publishing, mobile apps, third-party integrations, and admin automation. The only notable exception is Jetpack, which uses XML-RPC for some features. If you use Jetpack, either whitelist its IP ranges (see the Whitelisting Jetpack IPs section above) or check if Jetpack’s newer versions have migrated to the REST API for your specific features.
What’s the difference between XML-RPC and the REST API?
Both allow remote communication with WordPress, but they’re different systems. XML-RPC uses a single file (xmlrpc.php) with XML-encoded requests. It’s the legacy protocol with minimal security controls. The REST API uses URL-based endpoints (/wp-json/) with JSON-encoded data and supports proper authentication, permissions, and namespacing. For complete API security, secure the REST API as well.
What is pingback DDoS and how does disabling XML-RPC stop it?
WordPress’s pingback feature notifies other sites when you link to their content. Attackers abuse this by sending fake pingback requests to thousands of WordPress sites, all pointing to a single target URL. Each site then makes a request to the target, creating a distributed denial-of-service attack. Your site becomes an involuntary attacker. Disabling XML-RPC removes the pingback.ping method entirely, so your site can’t be weaponized this way.
Does this affect WooCommerce?
No. WooCommerce uses the REST API (/wp-json/wc/v3/), not XML-RPC. Disabling XML-RPC has zero impact on WooCommerce functionality. Cart, checkout, product pages, and all customer-facing features continue working normally. WP Ghost is fully compatible with WooCommerce.
Will the WordPress mobile app still work?
The current WordPress mobile app uses the REST API for most functionality. Older versions relied on XML-RPC. If you use the WordPress app, update it to the latest version before disabling XML-RPC. The modern app works fine without XML-RPC.
Does WP Ghost delete the xmlrpc.php file?
No. WP Ghost never modifies, moves, or deletes any file. The xmlrpc.php file stays on your server. WP Ghost blocks access to it through URL rewrite rules so all requests return a 404. Deactivating WP Ghost restores access to xmlrpc.php instantly.