Protection for WordPress Pingback Vulnerability
It was recently reported about a WordPress Pingback Vulnerability, whereby an attacker has four potential ways to cause harm via
xmlrpc.php, which is the file included in WordPress for XML-RPC Support (e.g., “pingbacks”). In this post, I offer a simple .htaccess technique to lock things down and protect against any meddling via the
About the Pingback Vulnerability
According to this article, there are four ways that WP‘s XML-RPC API (specifically, the
pingback.ping method) could be abused by an attacker:
- Intel gathering — attacker may probe for specific ports in the target’s internal network
- Port scanning — attacker may port-scan hosts in the internal network
- DoS attacks — attacker may pingback via large number of sites for DoS attack
- Router hacking — attacker may reconfigure an internal router on the network
Again, this is just a summary for reference, see the original article for more details on these various vulnerabilities as well as the
pingback.ping method. No need to rehash everything here :)
Protect against WordPress Pingback Vulnerability
If you know you aren’t using the XML-RPC functionality for anything, and would like to protect against any vulnerabilities, you can lock things down with a simple slice of .htaccess:
# protect xmlrpc <IfModule mod_alias.c> RedirectMatch 403 /xmlrpc.php </IfModule>
Include that after any other rules in your site’s root .htaccess file and you should be good to go. To test that it’s working, try accessing the
xmlrpc.php file in your browser. If it’s working, you’ll get a “403 – Forbidden message”. Tip: to redirect requests for
xmlrpc.php to a custom page, modify the
RedirectMatch like so:
# protect xmlrpc <IfModule mod_alias.c> Redirect 301 /xmlrpc.php http://example.com/custom-page.php </IfModule>
Alternate .htaccess method
Here is an alternate .htaccess technique for denying all access to
# protect xmlrpc <Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
Using this method, it’s possible to allow access to
xmlrpc.php for specific IP addresses. For example, if you know your Blogger and/or MovableType IP(s), you can whitelist them by adding an “Allow” line for each, like so:
# protect xmlrpc <Files xmlrpc.php> Order Deny,Allow Deny from all Allow from 123.456.789 Allow from 321.654.987 </Files>
Note: if you use one of these .htaccess methods, keep in mind that it may be removed once the reported vulnerability is secured in a future version of WordPress.
For further discussion, check out my post at DigWP.com: The xmlrpc.php File and Site Security.
Thanks to Yael K. Miller for bringing this to my attention.
Currently, several of my blogs are being hit with xmlrpc DDOS attacks. I’ve implemented Fail2Ban-fu to counter these attacks.
For Fail2Ban Fans:
# Fail2Ban configuration file
# Read common prefixes. If any customizations available -- read them from
before = common.conf
_daemon = wp-xmlrpc
# Option: failregex
# Notes.: regex to match repeated xmlrpc attacks. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# Values: TEXT
failregex = s.*s.POST /xmlrpc.php HTTP/1.1"*.s.*
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
enabled = true
filter = wp-xmlrpc
action = iptables-multiport[name=wp-xmlrpc, port="80,443", protocol=tcp]
logpath = /home/*/logs/access_log
maxretry = 10
findtime = 60
bantime = 3600
i just had it again, an attack on 11 Domains and a Serverload of 100+ that got my server to its limits, and so i went to your site (http://perishablepress.com/wordpress-xmlrpc-pingback-vulnerability/) to copy the correct htaccess code together and i saw a comment that statet like “In WP 3.5.1 the issue was fixed” and Plugins ans such were no more needed, were removed or can be removed.
Well, the truth is that there are more than enough ppl still trying to use/search for the vulnerability and that can easily bring your server down. With your htaccess code this is easily to avoid. I had just checked the processes, filtered the xmlrpc.php ones out and fixed these htaccess files. In less than 10 minutes the serverload normalized again.
Thanks for the feedback, Sascha. The xmlrpc file indeed remains a huge target for attackers. I think it’s a good idea to disable/block it on any site for which it is not needed. Just helps to keep liability at a minimum.