I had a client come to me with a site that was crawling. Just constantly slow. Their cheap hosting was sending them CPU limit warnings, and they were getting a flood of notifications from their security plugin about brute-force attacks against a file called xmlrpc.php. Total mess. They had a developer look at it before, who installed Wordfence, saw the alerts, and told them the plugin was handling it. But the site was still slow, and the attacks never stopped.
The previous dev treated the symptom, not the cause. The real issue is that most people don’t understand WordPress entry points. They just see a single login screen and think that’s the only door into their site. It’s not. WordPress has a lot of doors, and if you don’t know they exist, you can’t lock them. The file xmlrpc.php is one of those doors.
What Are WordPress Entry Points, Really?
An entry point is any PHP file in the WordPress core that can be accessed directly from the outside to kickstart the WordPress application. Think of wp-login.php. Or wp-cron.php. Or, in my client’s case, xmlrpc.php. These files load wp-load.php and fire up the whole WordPress environment. As Carl Alexander points out in his deep dive on the topic, this architecture opens up numerous vectors for attack if you’re not careful.
My first instinct, years ago, might have been to just start blocking the attacking IP addresses. And yeah, you can do that. But it’s a losing game of whack-a-mole. Hackers use massive botnets; you block one IP, and a hundred more take its place. You’re just reacting, not solving the problem. The real fix has to be at a more fundamental level.
Locking the Unused Doors
Here’s the kicker. The XML-RPC functionality is a leftover from a time when we needed it to connect to mobile apps and other external services. Most modern sites don’t use it at all. The Jetpack plugin is one of the few that still relies on it, but for this client? It was a wide-open, completely unused door that hackers were banging on 24/7. The solution wasn’t to build a better barricade; it was to just lock the door.
You can disable it completely with one line of code in a site-specific plugin or your theme’s functions.php file. Trust me on this, it’s the right way to handle it.
add_filter( 'xmlrpc_enabled', '__return_false' );And that was it. The second I added that, the attacks on that specific entry point stopped. The server load went down instantly. The site got faster. Problem solved. Not patched, solved.
So, What’s the Point?
The lesson here isn’t just about xmlrpc.php. It’s about thinking like a senior developer. It’s about understanding the architecture of the tools you use. Security isn’t just about installing a plugin and hoping for the best. It’s about knowing all the potential entry points into your application and deliberately controlling access to them. You secure what you know about.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
Leave a Reply