Free tools Windows power users keep installed
One-click scans. No signup required.
XML-RPC is WordPress’s legacy remote-control interface. It allows approved apps and services to publish posts, manage a site, send pingbacks and call other WordPress methods through /xmlrpc.php. WordPress has enabled it by default since 3.5.0. Disable or block the endpoint when no integration needs it; if a service such as Jetpack depends on it, keep it available and protect it with edge rate limiting, monitoring and server or WAF rules.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What XML-RPC is in WordPress
XML-RPC is an API that accepts structured XML requests over HTTP. A remote client sends a method name and parameters to your site’s xmlrpc.php endpoint; WordPress authenticates the request when the method requires a login, runs the method and returns an XML response. It predates WordPress’s modern administration and REST interfaces and remains in core for backward compatibility.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Which features use it
WordPress core documents support for the Blogger API, MetaWeblog API, MovableType API, pingback methods and WordPress-specific management methods. Depending on the client, XML-RPC can be used to create or edit posts, upload media, moderate comments, query site information or perform other remote-management actions. Pingbacks are different from ordinary publishing calls: they can invoke XML-RPC methods without the same authenticated workflow.
Why the endpoint is present by default
Core has enabled XML-RPC by default since WordPress 3.5.0 so that established mobile apps, desktop editors, automation tools and hosted services continue to work without a manual switch. “Enabled” does not mean every method is useful on every site. It means the route is exposed and individual methods decide whether they need authentication and what they do.
#1 Best Overall
Why administrators worry about XML-RPC
The endpoint is a frequent brute-force target, particularly the system.multicall method. A multicall request can package many method calls into one HTTP request, allowing an attacker to test credentials or consume server resources with fewer network round trips. An exposed endpoint can therefore create login noise, CPU and PHP work, and an additional route that must be monitored.
That does not make XML-RPC inherently insecure, and there is no authoritative percentage showing what share of all WordPress attacks comes through it. Risk depends on whether the site needs the interface, how authentication is configured, how much traffic reaches it and whether controls are applied before PHP runs.
The crucial distinction: method filtering versus blocking
WordPress’s xmlrpc_enabled filter has a narrower effect than its name suggests. The official hook reference says it controls XML-RPC methods that require authentication, such as publishing methods; it does not determine whether XML-RPC is fully enabled and does not control pingbacks or other custom methods that do not require authentication.
As a result, three different actions are often described as “disabling XML-RPC”:
- Disable authenticated methods: stop login-dependent publishing and management calls in WordPress.
- Remove selected methods: for example, remove pingback methods while leaving other calls available.
- Block the route: deny every request to
/xmlrpc.phpat the web server, reverse proxy or WAF.
A security plugin or hosting toggle may perform any one of these. Verify its actual scope instead of assuming that a successful filter blocks every XML-RPC request.
Should you disable XML-RPC?
Use an inventory-and-dependency decision rather than a blanket rule. Disabling unused XML-RPC follows WordPress’s own security guidance: “If you don’t use XML-RPC, disable it.” The right choice depends on what your site actually connects to.
Disable or block it when none of these apply
- Jetpack or another service that explicitly requires XML-RPC.
- A mobile app, desktop editor or external publishing workflow that posts through XML-RPC.
- Automation or vendor software documented as using
xmlrpc.php. - Pingbacks that you intentionally need to receive or send.
For a site with no such dependency, blocking the route removes an unnecessary exposed login and request surface. It also avoids having to absorb multicall traffic in WordPress.
Keep it when a required integration depends on it
Do not block the endpoint merely because it is old. Jetpack states that XML-RPC is the connection it uses to communicate with WordPress.com, and that blocking xmlrpc.php causes connection and feature problems. Its support documentation also requires the XML-RPC file to be publicly accessible during installation and says that hosts and security plugins must not reject those requests.
Jetpack describes its authentication as token-based rather than sending the site’s WordPress username and password through the API. That lowers the risk of treating every Jetpack request as a password attempt, but it does not make unrelated automated traffic safe. The endpoint still needs rate limits and monitoring.
Decision matrix
| Control | Jetpack and remote publishing | What it removes | Brute-force/resource protection | Operational complexity | Allowlisting and rate limiting |
|---|---|---|---|---|---|
Block /xmlrpc.php at a WAF, reverse proxy or host |
Incompatible with integrations that require XML-RPC | All methods and endpoint traffic | Strongest, because requests can be rejected before WordPress/PHP runs | Usually low once the rule is deployed; coordinate with the host | Can be precise if the edge product supports trusted-source rules |
| Use a maintained control that disables authenticated methods | May break publishing clients; test each integration | Authentication-dependent methods only | Partial; pingbacks and other methods can remain | Moderate; behavior depends on the implementation | Usually limited to application-level controls |
| Remove selected methods such as pingbacks | Preserves clients that use other methods | Only the methods you remove | Targeted; it does not stop password attacks against remaining methods | Moderate; requires knowing the method names | Usually requires separate server or WAF rules |
| Leave XML-RPC available and harden it | Compatible | Nothing by default | Depends on edge rate limits, monitoring and account security | Ongoing operational work | Best option for allowlists and differentiated limits |
How to disable XML-RPC completely
- Inventory first. Check Jetpack, mobile or desktop publishing clients, scheduled jobs, vendor integrations and pingback requirements. Search integration documentation and server logs for requests to
/xmlrpc.php. - Choose an edge or server control. Ask your host, reverse proxy or WAF to deny the exact
/xmlrpc.phproute. A route-level deny is the clearest way to remove all XML-RPC methods, including unauthenticated pingback calls. - Deploy the rule in a reversible way. Record the old setting, apply the deny rule, and keep an administrative path available so you can remove it if a required service stops working. A host may return 403, 404 or another deny response; the exact status depends on its configuration.
- Test the site’s real workflows. Publish or update content through every app and service you identified. Check scheduled jobs, media uploads and any pingback-dependent process rather than testing only the public homepage.
- Watch logs after deployment. Confirm that expected clients are not being denied and that repeated requests to the route are no longer reaching WordPress. If an integration fails, temporarily remove the block while you determine the narrowest safe exception.
A plugin or theme snippet that claims to disable XML-RPC may only turn off authenticated methods. Treat it as a method-level control unless its documentation and your tests show that the web route itself is inaccessible.
Application-level method control
WordPress documents this filter for disabling authenticated XML-RPC methods:
add_filter( 'xmlrpc_enabled', '__return_false' );Place such code in a maintained site-specific plugin or another deployment mechanism that will not disappear when a theme changes. This filter is not a complete endpoint block: pingbacks and custom unauthenticated methods can still be available. For finer control, WordPress points to the xmlrpc_methods and xmlrpc_element_limit hooks. Use those only when you understand which clients and methods your site requires.
How to stop XML-RPC brute-force attacks without breaking integrations
- Rate-limit at the edge. Apply limits in the WAF, reverse proxy or web server so abusive requests are rejected before PHP starts. WordPress specifically favors edge or server controls because application-level throttling can still make PHP process a heavy attack.
- Allow trusted traffic where practical. If your integration publishes from known service networks, create an allowlist or a separate rule for that traffic. Keep the list maintained; cloud services can change addresses.
- Monitor authentication anomalies. Alert on repeated failed XML-RPC logins, bursts of
system.multicallrequests, unusual countries or user agents, and sudden increases in request volume. Correlate these events with normal publishing activity. - Protect the accounts that can publish. Use long, unique passwords, remove unused administrator accounts, apply least privilege and enable two-factor authentication for administrator users. These steps matter even when XML-RPC is needed.
- Keep WordPress and integrations current. Updates can change supported methods and security behavior. Re-test after updates that affect authentication, firewall rules or the publishing client.
Jetpack-specific compatibility checks
When Jetpack is installed or being connected, blocking xmlrpc.php can prevent the connection and disable features that rely on it. Before changing a firewall rule:
- Confirm that the XML-RPC file is publicly reachable from the service’s network.
- Check that a security plugin or host rule is not rejecting WordPress.com traffic.
- After changing limits, reconnect or run Jetpack’s connection troubleshooting process and inspect the reported blocked requests.
- Do not replace a complete block with an unrestricted endpoint merely to make the connection pass; use the narrowest allowlist and rate limit your host supports.
How to verify what your change actually did
Confirm a complete block
Request https://your-domain.example/xmlrpc.php from an external network or use your monitoring service. A route-level block should produce the deny response configured by your host and should appear in edge logs rather than WordPress application logs. Then test every legitimate integration listed in your inventory.
Confirm a method-level filter
If the route still responds but authenticated publishing calls fail, you probably disabled methods rather than the endpoint. Test whether pingback-related requests and any custom methods remain possible. If your goal was to remove all XML-RPC traffic, move the control to the server, reverse proxy or WAF.
Interpret a sudden integration failure
- Jetpack will not connect: inspect firewall and WAF logs for blocked XML-RPC requests and restore access for the required service.
- A mobile editor cannot publish: verify whether it uses XML-RPC and whether your filter disabled its authenticated method.
- Brute-force alerts continue after using
xmlrpc_enabled: the route or pingback methods are still exposed; add edge rate limiting or block the route. - Pingbacks continue after disabling authenticated methods: remove the pingback methods specifically or deny the entire endpoint.
Bottom line
XML-RPC is a compatibility interface, not a requirement for every WordPress site. If your inventory finds no client or service that needs it, block /xmlrpc.php at the edge or server. If an integration requires it, retain the endpoint but rate-limit and monitor it before requests reach PHP, protect publishing accounts with strong credentials and two-factor authentication, and verify every change. The single most common mistake is treating add_filter( 'xmlrpc_enabled', '__return_false' ) as a universal switch; it disables authenticated methods, not necessarily XML-RPC itself.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
