Recovering from the dreaded "eval(gzinflate(base64_decode" attack

So you're running a WordPress site and one day you realize that your search engine traffic is trailing off. You have no idea why, but you start looking into the reason and you see that Google is littered with spam results dealing with your site and pharma terms like Viagra and Cialis. That prompts you to look at some of your .php files and you notice that there is a really odd line at the beginning of some (or all) of the files that looks like
<?php eval(gzinflate(base64_decode('........

Why can't I see any problems on my site because of this attack?

Most of the time with website attacks you can see some problem on your site, but this one is different because it will only show up if a search engine spider is viewing the site, meaning that your site can be infected for months or years before you ever find out. That's what makes it so effective, and why it's becoming so prevalent.

What is the point of the attack?

All the attacker is trying to do is take search engine rankings and goodwill that you've earned, and redirect it to their site. They want their sites to rank higher through the link juice that your site is sending them, without you ever knowing. The end result is that search engines will start thinking your site is spamming users, and stop ranking your site for keywords that you used to rank for. It can kill sites.

I see that my site has these modified files, but it doesn't look like my search engine rankings are affected?

This is where it pays to host with Buyhttp. We block the exec function at the server level on shared servers and by default on all managed dedicated servers, so no script can run it. This means the harmful code will never work on your site. What it will do is cause an error to show on your site, so it's very obvious that the attack has happened. We also run software on all shared servers that monitors file changes in real time and should block the attack from happening in the first place. But there is always a chance of failure there.

Now what? I need my site cleaned up and don't know all of the files that are affected?

If you have a dedicated, VPS, or cloud server, login to SSH, go to your public_html folder and run the following command
find . -type f -print0 | xargs -0 grep -l "eval(gzinflate(base64_decode"

That will print a list of every file on the site with the injected code.

If you have a shared account then you will not have SSh access. Just let us know and we can get you the list of files. 

The list of files can be very long, and cleaning out every one manually can take a long time. Cleaning the files should be your last resort. Ideally you should be deleting all files on the account and restoring a known-clean backup. On our business accounts we take backups every 6 hours and store 30 recovery points going back 6 months, so you have a lot of options. On unlimited accounts we take backups three times a week, and keep daily, weekly, and monthly backups. Servers, VPS, and cloud all have their own backup configurations. You can contact us if you have questions about backup availability.

If a clean backup doesn't exist, cleaning out your files is a pretty easy task. There is a great script release by Jerry Travis that automates the entire process. Go to his site and download the script. There are full insructions for it's use there, but the main parts are:

  • Take a full backup of your public_html folder
  • Download the script and extract it on your computer
  • Upload the clean.php and fullInfected.txt files to your public_html folder
  • Modify the fullInfected.txt file with the list of infected files you found earlier
  • Modify line 5 of clean.php to read $findWhat = 'eval(gzinflate(base64_decode';
  • Go to
That should result in your site having no more infected files.

Keeping the code from coming back

This code has a tricky way of coming back. We've seen it back on an infected site within a few minutes of removing it. The attackers tend to hide a backdoor in the database. You will want to download full backup of your database and do a search for the terms "viagra" and "argaiv". Yes, they are tricky enough to put the text in backwards to prevent it being found. If you get any hits, remove those entries from your database with phpMyAdmin.

This is one of the more annoying hacks to deal with, but armed with this information it shouldn't take too long to get your site back online.
  • 18 Users Found This Useful
Was this answer helpful?

Related Articles

How to change the admin color scheme in WordPress 3.8

We're big fans of the new admin layout in WordPress 3.8. One complaint we've seen going around...

How do I have WordPress update plugins and themes automatically?

WordPress will automatically apply minor release updates to your site, so you can be sure...

Displaying the most recent posts from a single category in WordPress

Have you ever seen a site that showed the most recent post or posts from a single category? If...

How do I disable automatic updating in WordPress?

One of the many features added to WordPress in 3.7 was automatically updating for minor releases....

Deleting post revisions from the WordPress database

One of the great features the WordPress added in was post revisions. Any changes made to posts...