Your blog has been hacked. Actually, maybe not. The Pingback Exploit.

This morning I got an email from a person named Sam Browne with the ominous subject line “Your blog has been hacked“. The email read as follows:

I am Sam Bowne, an Instructor in Computer Networking and Information Technology at City College San Francisco. Your blog has been hacked, and is being used to attack other sites. The specific URL and IP address involved in attacks is in the list below.

Please scan your blog and clean it.

Complete information about this is at:

Now I get a lot of crazy emails from a lot of crazy people so my initial reaction was that this is another one destined for the spam pile. But at the bottom of the email was a list of about 50 sites that were supposedly hacked and looking through it I got curious. On the list, which included a site I managed years ago, I found URLs like,, and The chance of any of these sites being hacked and used to spam Mr. Browne is pretty close to zero so clearly there was something else going on here.

Browsing the responses to Sam’s Twitter stream it became clear that many of the people who had received the same email (apparently it was sent to thousands of email addresses) had done their due diligence by checking their sites for exploits only to find they were in fact not hacked. My guess is that if we were to check all the sites on the list we’d find very few sites with hacks on them. But the claim that the sites were attacking Mr. Browne’s site are still true!

Your WordPress site can be tricked

It is a poorly kept secret that with some simple code you can turn a WordPress site into a tool of evil. Hidden in WordPress core is a function called XML-RPC that allows users to send emails to WordPress and then get WordPress to do things like publish posts. The feature also powers pingbacks – essentially messages sent to other sites when they are being linked to –  and it is very useful if you want to use a 3rd party application to write posts or you want to email posts to your site. This function can unfortunately be exploited to make your site send requests to target sites, thus becoming an accomplice in a DDoS attack.

It is disturbingly simple: A few lines of code will trigger a cascade of requests to your WordPress site that then in turn send pingback requests to a specified site. Multiply that by a hundred or a thousand or a million sites like yours and you have a perfectly orchestrated DDoS attack executed by proxy through your and other sites. Which seems to be what happened to Mr. Browne. Again, not an attack but an exploit.

Based on the list of sites provided by Sam and my own observations of spam comments it seems clear that a large portion of the sites that are taking down Sam’s site are in fact not infected but instead vulnerable to the pingback exploit. In fact it appears any standard install WordPress site without Akismet activated is vulnerable to this exploit. Which is a serious problem.

Solutions, current and future

This exploit is well known by the developers that build WordPress and it is being worked on. However as of right now your WordPress site may become part of the problem unless you take a simple step to prevent it: Go to Settings -> Discussion and turn   off. Some are suggesting removing the XML-RPC feature all together by deleting it from the WordPress install. This is a terrible idea and should not be done. WordPress core is not something you should mess with and the XMLRPC function is used for more than just sending out pingbacks, most notably to allow a user to post to the site using email or 3rd party apps.

Moving forward it’s clear this needs to be addressed in WordPress core so new users do not inadvertently become bots. What exactly that something is is up for debate. Simply disabling XML-RPC is not a solution yet leaving it completely open is an equal non-starter. Bottom line is a push needs to be made to get core updated in some way to curb this problem going forward. WordPress powers 20% of the web and will continue to take over more of the space so these exploits will be exploited more and more if nothing is done.


Brute force attacks call for an end to the default “admin” WordPress user

UPDATE: Chris Rudzki filed ticket #24078 in Track on April 13th to get the suggested username removed. There is some contention in the comments but overall it looks like this may be implemented.

UPDATE #2: Just published an extensive post on the blog with security tips and what to do if your site falls victim to this attack.

WordPress is under attack by brute force hackers. The target: WordPress installs with the username “admin” and other common test users (“Admin”, “test”, “Administrator” etc). While this is disturbing the more disturbing fact is that as it stands WordPress is encouraging new users to set up an admin account with the username “admin” thereby perpetuating the situation. This cannot continue.

If you are running a WordPress site there is a good chance you will become the subject of a brute force attack aiming to get login access to your site through the default admin account. For the layman this means a computer goes to the login page on your site with the username “admin” and tries every password under the sun to see if it can get in. In the last few days two major hosting companies – HostGator and CloudFlare – have released reports that tens of thousands of sites are under attack from a “well organized” individual or group.

Others have written extensively on the subject (here, here, here, here, here, etc) so I won’t reiterate what they have said better than me. Instead I will point out an obvious flaw in WordPress itself that is amplifying the problem and that can be easily fixed:

Problem: “admin” is still the default user name

Screen grab of the WordPress 5 minute install with "admin" set by default as the username
Even in version 3.6 “admin” is still the default username in WordPress

If you’ve been around for a while you know that in the past the first user created when WordPress was installed was always called “admin”. This lead to a barrage of brute force attacks on WordPress sites and was deemed to be enough of a vulnerability that by version 2.9 the user was prompted to set the admin user name manually.


So why are there so many sites that still have an admin user with the username “admin” even with the vulnerabilities and the ability to set the name manually? Simple: Like you can see in the image above, the suggested admin user name is still “admin” and will be used unless the user explicitly changes it to something else. And while seasoned WordPress users are aware of this and avoid using the name “admin”, new users are given no indication that using “admin” as the username is a bad idea.

In fact I would argue the current setup in which the username is automatically filled out with “admin” encourages new users to use the name thereby making them more vulnerable.

Solution: “admin” shouldn’t be an option

Considering the history of the “admin” user name and the fact that people still use it (because it is still the default and WordPress suggests they do) two things should be done:

  1. Force the user to set a username herself by not providing one in the field
  2. Add a filter that prevents “admin” from being used as a username

None of these are technically complex, and similar filters are used by other services and applications to avoid this exact issue.

As WordPress takes over a larger and larger share of the new site market it is more important than ever to ensure that new users are not led down a dangerous path. Suggesting “admin” as the username for the first user is precisely the type of path the new user should never be led down. I rest my case.