What Is XML-RPC in WordPress and Is It Still Needed?

What Is XML-RPC in WordPress?

XML-RPC is a remote procedure call protocol: a client posts an XML request that names a method and its parameters, and the server runs that method and returns an XML response. WordPress exposes it at xmlrpc.php, the endpoint behind remote publishing, pingbacks and Jetpack.

The request body is a methodCall with a methodName and zero or more params; the reply is a methodResponse or a fault. The endpoint accepts POST only, so a plain browser visit answers "XML-RPC server accepts POST requests only." That is a live endpoint, not an error.

WordPress has left XML-RPC enabled by default since version 3.5, largely for Jetpack and the mobile apps of that era. One feature makes it dangerous: system.multicall lets a single HTTP request carry many method calls, each with its own credentials.

What Still Uses XML-RPC in WordPress?

Desktop blog editors that speak the MetaWeblog API, Jetpack's remote features, pingbacks and older builds of the WordPress mobile app still use the endpoint. The block editor and most current integrations do not: they call the REST API.

• Jetpack: the plugin's connection to WordPress.com uses XML-RPC for several remote actions.
• Desktop editors: MarsEdit and similar tools publish through MetaWeblog methods.
• Pingbacks and trackbacks: other blogs notify your site through pingback.ping.
• Legacy automation: older IFTTT-style recipes and custom scripts that predate REST.

If none of those apply, the endpoint has no job on your site. That is the test to run before deciding.

Why Do Attackers Target xmlrpc.php?

One request can carry hundreds of login attempts, and one pingback call makes your server fetch a URL the attacker chose. Both are cheap to automate and awkward to rate-limit per request, which is why scanners try /xmlrpc.php on every WordPress site they find.

The brute-force path uses system.multicall to pack many wp.getUsersBlogs calls into one POST. A per-request firewall limit sees one request and lets it through, while the body tests a hundred password guesses. Without a lockout or a blocklist, the guesses continue indefinitely.

The second path is pingback.ping: your site is told to fetch a URL, and it does. Attackers point that at internal addresses to probe the network, or at a victim's site so the traffic appears to come from yours. The same method is why a small site can be used as a reflector in a larger flood. A WordPress security checklist usually lists this endpoint first for that reason.

Is XML-RPC Still Needed in 2026?

Only when a tool you actually use depends on it. The REST API covers posts, media, comments, users and settings, and the block editor runs on it, so a site without Jetpack or a desktop editor can turn XML-RPC off with no visible change.

Keep it, restricted, if Jetpack is connected or a publishing tool needs MetaWeblog methods. Disable it if the site only publishes through wp-admin, which is most sites. Either way, test one real action afterwards: publish a draft, open the Jetpack connection, or send a test pingback.

How Do You Check Whether XML-RPC Is Enabled?

Open https://yourdomain.com/xmlrpc.php in a browser. If the page says "XML-RPC server accepts POST requests only.", the endpoint is live. A 403, a 404 or a blank page means something already blocks it, and you can stop here.

• A GET request proves the file is reachable, nothing more.
• A POST with system.listMethods returns the methods enabled; look for pingback.ping and system.multicall.
• Check the same URL with and without www, because a rule can be applied to one host only.
• If a security plugin is active, read its XML-RPC setting before you add a second block.

Do this from outside the server, not from a local shell, or you will test the wrong path.

How Do You Disable or Restrict XML-RPC Safely?

Blocking at the server is the cleanest fix because it stops the request before PHP runs. A plugin is easier to reverse. Restricting to Jetpack's addresses is the middle option when remote publishing must keep working.

• Plugin: a "Disable XML-RPC" plugin returns 403 for the endpoint. Easy to switch off, but it runs after PHP has started.
• Apache: add a <Files xmlrpc.php> block with Require all denied to .htaccess, or to the vhost if you have root.
• Nginx: a location = /xmlrpc.php { deny all; } block in the server config, then reload Nginx.
• WordPress filter: add_filter('xmlrpc_enabled', '__return_false'); stops authenticated methods but leaves pingbacks able to respond, so pair it with a server block.

If Jetpack must stay connected, allow its IP ranges and deny everyone else instead of removing the endpoint. On WebJi® cPanel accounts the host-level WAF also blocks POSTs to xmlrpc.php on request; WordPress hosting covers the server side, and the support desk will confirm which rule is active before you change .htaccess.

XML-RPC vs the WordPress REST API

REST sends JSON to named routes under /wp-json/, uses HTTP verbs, and authenticates with application passwords or a cookie plus nonce. XML-RPC sends an XML envelope to one endpoint over POST and authenticates inside the body.

That difference decides the tooling. REST is easier to call from JavaScript, returns smaller payloads and is what the block editor uses. XML-RPC still has the multicall trick and a long list of legacy clients, which is exactly why it remains a target. New integrations should use REST; XML-RPC should exist only for something that cannot.

Hardening the rest of the site is the next step, and the WordPress security services desk covers the audit, the file permissions and the update policy that sit around this one setting.