XML-RPC brute force looks like traffic

XML-RPC brute force is a flood of POST requests to xmlrpc.php that try passwords or pingbacks in bulk. On shared hosting it often pins CPU, trips CloudLinux LVE limits, and returns 503 errors to real visitors, so it can look like ordinary traffic until you check the URI in the access logs.

What the bot is actually doing

WordPress exposes xmlrpc.php as an API for pingbacks, remote publishing, some mobile apps, and Jetpack. Attackers prefer it because it is not wp-login.php and many sites leave it open without the same rate limits. With system.multicall they can pack many password guesses into a single HTTP request, which is why CPU stays flat while request counts only look moderately busy.

A WAF rule or Imunify often already flags this pattern. Still, if you do not need the endpoint, turn it off. Jetpack and the official mobile app are the usual reasons to keep it. Most sites do not need it day to day. If you must keep it, rate-limit that path rather than the whole site.

How to confirm it on your account

Open the access logs and search for xmlrpc.php. Long runs of POSTs, pingback attempts, or multicall bodies are the usual signature. On CloudLinux LVE graphs you often see PHP entry processes pegged and CPU as a flat top while total traffic is not actually huge. That mismatch is a strong clue you are dealing with auth noise, not customers.

Do not resize the plan first. The same bot will follow you to a larger shared plan or a VPS and keep posting. Fix the door, then recheck the graphs.

Disable the endpoint, then verify

You can block it with a small must-use plugin that returns 403 for xmlrpc.php, a LiteSpeed or .htaccess deny for that file, or the toggle in WP Toolkit on WordPress accounts. After you apply the block, send a test POST to the file and expect a 403. Watch LVE again. If the flat CPU line drops, you were not under-provisioned.

Keep rate limits on wp-login.php either way, because bots that lose xmlrpc often try the login form next. A CDN in front will still forward those POSTs to origin unless you also add a WAF rule at the edge. If Jetpack or a mobile workflow truly needs xmlrpc, leave it on and rate-limit only that path. Most shops here can close it and move on.

If the rectangle stays after you deny the file, look elsewhere: a real crawl, a stuck cron, or a loop in the app. Closing the door you measured is the first step, not buying a bigger plan because xmlrpc was left open.