WordPress xmlrpc.php: What It Does and When to Disable It

Short answer: xmlrpc.php is an old interface that lets external apps and services talk to a WordPress site: publish posts, manage comments and send pingbacks. Most sites no longer need it, because the modern REST API does the same jobs, but it is still enabled by default and is a popular target for password-guessing and pingback abuse. If nothing on your site depends on it, block it at the server level and test that it returns 403. If a service such as Jetpack uses it, keep it open but protect it.

What xmlrpc.php is

XML-RPC is a simple protocol for calling functions on a remote server by sending XML over HTTP. WordPress adopted it early to let people publish from desktop blogging tools and, later, from mobile apps. The file xmlrpc.php in the root of every WordPress installation is the entry point: an app sends a request to it with a username, password and an instruction such as “create a new post”.

XML-RPC has been switched on by default in WordPress for more than a decade. Over the same period, WordPress added the REST API, a more modern interface used by the block editor, current mobile apps and most integrations. For many sites, xmlrpc.php is now a legacy door that nobody uses but that remains open.

The difference matters for security. The REST API has a more modern permission model and supports application passwords, which give each integration its own credential that can be revoked without changing your main password. XML-RPC, by contrast, usually works with the account’s normal password, so every tool that uses it holds a key to the whole account.

If you open https://your-site/xmlrpc.php in a browser and see “XML-RPC server accepts POST requests only”, the interface is active.

Why attackers target it

Automated attacks against WordPress routinely probe xmlrpc.php. There are three main reasons.

• Amplified password guessing. XML-RPC includes a method called system.multicall that runs many calls in one request. Attackers use it to try hundreds of username and password combinations in a single HTTP request, which is far more efficient than attacking the login page and can slip past protections that count requests rather than attempts.
• Bypassing login protection. Some login-limiting tools and CAPTCHA solutions protect only the login form. If xmlrpc.php accepts passwords too, the attacker simply uses that route instead.
• Pingback abuse. The pingback feature makes your server fetch a URL supplied in the request. Attackers have used large numbers of WordPress sites this way to flood a victim with traffic, and pingbacks can reveal information about your server or be used to probe other systems.

Even when attacks fail, the flood of requests to xmlrpc.php can use enough server resources to slow the site down. Our guide to brute-force login protection explains the password-guessing side in more detail.

Signs your xmlrpc.php is under attack

Many site owners only discover XML-RPC when their host complains about resource use. Typical signs include:

• Server access logs full of POST requests to /xmlrpc.php, often from many different IP addresses in a short time.
• High CPU or memory use, slow pages or “resource limit reached” errors on shared hosting, without a matching rise in real visitors.
• Security plugin reports of failed logins for usernames that exist on your site, even though your login page is protected.
• Your host or another network reporting that your server sent unusual requests to other sites, which can happen with pingback abuse.
• Unexplained account lockouts for real users, triggered by guessing attempts against their usernames.

If you see these patterns, blocking xmlrpc.php at the server usually brings resource use down immediately. Then check that no account was actually compromised: review administrator users, recent logins and recently changed content, and change passwords for accounts that were targeted.

Who still needs XML-RPC

Before blocking it, check whether anything on your site depends on it. Common cases:

If you are not sure, look in your server access logs for successful POST requests to xmlrpc.php from recognisable services, or block it on a staging copy first and test your tools.

Three ways to disable it

1. Block the file at the web server (most effective)

Blocking at the server stops the request before WordPress even loads, which also saves resources during attacks.

On Apache or LiteSpeed, add this to the .htaccess file in the site root, outside the WordPress rewrite block:

<Files xmlrpc.php>
    Require all denied
</Files>

On Nginx, add to the server block, before the general PHP location:

location = /xmlrpc.php {
    deny all;
}

If you use Jetpack, allow the service’s published IP ranges instead of denying everything, following Jetpack’s own documentation.

2. Use the firewall, CDN or host

Many web application firewalls, CDNs and managed WordPress hosts offer a rule or a switch to block or rate-limit xmlrpc.php. This works well if you already use one. See whether your website needs a WAF for background.

3. Disable it inside WordPress

Security plugins often include a “disable XML-RPC” option, and developers can use the xmlrpc_enabled filter. Be aware of two limits: WordPress still loads to handle each request, so attack traffic still costs resources, and the xmlrpc_enabled filter by itself turns off methods that require a login but not necessarily pingbacks. Check exactly what your plugin blocks. A server-level rule is simpler and more complete.

Test that it is really blocked

Do not rely on a setting screen; test the result from outside.

1. Open https://your-site/xmlrpc.php in a browser. You should see a 403 Forbidden error, not the “accepts POST requests only” message.
2. Send a real XML-RPC request from the command line, for example: curl -s -d '<methodCall><methodName>system.listMethods</methodName></methodCall>' https://your-site/xmlrpc.php. A blocked endpoint returns 403 rather than a list of methods.
3. If you use a CDN, test from outside your office network so you see what the public sees.
4. Test the tools that should still work: the block editor, your mobile app and any integrations.

Repeat the test after moving hosts, changing CDN settings or switching between Apache and Nginx, because a rule in one place can silently stop applying.

If you must keep it enabled

When a service you rely on needs XML-RPC, reduce the risk instead of closing it:

• Allow requests only from that service’s IP ranges, if it publishes them.
• Rate-limit requests to xmlrpc.php at the firewall or server.
• Remove the system.multicall method and pingback methods with a small code snippet or plugin option, if the service does not need them.
• Use strong, unique passwords and two-factor login for all administrator and editor accounts. Application passwords can give integrations their own revocable credentials.
• Remove unused user accounts, which are all potential targets for guessing.

XML-RPC in the bigger security picture

Closing xmlrpc.php is a quick, worthwhile hardening step, but it is one item in a longer list. Attackers who find it closed will try the login page, vulnerable plugins or stolen passwords instead. Treat it as part of a routine that also covers updates, backups, user accounts, security headers and file protections such as blocking PHP execution in uploads. The WordPress security checklist puts these steps in order, and hiding version details, covered in exposed software versions, makes automated targeting a little harder too.

How Site AI Audit helps

Site AI Audit checks your website from the outside: the SSL certificate and expiry, the HTTPS redirect, security headers and exposed software versions, together with SEO, speed and e-mail authentication. Findings are explained in plain words and ranked by impact, so you can see which security basics need attention first. Paid plans on the pricing page add re-checks and monitoring with alerts.

Related reading

• Website Security for Small Businesses: Where to Start
• Website Security Audit Checklist: What to Check and in What Order
• Outdated Plugins and CMS Versions: A Safe Update Strategy

The bottom line

xmlrpc.php is a remote access interface from an earlier era of WordPress. Most sites no longer use it, and attackers use it to guess passwords efficiently and abuse pingbacks. Check whether Jetpack or another tool depends on it; if not, block it at the server and confirm a 403. If you must keep it, restrict and rate-limit it and protect every account with strong credentials.

FAQ

Is it safe to disable xmlrpc.php?

For most sites, yes. The block editor and REST API integrations do not use it. Check first whether Jetpack, an older app or a remote publishing service depends on it.

Does Jetpack need XML-RPC?

Yes, Jetpack uses XML-RPC to communicate with WordPress.com. If you use Jetpack, allow its servers rather than blocking xmlrpc.php for everyone.

Why do I see so many requests to xmlrpc.php in my logs?

Automated bots probe it constantly, mostly to guess passwords or abuse pingbacks. The volume alone can slow a site, which is another reason to block it at the server.

Is the xmlrpc_enabled filter enough to disable XML-RPC?

Not completely. It turns off methods that require authentication, but WordPress still processes requests and pingbacks may remain. A server-level block is more complete and saves resources.

How do I check if XML-RPC is enabled on my site?

Open your-site/xmlrpc.php in a browser. The message “XML-RPC server accepts POST requests only” means it is active; a 403 error means it is blocked.