How to disable XML-RPC in WordPress (and whether you actually should)
TL;DR: XML-RPC is a WordPress feature enabling remote communication with your site, historically used for the WordPress mobile app, some third-party publishing tools, Jetpack's own functionality, and the pingback/trackback system, but it is also a documented, real vector for two specific attack patterns: brute-force login amplification (allowing many login attempts to be tested through a single XML-RPC request rather than the standard login form, bypassing some login-specific rate limiting) and pingback-based DDoS amplification. Whether disabling it is the right move depends on whether you actually use anything that depends on it, checking this first, rather than disabling it blindly based on generic security advice, avoids breaking a legitimate integration you may not realize relies on it.
What XML-RPC actually does
XML-RPC is a protocol WordPress implements (via the xmlrpc.php file at your site's root) allowing external applications and services to communicate with your WordPress installation remotely, performing actions like publishing a post, retrieving content, or managing comments without going through the standard web-based admin interface. It was historically significant as the mechanism enabling the original WordPress mobile apps and various third-party blogging clients to interact with a WordPress site, and it remains the underlying mechanism for certain still-active functionality, including Jetpack's core features and the pingback/trackback system (a mechanism for sites to notify each other when they link to one another's content).
The two specific security concerns
Brute-force login amplification. XML-RPC's system.multicall method allows multiple method calls, including authentication attempts, to be bundled into a single HTTP request, which means an attacker can test a large number of username/password combinations far more efficiently through this single endpoint than through WordPress's standard login form, which is where most login-attempt rate-limiting and lockout mechanisms (covered in our wp-admin brute-force guide) are specifically focused. This makes XML-RPC a genuine, documented amplification vector for brute-force attacks that can partially bypass defenses specifically designed around the standard login form.
Pingback-based DDoS amplification. The pingback mechanism can, in certain attack configurations, be exploited to have your server send a large volume of requests to a third-party target (an attacker instructing many WordPress sites' pingback functionality to all simultaneously send requests toward a single victim), making your server an unwitting participant in an attack against someone else entirely, a distinct concern from an attack directed at your own site specifically.
What actually still depends on it
Despite these legitimate concerns, disabling XML-RPC entirely is not risk-free, since certain functionality genuinely still relies on it, and blanket disabling without checking can break things unexpectedly. Jetpack, a very widely used plugin, has historically depended on XML-RPC for core functionality (though this has evolved over various Jetpack versions, and checking your specific installed version's current requirements is worth doing directly rather than assuming based on older information). Some third-party publishing and content-management integrations, certain automated posting tools, and some legacy mobile or desktop blogging clients still use XML-RPC as their communication method, though this has become less universal as more modern integrations increasingly use the WordPress REST API instead, covered in our REST API 403 guide, a separate, more modern system serving some overlapping purposes.
How to check if you're actually using it
Rather than assuming, check directly before disabling anything. Review your active plugins for any that explicitly document XML-RPC as a requirement, Jetpack being the most common example worth checking specifically against your installed version's current documentation. Check server access logs for actual recent requests to xmlrpc.php from sources other than obvious automated scanning/attack traffic (which is extremely common and not evidence of legitimate use, since XML-RPC is a very commonly probed endpoint by automated bots regardless of whether you use it legitimately), looking specifically for patterns consistent with a legitimate integration you recognize rather than generic scanning noise. If you use any third-party app or service to publish content to your site remotely, confirm directly with that specific service's documentation whether it uses XML-RPC or the newer REST API for its connection.
Option 1: disable it completely
If you have confirmed no legitimate dependency, the most direct approach is disabling XML-RPC entirely, either via a security plugin's specific setting for this (many popular WordPress security plugins include a straightforward toggle for exactly this purpose, the simplest approach for most site owners) or via a direct code-level block (adding specific rules to .htaccess on Apache-based hosting, or an equivalent server-level rule, blocking direct access to xmlrpc.php), which fully removes both the brute-force amplification and pingback DDoS participation concerns simultaneously, at the cost of breaking any functionality that genuinely depended on it.
Option 2: disable only the risky parts
A more surgical, less disruptive alternative addresses the specific security concerns without fully disabling the entire protocol, worth considering if you have confirmed some genuine dependency exists but still want to reduce the specific risks. Disabling only the pingback/trackback-related XML-RPC methods specifically (several security plugins offer this more granular option, or it can be implemented via a small code snippet filtering out the specific pingback methods from XML-RPC's available method list) addresses the DDoS amplification concern while leaving other XML-RPC functionality, potentially including whatever your genuine dependency relies on, intact. Alternatively, rather than disabling XML-RPC itself, applying strong rate limiting and monitoring specifically to requests targeting xmlrpc.php (similar in principle to the login-attempt rate limiting covered in our wp-admin brute-force guide, but applied to this specific endpoint) reduces the brute-force amplification risk without removing the functionality entirely.
A decision table
| Your situation | Recommended approach |
|---|---|
| No Jetpack, no remote publishing tools, no confirmed legitimate use | Disable XML-RPC completely |
| Using Jetpack (confirm current version's actual requirement) | Check Jetpack's specific current XML-RPC dependency before disabling |
| Using a third-party app/service for remote publishing | Confirm with that service whether it uses XML-RPC or the REST API |
| Some dependency confirmed, but want to reduce DDoS risk specifically | Disable pingback methods only, leave rest of XML-RPC intact |
| Uncertain, want a lower-risk middle ground | Apply strong rate limiting to xmlrpc.php rather than disabling outright |
FAQs
Will disabling XML-RPC break my WordPress mobile app?
Modern versions of the official WordPress mobile app primarily use the WordPress REST API rather than XML-RPC, so for most current setups this is not a concern, though if you are using a notably outdated version of the app or a specific third-party mobile client, checking that specific app's current requirements directly is worth confirming rather than assuming based on the modern default.
Does every WordPress site get probed for XML-RPC vulnerabilities, or only specific targets?
Automated scanning for xmlrpc.php and attempts to exploit it are extremely common, indiscriminate background activity affecting essentially every publicly reachable WordPress site, similar in nature to the brute-force login scanning discussed in our wp-admin security guide, not evidence of your specific site being individually targeted.
If I disable XML-RPC, will pingbacks/trackbacks from other sites linking to me stop working?
Yes, disabling XML-RPC entirely removes pingback/trackback functionality along with everything else that relies on the protocol; if you specifically value this feature (many site owners find pingback/trackback spam more of a nuisance than a benefit and have already disabled it separately regardless of this broader XML-RPC question), the surgical approach of disabling only the pingback-specific methods while leaving other functionality intact, or accepting the loss of this specific feature as a reasonable trade-off, are both valid choices depending on how much you actually value it.
Is XML-RPC an outdated technology that WordPress is planning to remove?
WordPress has not announced plans to remove XML-RPC entirely, given that some functionality (including certain Jetpack features, depending on version) continues to depend on it, though the broader trend has been toward the more modern REST API for new integrations and functionality, meaning XML-RPC's relative importance has been gradually declining even without a formal deprecation.
Does using a security plugin's XML-RPC toggle fully protect me, or do I need additional steps?
For most site owners, a reputable security plugin's toggle to disable XML-RPC (once you have confirmed you do not need it) is sufficient and effectively closes this specific attack vector; additional server-level blocking is a reasonable extra layer of redundancy but is not strictly necessary if the plugin-level disable is correctly functioning, which is worth verifying by confirming xmlrpc.php genuinely returns an error or block response after the setting is applied.
Can I test whether XML-RPC is currently enabled or disabled on my site?
Yes, loading yourdomain.com/xmlrpc.php directly in a browser shows a specific response indicating whether it is active (typically a message about requiring a POST request rather than a direct GET, indicating it is live and listening) or blocked (typically a 403 or similar error if properly disabled), a quick, direct way to confirm your current configuration status.
Should a brand new WordPress site disable XML-RPC by default from the start?
This is a reasonable default for a new site with no established Jetpack usage or remote publishing integration yet, since there is no existing dependency to break; if a genuine need for it (Jetpack's specific features, a remote publishing tool) emerges later, it can be re-enabled at that point rather than needing to be left on preemptively for a hypothetical future need.
Conclusion
XML-RPC presents genuine, documented security concerns, specifically brute-force amplification and pingback-based DDoS participation, but blanket disabling without first checking your actual dependencies risks breaking legitimate functionality, particularly around Jetpack or third-party remote publishing tools that may still rely on it. Check your specific plugins and integrations' actual current requirements before disabling, rather than following generic advice that assumes no one ever legitimately needs it.
For most sites confirmed to have no genuine dependency, disabling XML-RPC completely via a security plugin's straightforward toggle is the simplest, most complete fix; for sites with a confirmed but narrow dependency, disabling only the pingback-specific methods, or applying strong rate limiting to the endpoint instead of a full disable, offers a more surgical middle ground.
HostCloud's managed WordPress hosting includes server-level rate limiting on commonly abused endpoints including xmlrpc.php as standard, providing a baseline layer of protection regardless of your specific plugin-level configuration choice. Plans start at ₹99 a month at https://hostcloud.in.