Protect Against WordPress Brute Force Amplification Attack

It seems the WordPress xmlrpc.php file is the target of another type of attack. Before, it was the XML-RPC Pingback Vulnerability. Now, it is the Brute Force Amplification Attack. This post explains what you need to know and then cuts to the chase with several ways to protect your site against this new malicious exploit, as well as all other related threats.

What is XML-RPC?

Before getting into protecting the xmlrpc.php file, it is important to understand what it does. As explained here:

[XML-RPC is] a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet. It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.

If you’re scratching your head, basically that means that XML-RPC enables remote platforms to interact with each other over the internet. More specifically, the WordPress xmlrpc.php file enables external applications to connect, transmit, and process data.

Do I need XML-RPC?

If you have to ask, chances are you do NOT need the xmlrpc.php file. But there are various plugins that may make use of WP’s XML-RPC functionality for various remote operations, so if in doubt ask the developers of whichever plugins you are using. In my experience, 99% of WordPress-powered sites do not use the xmlrpc.php file whatsoever. So as long as you are sure that you don’t need the file, it’s fine to delete, block, or disable it. Read on for numerous ways to secure your site against XML-RPC threats.

Protect via plugin

If adding/maintaining another plugin is your thing, then head on over to the WordPress Plugin Directory and search for “xmlrpc plugin” or similar. I’m sure there is at least one plugin that is suitable for disabling xmlrpc.php.

Protect via .htaccess

If you are savvy with .htaccess, there are numerous ways to go about blocking access to the xmlrpc.php file. Here are two of the simplest ways of doing so:

Block xmlrpc.php via RedirectMatch

# protect xmlrpc
<IfModule mod_alias.c>
	RedirectMatch 403 (?i)/xmlrpc.php

The nice thing about this technique is that it doesn’t matter where you have installed WordPress. The xmlrpc.php file will be protected regardless of its location in the directory structure (e.g., /wp/xmlrpc.php, /wordpress/xmlrpc.php, /whatever/xmlrpc.php, etc.). It’s also case-insensitive, so you’re protected against any “all-cap” attack variations.

Block xmlrpc.php via Order/Deny

# protect xmlrpc
<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all

Either of these snippets work perfectly to protect the xmlrpc.php file by blocking all access to it. This is my preferred method of securing against XML-RPC attacks. It’s easy, thorough, reliable, and maintenance-free. Of course, it is possible to customize these xmlrpc.php .htaccess techniques to do stuff like allow access from specific IP addresses and redirecting blocked requests to a specific page.

Alternately, you can block access using mod_rewrite via a variety of request variables. With .htaccess, there are many possibilities.

Protect via custom function

If you don’t want to use another plugin, and don’t want to mess with .htaccess, another way to protect against the Brute Force Amplification Attack specifically is to disable the system.multicall functionality of the xmlrpc.php file. Here is the function that you can add directly via your theme’s functions.php file:

function shapeSpace_disable_xmlrpc_multicall($methods) {
	return $methods;
add_filter('xmlrpc_methods', 'shapeSpace_disable_xmlrpc_multicall');

Some pros and cons about this method:

  • Pro – no need to maintain another plugin
  • Pro – no need for .htaccess
  • Con – is theme-specific
  • Con – is threat-specific

So the pros are self-explanatory, but the cons may be elaborated upon. By “theme-specific”, that basically means that the function will help protect only when the theme that includes it is active. That is, if you switch themes, you lose protection unless you add the function to your new theme. And by “threat-specific”, that means that this function disables only the system.multicall aspect of xmlrpc.php. So it works to protect against the Brute Force Amplification Attack specifically — not any of the other attacks that currently target the xmlrpc.php file. This is another reason why the .htaccess technique is an ideal choice for securing your site: it protects against all types of XML-RPC attacks.

Bottom Line

Be aware that the WordPress xmlrpc.php file is a huge attack vector. If you’re running the latest version of WordPress, technically you have nothing to worry about, but even so the file remains a perpetual target for attackers. The bad guys are constantly scanning for vulnerabilities related to pingbacks, amplification attacks, brute-force attacks, and all sorts of other mischief.

With that in mind, it’s advisable to protect your site according to your own security strategy. If you’re not using the file, I recommend disabling, deleting, or denying access.