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 problem is that most people don’t understand WordPress entry points. They see a single login screen and assume that’s the only door into their site. It isn’t. 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 them.
What are WordPress entry points, really?
An entry point is any PHP file in WordPress core that can be reached directly from the outside to start up 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 explains in his write-up on the topic, that design opens up a lot of attack vectors if you’re not careful.
Years ago my first instinct might have been to 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, so you block one IP and a hundred more take its place. That’s reacting, not solving. The fix has to sit at a lower level.
Locking the unused doors
The XML-RPC functionality is a leftover from when we needed it to connect mobile apps and other external services. Most modern sites don’t use it at all. Jetpack is one of the few plugins that still relies on it, but for this client it was a wide-open, unused door that hackers were banging on around the clock. The answer wasn’t a better barricade. It was to 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. It’s the cleanest way to handle it.
add_filter( 'xmlrpc_enabled', '__return_false' );And that was it. The moment I added that filter, the attacks on that entry point stopped, the server load dropped, and the site sped up. It was solved, not patched.
So, what’s the point?
The lesson here isn’t really about xmlrpc.php. It’s about understanding the architecture of the tools you use and thinking a step ahead. Security isn’t a plugin you install and forget. It’s knowing every entry point into your application and deciding, on purpose, who can reach each one. You secure what you know about.
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.
