Skip to content

WordPress

XML-RPC and application passwords

Learn when to close xmlrpc.php and how application passwords replace it for normal WordPress apps.

Updated Aug 29, 20263 min read12 reads
XML-RPC and application passwords
XML-RPC, application passwords, and the REST API

XML-RPC is an older WordPress interface that remote apps use through the xmlrpc.php file. Most sites no longer need it, because the official mobile app and modern tools can use application passwords with the REST API instead. If you leave XML-RPC open without a clear reason, bots often brute-force it, which can look like heavy traffic and lead to 503 errors for real visitors.

Check whether xmlrpc.php responds

You can confirm the endpoint is reachable with a simple request from outside your server. A 200 response usually means the file is still available to the public internet.

bash
curl -sI https://example.com/xmlrpc.php | head

If a POST to that URL returns a method list, XML-RPC is open and bots will find it. Pingbacks are a common spam path even when you plan to keep XML-RPC, so turn them off under Settings → Discussion unless you truly rely on them. Renaming xmlrpc.php is not a lasting fix, because a WordPress update can restore the file.

Disable XML-RPC when you do not need it

On our shared hosting, you can block the file with a LiteSpeed or Apache rule, use WP Toolkit where available, or add a small must-use plugin that returns 403. A WAF rule also works if you are willing to review that WAF’s logs when something breaks. Close the door unless you can name the specific client that still requires XML-RPC. After you block it, run the same curl check from off-box and watch your traffic metrics for a day.

Prefer application passwords and the REST API

In the WordPress admin, open Users → Profile and create an application password for each integration that needs access. Point the official mobile app and other modern tools at /wp-json/ over HTTPS. That path does not require xmlrpc.php. If an old desktop app still insists on XML-RPC, replace the app when you can, or leave the endpoint open only while you actively monitor load. Do not leave it enabled “for later” with no client in use.

Why botnet traffic hurts the whole site

Attackers often send system.multicall requests that pack many password guesses into one POST. PHP workers fill up, and legitimate pages such as checkout wait behind that queue. Security tools or a CDN may catch part of the noise, but the simpler fix is to disable XML-RPC when nothing you run still needs it. Those hits are authentication attempts, not useful visitors. If metrics stay high after you 403 xmlrpc.php, look next at wp-login and REST activity rather than reopening XML-RPC for an abandoned old app.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Tagged

Was this article helpful?

Be the first to rate this article.