GoDaddy-hosted sites at risk — WordPress, Joomla!, Pligg, ZenCart, others…

Recently, there was a malicious attack on GoDaddy-hosted sites. It’s tough to track down the exact date of the original attack — I was first able to find a mention of it on Slashdot from 4/26, and I found a topic in the WordPress support forums that supported that approximate time. However, I also found another post elsewhere with a Unix/Linux shell script that would fix what appears to be the same issue which was dated March 2, so this may have been around much longer.  At any rate, there seems to have been another major wave this past weekend.

Last month, Network Solutions was targeted by what appeared to be a malicious user who was able to gain access to sites’ databases by accessing the database server, username and password from the wp-config.php file common to all WordPress installations.  The attack took advantage of the fact that most users don’t change their file permissions, and left the wp-config.php file — with all the above information that it contained — in a public-readable state.  Once the database username and password were obtained, the hacker added a redirect script in the Site URL setting in the options stored in the database which redirected visitors to a site of his choosing.

This taught us the lesson to make sure your files — especially the important files with sensitive data contained within them, like passwords — are properly secured by correct file permissions.

This particular hack on GoDaddy sites did not attack the database, the upside of which means your data, stored passwords, posts, and everything else are still safe. However, according to the reports I found, what it did was embed a small javascript at the bottom of every php file.  The embedded code would ultimately cause visitors to be redirected to a malicious site that would install malware on their PC.  Based on the domain names that were grabbed by an independent security analyst, it looks like the end-goal was to infect a visitor’s computer with malicious software or viruses and then sell them antivirus software (the virus-scanning effectiveness of which would, presumably, be fairly suspect, given the circumstances) — the domains were things like,,,, etc.  That post also points out that the person or people behind this attack have done this before.

So you have a GoDaddy site running WordPress, how do you know your site is infected?  If your site was infected, you would see this when you logged into your dashboard:

At first glance it just looks like the CSS is messed up, not anything that might suggest a virus.  However, when I tried to access the admin panel on two GoDaddy-hosted WordPress sites that we support, my antivirus software gave me a virus warning.  This happened, too, when the Network Solutions hack went down, so I became instantly suspicious.  (My virus software, by the way, is avast! which can be downloaded free for personal use.)

GoDaddy’s official initial response to the issue — which has been posted in a couple different places — was this:

A few of our customers were affected. Here’s what our CISO had to say about it:

“WordPress is a-ok. Go Daddy is rock solid. Neither were ‘hacked,’ as some have speculated.

After an extensive investigation, we can report there was a small group of customers negatively impacted. What happened? Those users had outdated versions of the popular blogging software, set up in a particular way.

This underscores the importance of installing the latest Web applications, no matter where you are on the Internet. If you use Hosting Connection, automatically update WordPress to version 2.9.2 using the simple 3-step update offered when you log-in.

And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure, and in a safe place.”

If you have questions or you’d like someone to take a look at your WordPress site, please get in touch with our 24/7 support team at


Here’s the problem with that statement: it’s wrong.  Both the sites that I saw directly were running the 2.9.2 version of WordPress.  And I’m not alone.  I’ve read reports in forums and blog comments from many users who were not only running up-to-date versions of WordPress, but also had secure and unique passwords for their WordPress backend, FTP and database, and many had countermeasures in place to prevent attacks on their WordPress site.  None of which protected them from being infected.  Later, GoDaddy’s Chief Information Security Officer sent out the following message which is currently appearing on their support page:

If you are experiencing difficulties with your site, you may be using outdated software and unknowingly hosting malware…And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure and in a safe place.

Calls to GoDaddy support about the issue right now are apparently being met with “this is a WordPress issue”-type responses.  But careful viewers of how this particular infection works will see that there isn’t anything specific to WordPress about it — it’s targeting php files on GoDaddy-hosted sites.  Whereas the Network Solutions hack was looking for a specific file — wp-config.php — to gain access to the database, php files can be in any software written in that language, which includes Joomla!, Drupal, ZenCart, Magento, and on and on.  Blaming the issue on bad security practices is a gross misrepresentation of the facts. As of this writing, GoDaddy hasn’t yet tracked down the source of the infiltration or taken much more responsibility for the issue than the above statements.

The good news is that, as far as I can tell, there isn’t anything you did wrong to make your site more of a target. The bad news is no one is sure how the hacker was able to access a huge number of sites on GoDaddy and append a javascript code at the bottom of every php file on those sites. The fact that GoDaddy’s canned response inaccurately suggests that the affected installations were outdated isn’t very reassuring.

Fear not, for there is a fix.  One thing the infected sites seem to have in common is that they are all hosted on Linux servers.  If your GoDaddy site is hosted on a Linux server, you can use the History feature to restore an earlier backup of the files. Since the database was untouched, this won’t affect any posts you may have published, however it may (or may not) affect any media files you uploaded between the time you restore back to and now — so it’s probably a good idea to check those posts for broken image links and the like after you do it to make sure everything is okay.  Check out this help file for full instructions on how to restore your site to an older backup.

Over the weekend, GoDaddy posted a fix to their forums that they referred to as a “permanent” fix. The updated fix involves backing up your database, saving any files you may have uploaded to your site, deleting everything, then reinstalling and restoring your database backup. While this would resolve the issue, until they announce that they know where these attacks are coming from and why they are so widespread, I can’t see this as a “permanent” fix — it’s not any more permanent than restoring from a backup (presuming that the virus wasn’t present at the time the restore point you are using was created).  And evidence suggests that security best practices wouldn’t safeguard your site against attack either.  That said, changing your passwords is probably not a bad idea.

I would like to reiterate that this is not a WordPress compromise, but a GoDaddy compromise. In this case, the sites that were reportedly vulnerable (those that were using a version of WordPress prior to 2.9.2) was inaccurate and given the nature of the attack, I don’t see what the WordPress version really has to do with anything anyway.  Even if we assume the attack only targeted WordPress, 2.9.2 addressed an issue in which users who were logged into the admin panel could look at Trashed posts from other authors. 2.9.1 resolved a number of minor bugs but no security holes. Neither of these would have prevented someone injecting malicious code into the php files of your WordPress installation. Until someone is able to expose the breach, I’m not convinced that any of the posted resolutions and prevention methods are “permanent” nor do I believe that this is the last we’ll see of this attack — from what I’ve been able to gather, many bloggers who fixed the problem last week were hit again this past weekend. (Not surprisingly, domain transfers from GoDaddy to another registrar quadrupled in the last week of April. This doesn’t necessarily mean hosting went with it, but I’d be surprised if the two things weren’t related.)

I don’t like to tell people that you shouldn’t use a certain webhost because of x, y and z. I will make recommendations based on my personal experience and suggest hosts that I’ve had good experiences with, but I’m not one to badmouth other companies to our clients or their decision to go (or stay) with that company. So I’m not going to tell you to switch to something else if you are using GoDaddy. However, if I was using GoDaddy, I’d be very concerned about my site’s security if it was running any kind of web application (blog or forum or CMS, WordPress or otherwise) until their Security team says something other than “make sure your passwords are secure.” What’s more, while Network Solutions was able to respond to, and secure the attack on their hosted WordPress sites within 24 hours (at least the initial attack, if not the subsequent attacks that came later), GoDaddy was hit with this, initially, sometime around April 21 or even much earlier.  I’ve seen no indication that they resolved the initial breach, let alone these new modifications.

If you have been compromised, or you are concerned about being compromised, I urge you to contact GoDaddy and express your concerns and try to learn what they are doing to prevent this attack from happening again. The more concerned customers they hear from, the more urgent the issue becomes and, hopefully, the faster they will work to resolve it.  However, if you would rather not be at risk just waiting for this weekend and the next wave of attacks, we highly recommend 1and1 for web hosting, and if you have questions or concerns about your site, you can contact us for a quote.  We can fix your infected WordPress site, help with your webhost transfer, or clean your infected php site that uses a different platform.

Tomorrow I will be posting an article about what you can do to keep your website as safe as possible.

If you would like to learn more about the issue, here are some of my sources:

Massive Number of GoDaddy WordPress Blogs Hacked [slashdot]
Warning! Massive Number of GoDaddy WordPress Blogs Hacked This Weekend [BlogcastFM]
GoDaddy/WordPress ninoplas Base64Virus and the Fix [inspirated]
GoDaddy WordPress blog hacked [WordPress Support Forums]
What people are saying about “GoDaddy WordPress” [Twitter Search]
GoDaddy Hacked WordPress Hosting Accounts [Smooth Blog]
WordPress on Hacked [NeoWin]
WordPress Compromised? How to Fix It! [GoDaddy]
GoDaddy Support [GoDaddy]
WordPress 2.9.2 [WordPress Development Blog]
WordPress 2.9.1 [WordPress Development Blog]
Restoring a Linux Hosting Account [GoDaddy]
GoDaddy Domains Lost by Transfer QUADRUPLE!! [NoDaddy]
Registrar Report for GoDaddy [WebHosting.Info]
Ninoplas Base64 WordPress Hacked on GoDaddy [WPSecurityLock] – WordPress Hacked [WPSecurityLock]
GoDaddy’s Mass WordPress Blogs Compromise Serving Scareware [Dancho Danchev’s Blog]
Breaking News!  Dangerous Malware Alert — Self-Hosted Sites on Major Hosting Service Hacked Again! [WPSecurityLock]
Details on the Network Solutions/WordPress Mass Hack [Sucuri Security]
The Kneber botnet – FAQ [ZDNet]



1 response to “GoDaddy-hosted sites at risk — WordPress, Joomla!, Pligg, ZenCart, others…”

  1. Ari johnson Avatar
    Ari johnson

    Thanks for the sharing such a alart news for us. I will also recommonded to other for do not go at godaddy to host thier website. Thanks you.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.