Every WordPress site ships with a file called xmlrpc.php. It is a remote-control interface from the era before the modern REST API: it let desktop blogging apps and the old Jetpack talk to your site. Almost nothing legitimate uses it anymore. Attackers use it daily.

Why attackers like it

  • Amplified brute force. The system.multicall method lets one HTTP request carry hundreds of login attempts. Your login page may be rate-limited; xmlrpc.php usually is not. An attacker can quietly test thousands of passwords with a handful of requests.
  • Pingback abuse. The pingback feature can be told to fetch any URL, which lets attackers use your site as a foot soldier in DDoS attacks against someone else, burning your server resources along the way.
  • A second login door. Any credential an attacker finds elsewhere can be tried here, away from whatever protections your login page has.

Do you still need it?

Probably not. The modern WordPress mobile apps and current Jetpack use the REST API. You only need xmlrpc.php if you rely on a legacy desktop publishing tool or a very old integration. If you are not sure, block it and watch: if nothing breaks in a week, nothing was using it.

How to check and block it

Check whether yours responds:

curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/xmlrpc.php

A 200 or 405 means it is alive. To block it: at the edge is best, with a Cloudflare WAF rule blocking the path, because requests never even reach your server. Alternatively a server rule or a small snippet via the Code Snippets plugin can disable the endpoint. Avoid installing a whole plugin just for this.

A free AuditMerlin scan checks xmlrpc.php exposure along with user enumeration, version disclosure and the rest of the WordPress basics, using only ordinary public requests.