Should You Disable
WordPress XML-RPC?
The Honest Answer, Checked For You.
XML-RPC is an older WordPress feature that allows external applications to interact with your site, originally built for the WordPress mobile app and remote publishing tools. Most sites today do not actively use it, yet it remains enabled by default and is a common vector for brute-force attacks and DDoS amplification through its pingback feature.
CV Infotech checks whether you actually need XML-RPC active before recommending anything, since disabling a feature a connected app depends on causes more problems than it solves. If you do not need it, we disable it correctly and verify nothing breaks.
What WordPress XML-RPC Actually Does
XML-RPC is a remote procedure call protocol that WordPress has supported since long before the modern REST API existed, originally enabling the official WordPress mobile app, remote blogging clients, and a feature called pingbacks, which notify a site when another site links to it. The file that handles all of this, xmlrpc.php, sits at the root of every WordPress install and responds to requests by default whether or not anything is actually using it.
The security concern is twofold. First, xmlrpc.php can be used to attempt many username and password combinations in a single request, making it a more efficient brute-force vector than the standard login page for an attacker. Second, the pingback feature can be abused to make a WordPress site unknowingly participate in a distributed denial-of-service attack against a third party, by sending a flood of pingback requests to a target using thousands of compromised or unprotected WordPress sites simultaneously.
Francisco Escobar's WordPress infrastructure has had XML-RPC reviewed and appropriately configured for the full 14 years CV Infotech has managed it, checked as part of every security pass rather than left on whatever the default happened to be. That same review is the first thing we run on any XML-RPC engagement, and it is a standing feature of our plans at /wordpress-maintenance-service/.
We Check Before We Disable Anything
Some sites genuinely need XML-RPC active for the WordPress mobile app or a connected service like Jetpack, and disabling it blindly breaks that functionality entirely.
Pingback-Specific Mitigation Available
If full disabling is not appropriate for your setup, we can disable just the pingback functionality, closing the DDoS amplification risk while preserving other XML-RPC uses.
Verified Against Real Site Functionality
After any change, we test publishing, the mobile app if used, and any connected integrations to confirm nothing legitimate was broken.
Explained In Plain Language
You receive a clear explanation of what XML-RPC does, why it matters for your specific site, and exactly what was changed and why.
What We Cover In Every XML-RPC Review
Dependency Check
We check whether Jetpack, the WordPress mobile app, or any other connected service on your site actually requires XML-RPC before recommending any change, since disabling it blindly can silently break legitimate functionality.
Brute-Force Exposure Assessment
We review whether xmlrpc.php has been targeted by automated login attempts using the system.multicall method, which allows many credential attempts in a single request and is significantly more efficient for an attacker than the standard login form.
Pingback Vulnerability Check
We specifically test whether the pingback.ping method is exposed, which is the component most commonly abused for DDoS amplification attacks against unrelated third-party targets.
Safe Disabling or Partial Restriction
Where full disabling is appropriate, we implement it at the server or plugin level correctly. Where partial functionality is still needed, we restrict specifically the vulnerable methods instead.
Firewall-Level Alternative
For sites where XML-RPC must remain technically available but usage should be restricted, we can configure firewall rules limiting access to trusted IP ranges instead of a full disable.
Post-Change Verification
We test publishing, any mobile app connection, and Jetpack functionality specifically after the change, confirming the site works exactly as it did before, minus the vulnerability.
XML-RPC is a good example of a security decision that is not actually one-size-fits-all, despite a lot of generic advice online simply saying to disable it. A site actively using the WordPress mobile app for publishing, or relying on certain Jetpack features, will break in a visible way if xmlrpc.php is disabled without checking dependencies first, which is precisely the kind of mistake a blanket security checklist produces.
The right approach is checking what your specific site actually uses it for, then applying the narrowest fix that closes the real risk, whether that is a full disable, a pingback-specific restriction, or a firewall rule limiting access. This is a small decision individually, but it is representative of how we approach every hardening recommendation, specific to the site, not generic to the platform.
This service is not the right choice if:
- You have already confirmed XML-RPC is disabled correctly and nothing depends on it
- Your security plugin already handles this and you have verified it is working
- You need a broader security audit rather than this one specific item, see /wordpress-security/security-hardening/
- You actively rely on remote publishing tools and simply want the risk explained, not changed
We will confirm which of these applies during a short review before billing anything.
USA
Compliance: CCPA · Hosting: AWS us-east-1 · Support: EST (UTC-5)
Server and configuration access during the review is handled in compliance with CCPA, processed on AWS us-east-1 infrastructure. Full detail: /web-development-agency-usa/
UK
Compliance: UK GDPR · Hosting: AWS eu-west-2 London · Support: GMT (UTC+0)
UK GDPR governs how any account or configuration data reviewed is handled. John Gowland's real estate platform had XML-RPC reviewed and appropriately configured as part of the same standard. Full detail: /hire-developers-uk/
Australia
Compliance: Privacy Act 1988 · Hosting: AWS ap-southeast-2 Sydney · Support: AEST (UTC+10)
Privacy Act 1988 obligations are factored into how Australian client configuration data is handled. Laura Maher's ongoing WordPress work runs on this same AEST-aligned model. Full detail: /app-development-company-australia/
How To Tell If You Actually Need XML-RPC
Check these before disabling anything yourself.
| # | Item | Why It Matters |
|---|---|---|
| 1 | Do you publish posts using the official WordPress mobile app? | This app relies on XML-RPC in many configurations, disabling it can block publishing from the app |
| 2 | Is Jetpack installed and actively connected? | Some Jetpack features specifically depend on XML-RPC to communicate with WordPress.com |
| 3 | Do you use a remote blogging client outside wp-admin? | Legacy desktop or third-party publishing tools often depend on this protocol |
| 4 | Have you received pingback notifications recently that you actually wanted? | If pingbacks are a feature you use intentionally, a full disable removes that too |
| 5 | Does any third-party integration explicitly document an XML-RPC requirement? | Check integration documentation before assuming nothing depends on it |
We Check Dependencies First
Nothing gets disabled until we confirm what, if anything, on your specific site actually relies on it.
512 Verified 5.0 Reviews
512 reviews on Freelancer.com with a 5.0 rating, from real client engagements.
Partial Restriction Available
If a full disable is not right for your setup, we can close the specific risky methods instead of an all-or-nothing approach.
Francisco Escobar, 14 Years, Zero Breaches
Client since 2012. XML-RPC has been appropriately configured on his infrastructure for the full 14 years.
How We Review And Secure XML-RPC
Six steps from dependency check to the right fix verified and documented.
We check Jetpack, mobile app usage, and any third-party integrations for an actual XML-RPC requirement before recommending anything.
We test whether system.multicall and pingback.ping are currently exposed and being targeted.
Full disable, partial method restriction, or a firewall rule is applied based on what the dependency review actually found.
Publishing, mobile app connection if used, and Jetpack features are tested to confirm nothing legitimate was broken.
We check that blocked requests are actually being rejected at the server level, not just hidden from a plugin's dashboard.
You receive a plain explanation of what was found, what was changed, and why it was the right level of restriction for your site.
Frequently Asked Questions
Not without checking dependencies first. Sites actively using the WordPress mobile app for publishing or certain Jetpack features can break in a visible way if XML-RPC is disabled without confirming what actually relies on it.
It handles remote procedure calls originally built for the WordPress mobile app, remote blogging clients, and the pingback notification feature, allowing external applications to interact with your site without using the standard wp-admin interface.
Its system.multicall method allows many login credential attempts in a single request, making brute-force attacks more efficient than through the standard login page, and its pingback feature can be abused to make your site participate in DDoS attacks against unrelated targets.
It can, depending on your specific app version and configuration, which is exactly why checking dependencies before disabling is the right first step rather than applying a blanket recommendation found in a generic checklist.
Some Jetpack features have historically depended on XML-RPC for communication with WordPress.com, though this has evolved over time, which is why a current check against your specific Jetpack configuration matters more than general advice.
Yes, restricting specifically the system.multicall and pingback.ping methods while leaving other functionality intact is possible and often the better approach for sites with a genuine, narrow dependency.
Server access logs showing repeated POST requests to xmlrpc.php, particularly with unusually large request bodies, are the clearest sign of an active brute-force attempt through this vector.
Our rate is $30 an hour, and a typical review including dependency checking, the appropriate fix, and verification runs a small number of hours.
No, they are separate systems. The REST API is the modern interface most current plugins and the WordPress block editor rely on, while XML-RPC is the older protocol this page addresses, and disabling XML-RPC does not affect REST API functionality.
Many security plugins offer an XML-RPC disable toggle, but toggling it without checking dependencies carries the same risk as any other blanket change, which is why we review actual usage before applying any setting.
Yes, a high volume of automated requests through xmlrpc.php can trigger a hosting provider's resource abuse detection, occasionally leading to a suspension even before the site owner notices anything is wrong.
Yes. $30/hr. Contact us through the form above and we typically complete the review and fix the same day during business hours.
Not Sure If You Actually Need XML-RPC? We Check Before We Touch Anything.
$30/hr. The right fix for your setup, not a blanket disable.