XML-RPC

Test whether it responds by sending a POST to /xmlrpc.php with a system.listMethods call; a live endpoint returns a list of methods such as wp.getUsersBlogs and system.multicall. A browser GET returns the text XML-RPC server accepts POST requests only. Count abuse in the access log with grep 'POST /xmlrpc.php' access.log | wc -l.

The system.multicall method lets a client try hundreds of username and password pairs in one HTTP request, which is why attackers like it. Pingbacks through the same file can be used to make your site send requests to a target.

A small clinic's site gets 62,000 POSTs to /xmlrpc.php in a day from a handful of IPs. Each request carries about 500 login guesses. The firewall shows no failed wp-login.php attempts, so the owner's login-limit plugin never triggered.

Blocking the file at the web server with a deny rule returns 403 instantly and cuts CPU use by 40 percent. The owner confirms the mobile app they use now posts through the REST API.

XML-RPC is a separate entry point from wp-admin: it accepts credentials in the request body, so a login-limit on wp-login.php does not cover it. The WordPress REST API replaces it for current features and has per-route permissions. Some older apps, and Jetpack's connection in earlier setups, still call xmlrpc.php.

Securing wp-login.php and leaving xmlrpc.php open. Disabling it with a filter and believing the file no longer receives load, when PHP still starts. Blocking it and breaking Jetpack or a desktop client. Assuming it is only used by attackers. Never reading the access log.

Count requests to xmlrpc.php in your last week of logs. If nothing legitimate uses it, deny the path at the server. If Jetpack or an app needs it, allow only the needed methods or IP ranges and add rate limiting.