To disable XML-RPC in WordPress with WP Ghost: log into your dashboard, go to WP Ghost > Change Paths > API Security, switch on Disable XML-RPC Access, and click Save. That single toggle blocks /xmlrpc.php, kills the system.multicall brute force amplification attack, and stops your site from being used in pingback DDoS campaigns. No code editing, no .htaccess work.
The Four-Step Toggle
- Log into your WordPress dashboard.
- Go to WP Ghost > Change Paths > API Security.
- Switch on Disable XML-RPC Access. This blocks
/xmlrpc.phpand prevents brute force amplification, pingback DDoS, and username enumeration through the legacy API. - Click Save.
Note: one of the security levels (Safe Mode or Ghost Mode) needs to be active for the XML-RPC toggle to apply. Set that first under WP Ghost > Change Paths > Level of Security if you have not already.
What XML-RPC Actually Is (And Why It Is Still There)
XML-RPC is the old way WordPress talked to the outside world, years before the REST API existed. It runs through a single file, xmlrpc.php, sitting in your site root at yourdomain.com/xmlrpc.php. In its day, it handled mobile publishing, pingbacks, trackbacks, and third-party integrations. Modern WordPress does all of that through the REST API (/wp-json/) instead, and the REST API is better in every way: proper authentication, namespacing, rate limiting hooks, the works.
The problem is that xmlrpc.php is still active on every default WordPress install. It was never removed for backward compatibility. And unlike the REST API, it has almost no built-in security controls. No rate limiting. No CAPTCHA. No login attempt tracking. It is a wide-open door that most security plugins do not even monitor.
Default WordPress vs XML-RPC Disabled
| Attack Vector | Default WordPress | With XML-RPC Disabled |
|---|---|---|
| Brute force via system.multicall | Up to 1,999 password guesses per request | 404 response, attack fails |
| Pingback DDoS amplification | Your site weaponized against others | pingback.ping method gone |
| Username enumeration via wp.getUsersBlogs | Confirms valid usernames | No response |
| WordPress CMS fingerprinting | “XML-RPC server accepts POST requests only” | 404 error, no signal |
| Server resource drain from failed attempts | Each attempt triggers DB query | Blocked before WordPress loads |
Why XML-RPC Is the Quiet Favorite of Attackers
The headline risk is an obscure method called system.multicall. It was designed to let apps bundle multiple commands into one request for efficiency. Attackers use it differently. Instead of hitting /wp-login.php 500 times and tripping every brute force protector on your site, they send one HTTP request to xmlrpc.php containing 500 username/password guesses. Public exploit tools push this up to 1,999 attempts per request. Your rate limiter sees one request. The attacker gets 1,999 tries.
On top of that, the pingback.ping method lets attackers weaponize your site in DDoS campaigns. They send fake pingback requests to thousands of WordPress sites, all pointing at one target URL. Every site dutifully makes a request to the target. Congratulations, you just attacked someone without knowing it. Disabling XML-RPC removes the pingback method entirely and takes you out of that ecosystem.
There is also a smaller but real issue: XML-RPC is a WordPress fingerprint. A responsive xmlrpc.php file is how scanners like WPScan confirm you are running WordPress. Even the default error response (“XML-RPC server accepts POST requests only”) tells bots everything they need. Return a 404 instead and that signal is gone.
Does Anything Break When You Disable XML-RPC?
For the vast majority of sites, nothing breaks. The WordPress block editor uses the REST API. Theme and plugin updates use the REST API. The current WordPress mobile app uses the REST API for almost everything. WooCommerce uses the REST API. Gravity Forms, Elementor, WPForms, all REST API. Disabling xmlrpc.php is invisible to normal day-to-day usage.
The one notable exception is Jetpack, which still uses XML-RPC for some of its communication with WordPress.com servers. If you run Jetpack and need those features, either whitelist the Jetpack IP ranges in your .htaccess (covered in the full XML-RPC tutorial) or check if Jetpack’s newer versions have migrated your specific features to the REST API. Other edge cases: really old remote publishing tools, legacy multisite management dashboards, or the WordPress mobile app from several years ago. Update those first, then disable XML-RPC.
Verify It Actually Worked
After saving, confirm the block is active. The easy way: open an incognito window and visit yourdomain.com/xmlrpc.php. If you see a 404 instead of the “XML-RPC server accepts POST requests only” message, you are protected. The thorough way: go to WP Ghost > Security Check, click Start Scan, and let the plugin confirm XML-RPC is blocked along with dozens of other security checks. Full walkthrough in the Website Security Check guide.
Frequently Asked Questions
Should I disable XML-RPC on my WordPress site?
Yes, unless you actively use Jetpack features that require it or an older integration that has not migrated to the REST API. For every other site, disabling XML-RPC closes one of the most exploited doors in WordPress with zero functional downside. It is a one-click win.
What is system.multicall and why does it matter?
It is a legitimate XML-RPC method that lets apps send multiple commands in one request for efficiency. Attackers abuse it to bundle hundreds or thousands of login attempts into a single HTTP request, bypassing login rate limiters that count requests, not attempts. One request, up to 1,999 password guesses. This is the single biggest reason to disable XML-RPC.
Will disabling XML-RPC break Jetpack?
It can, depending on which Jetpack features you use. Some Jetpack modules still rely on XML-RPC for communication with WordPress.com servers. The workaround is to keep xmlrpc.php blocked for everyone except Jetpack’s IP ranges. See the full XML-RPC tutorial for the .htaccess snippet that whitelists Jetpack only.
What is the difference between XML-RPC and the REST API?
Both are ways for external apps to talk to WordPress. XML-RPC is the legacy protocol: one file (xmlrpc.php), XML-encoded requests, almost no security controls. The REST API is modern: URL-based endpoints at /wp-json/, JSON data, proper authentication and permissions. The REST API has replaced XML-RPC for every modern use case. For full API lockdown, also change the REST API path in the same API Security tab.
Does disabling XML-RPC affect WooCommerce?
No. WooCommerce uses the REST API, not XML-RPC. Disabling xmlrpc.php has zero impact on cart, checkout, product pages, customer accounts, or any WooCommerce feature. WP Ghost is fully compatible with WooCommerce.
Will the WordPress mobile app still work?
The current WordPress mobile app uses the REST API for almost everything. Older versions relied on XML-RPC. Update your app to the latest version before disabling XML-RPC and you will not notice a change.
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 requests return a 404. Deactivating WP Ghost restores access instantly.
Does WP Ghost modify WordPress core files?
No. WP Ghost uses server-level rewrite rules and WordPress filters. No core files are touched. Deactivating WP Ghost restores every original path and default instantly, including XML-RPC access.