Weekly ecommerce tips, deals & news.
XML-RPC is an older WordPress protocol that lets outside apps control your site remotely. It runs through a single file called xmlrpc.php, which is switched on by default. Apps have used it to publish posts, pull site data, and send pingbacks between blogs. However, the WordPress REST API has since replaced it for almost every modern use.
XML-RPC stands for XML Remote Procedure Call. Strip the jargon and it’s a way for one program to ask another program to do something. In this case, the request travels as XML, a structured text format, over an ordinary web request.
Think of xmlrpc.php as a single service window at a government office. Every request goes to that same window, whatever you need done. In practice, you hand over a slip naming the task plus your credentials, and the clerk carries it out.
On a real site, an app posts an XML document to yoursite.com/xmlrpc.php. That document names a method, such as wp.newPost, along with a username and password. Then WordPress runs the method and returns an XML response.
Two details matter here. First, the credentials travel inside the request body every single time. On top of that, one request can carry more than one method call.
Because credentials ride along in the body, XML-RPC never supported scoped or revocable access. As a result, every connection used a real account password with full permissions.
Less than most store owners expect. Pingbacks and trackbacks, the automatic notifications between blogs that link to each other, run over XML-RPC. Some older desktop publishing clients and legacy mobile apps used it too.
Still, a handful of plugins call it for remote connections. That’s the real reason to check your own site before switching it off. Your WooCommerce store itself doesn’t need XML-RPC for orders, products, or customers.
Instead, those all run through the WooCommerce REST API. For bulk work, pulling order data out of your store over that API is the cleaner route. Meanwhile, Zapier integrations and webhooks use modern endpoints, not XML-RPC.
One clarification is worth making. XML-RPC has nothing to do with an XML sitemap or an XML product feed. Those are files that search engines and shopping platforms read. By contrast, XML-RPC is a live, two-way channel into your site.
Two abuse patterns made XML-RPC notorious. Note that both come from features working as designed, not from bugs.
The first is brute-force amplification. A method called system.multicall lets one request bundle many method calls together. So attackers used it to test huge batches of passwords in a single hit. Sucuri documented requests built to try 500 passwords in one shot.
That matters because most login monitoring counts requests, not attempts. Four requests look harmless in a log file. Even so, thousands of password guesses could sit behind them.
The second pattern is pingback reflection. Any site can ask another site to send a pingback. So attackers pointed a whole crowd of WordPress sites at one victim. In one documented case, over 162,000 legitimate WordPress sites were turned against a single target.
Scale is what makes this attractive to attackers. WordPress powers 41.2% of all websites, so a default-on endpoint offers an enormous pool. Beyond that, an unused open endpoint is the kind of finding a PCI compliance review raises.
Checking takes about a minute. Visit yoursite.com/xmlrpc.php in a browser and read what comes back. A message saying the server accepts POST requests only means the endpoint is live.
If you get a 403, a 404, or a blank page, something already blocks it. That something is usually your host, a firewall, or a security plugin.
Next, work out what would actually miss it. Scan your active plugins for anything mentioning remote publishing or app connections. Then check whether pingbacks are switched on under Settings, then Discussion.
Imagine a mid-sized outdoor gear store called Ridgeline Supply. It runs WooCommerce, does steady traffic, and has four staff accounts in the admin. Nobody has touched xmlrpc.php since the site launched.
Ridgeline’s host flags a spike in CPU usage. The access log shows thousands of POST requests to /xmlrpc.php from rotating IP addresses. Meanwhile, traffic to the storefront looks completely normal, so nothing visibly broke.
Here’s the part the log hides. Each of those requests may carry a bundled batch of login attempts. Using the same 500-per-request figure Sucuri documented, 400 logged requests could represent up to 200,000 password guesses.
That’s the amplification problem in one line. 400 requests is a rounding error in a traffic report. By contrast, 200,000 password attempts against four admin accounts is a serious incident.
Ridgeline’s real exposure comes down to password quality. Strong, unique passwords survive this kind of pressure. A password reused from an old breach list does not.
Even so, the store is spending real money on the traffic. Every bundled request burns CPU cycles that paying customers should be getting.
Ridgeline’s developer audits which plugins call XML-RPC and finds none in active use. Pingbacks were already switched off in the discussion settings. So the team blocks /xmlrpc.php at the server level, then confirms the storefront and checkout still work.
From there, CPU usage settles the same day. The store loses nothing, because its integrations already ran over the REST API. They also document the change, so a future developer isn’t left puzzling over a blocked endpoint.
The lesson generalizes past this one store. Ridgeline’s risk was never a flaw in WooCommerce or a plugin. In one recent annual review, Patchstack recorded only seven vulnerabilities in WordPress core. By contrast, almost every other finding sat in plugins rather than core.
Both let outside software talk to your site. The difference is how they authenticate, and how precisely you can control what a connection may do.
XML-RPC sends a username and password inside every request. There’s no way to scope what that connection may touch. On top of that, there’s no way to revoke one app without changing the account password.
The REST API takes a different approach. Application passwords, introduced in WordPress 5.6, create a separate credential per application. Each one is individually revocable, so you can cut off a single integration and leave the rest running.
REST also uses clean, predictable URLs per resource instead of one catch-all file. As a result, it’s far easier to monitor, rate-limit, and block selectively. In short, if you’re building anything new, use REST. Token schemes like a JSON Web Token layer on top of it, and XML-RPC has no equivalent.
For most stores, yes. Check first whether any active plugin or connected app relies on it. If nothing does, blocking xmlrpc.php removes an attack surface you aren’t using.
WooCommerce itself doesn’t need it, since orders, products, and customers all move through the REST API. Note that blocking it also disables pingbacks, which most stores are happy to lose. Either way, test checkout once afterward.
It can, so check before you switch it off. Pingbacks and trackbacks stop working, which is usually a feature rather than a loss. Older desktop publishing clients and some legacy mobile apps lose their connection.
Still, a few plugins use XML-RPC for remote linking, so review your active list first. Integrations built on the REST API and application passwords are unaffected. In practice, most modern stores notice nothing at all.
Look at your server access log for POST requests to /xmlrpc.php. A steady stream from rotating IP addresses is the usual signature. Meanwhile, watch for unexplained CPU spikes that don’t match your storefront traffic.
Remember that raw request counts understate the problem. A single request can bundle many login attempts behind it. For that reason, judge severity by CPU load rather than by hit count.
XML-RPC is a solved problem that’s still switched on by default across most WordPress installs. Modern integrations don’t need it, and leaving it open invites password guessing at scale. So audit what actually uses it on your store, then close the door. Locking down unused defaults is quiet work, and it pays off.
Copyright © StoreOwnerTips.com. All Rights Reserved.
