WordPress is a convoluted mess of security holes. Every year millions of WordPress websites are attacked because if the poor security provided by the vendor (WordPress.org / the open-source community). You would think some core things would have been eliminated by now, but no such luck.
To avoid most of these attacks, you just need to follow a simple formula:
- Update WordPress Core
- Update WordPress Plugins
- Update Themes
- Disable themes not in use
- Keep up to date with PHP
For most savvy hosts and conscientious connected hosting clients, this is now common knowledge. WordPress But unfortunately the vendor (WordPress.org and it’s open source community) still haven’t been able to fix one particular bad attack:
XML RPC Attack
Without going into details, xmlrpc.php is by far one of the most common attacks and the sheer number of attempts to breach it will bring a server’s performance down and cause huge CPU spikes. In some cases where RAM and or CPU cycle resources are minimal, the server will quickly get overwhelmed and stop serving efficiently.
Mitigating XML RPC using WP Toolkit on a WHM Server
Fortunately WHM has software called “WP Toolkit” which addresses this issue. Below we have identified a server that might get compromised due to this and the advice that “WP Toolkit” on a WHM server suggests:
Take note the fine print:
This security measure prevents access to the xmlrpc.php file. It is recommended to apply it to reduce attack surface if XML-RPC is not used. This measure modifies the server configuration file (Apache, nginx). Note that custom directives in the .htaccess files might override this.
Also
This vulnerability has no fix from the vendor yet. It can be mitigated by WP Toolkit.
What does this fix do?
- Block access to xmlrpc.php
- Block access to xmlrpc.php
What is this fix called?
WordPress Core All Versions – Unauthenticated Blind Server-Side Request Forgery vulnerability
But what if the site breaks and what if I actually use xmlrpc.php?
xmlrpc.php is a fundamental part of quite a few plugins and APIs. It’s beyond the scope of this article to advise what to do if turning off xmlrpc breaks your website. As with many things IT, application is best, testing, and reverting where need.
To the author of this article who has mitigated 100s of xmlrpc attacks it appears WordPress has an architectural problem with that file and they haven’t been able to address it, sadly.
How does this fix work?
Apache’s .htaccess file and NGinx‘s equivalent is updated to avoid this problem.