The XML-RPC Security Challenge
If you run a server hosting multiple websites, you may encounter issues with WordPress installations due to a feature called XML-RPC. This remote admin functionality allows third-party applications to connect to WordPress sites and post new articles or perform other administrative actions.
While XML-RPC is excellent in theory, in practice it has become a significant avenue for attack by bot networks. Server administrators often observe hundreds or thousands of malicious connection attempts per minute across multi-domain hosting environments. On one of our servers hosting 40 sites (nearly all WordPress), these attacks are a constant concern.
Impact on Server Performance
These malicious XML-RPC requests consume valuable server resources even when they fail to compromise a site. With multiple WordPress installations managed by people with varying technical skills, some sites may become vulnerable due to outdated software or poor maintenance practices.
The cumulative impact of these requests can significantly degrade server performance, causing:
- Increased response times for legitimate visitors
- Higher CPU and memory usage
- Potential service disruptions during peak attack periods
- Premature need for hardware upgrades
Implementing a Solution with mod_security
If you’re running mod_security (which is strongly recommended for protecting your sites and your clients’ sites), you can add the following rule to block malicious XML-RPC requests:
#Block requests to xmlrpc.php with no referring URL SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000900,chain,msg:'xmlrpc.php request blocked, no referer'" SecRule &HTTP_REFERER "@eq 0" "chain" SecRule REQUEST_URI "xmlrpc.php"
Adapted from a post on cPanel forums by ‘dalem’ (https://forums.cpanel.net/threads/xmlrpc-spam.646765/)
How This Solution Works
Once implemented, any request to xmlrpc.php that doesn’t originate from a link or trigger from a legitimate website (i.e., has no referrer) will be blocked with a 401 (Forbidden) response. This effectively stops the vast majority of automated attacks whilst allowing legitimate XML-RPC usage.
Enhanced Protection with Firewalls
For additional protection, if you have a firewall or IP banning software such as CSF Firewall or Fail2ban, you can configure these tools to scan your log files and automatically ban repeat offenders that trigger this mod_security rule.
This layered security approach provides both immediate request blocking and longer-term protection against persistent attackers.
When This Approach May Not Be Suitable
This solution may not be appropriate in all scenarios, particularly:
- If you or your customers actively use third-party services that utilise the XML-RPC functionality
- When legitimate applications need programmatic access to WordPress without a referrer
If you have specific IPs that need to access XML-RPC (such as from a content management system or publishing tool), you could modify the rule to exclude those IP addresses. However, this approach may become difficult to maintain over time, especially with services that don’t use fixed IP addresses.
Alternative Approaches
If the solution above doesn’t suit your needs, consider these alternatives:
- Selective enabling: Only enable XML-RPC on specific WordPress sites that genuinely need it
- Plugin solutions: Use security plugins that provide more granular control over XML-RPC access
- IP whitelisting: Configure your web server to only allow XML-RPC requests from trusted IP addresses
- Request throttling: Implement rate limiting for XML-RPC endpoints
Conclusion
By implementing this mod_security rule, you can significantly reduce server load and improve security across multiple WordPress installations. The approach is particularly valuable for shared hosting environments where WordPress sites of varying ages and maintenance levels coexist.
Monitor your server logs after implementation to ensure legitimate services aren’t being inadvertently blocked, and adjust your rules as needed to balance security and functionality.
