Security Alert: WordPress Timthumb Hacker on the Prowl

As most WordPress bloggers and site owners and administrators will already be aware, the TimThumb script that is popularly used for resizing images to create thumbnails for WordPress themes and plugins has a security vulnerability that allows hackers an easy ride into websites.

The vulnerability was made public at the beginning of August and was patched almost as soon as it was announced. However, I’ve noticed a increasing number of crawls of sites I manage by scripts looking for themes and plugins that use timthumb.php. These crawls produce 404 error reports in both the plugins SEO Ultimate and Redirection because the files the bot’s hunting for do not exist on my servers. In every case, the crawler scanned the directory /wp-content/themes/ and /wp-content/plugins.

10th Nov. 2011: Please see Bootnote for the best solution.

Scanned Themes and Directories

It looks like the bots are aimlessly scanning for any theme or plugin that might contain timthumb.php (or its alias, thumb.php).

The first scans hit the following directories:

IP’s To Block

Place the following Apache directive into the .htaccess file in your server’s root directory. It tells your server to deny requests emanating from the stated IP addresses (updated 20th Oct. 2011):

The following IP addresses have been removed from the above list in response to host and webmaster replies to my alerting them that their servers have been hacked.

Security Recommendations

Delete any themes and plugins that you no longer use and keep WordPress, all installed themes and all installed plugins up-to-date.

There is a plugin available to scan your WordPress wp-content directory for unpatched versions of TimThumb. Grab it from

Block public access to timthumb.php (and thumb.php) with an .htaccess FilesMatch directive. Copy and paste this line into your topmost .htaccess file:

The caret, ^, tells Apache to look for requests to view files that “start with…”, the parentheses, (), tell Apache to expect a list of files in the directive, the backslash before every full-stop tells Apache to treat the full-stop as a literal character (as opposed to a representation of any character), and the pipe, |, is used to separate list items with an “OR” preposition.

The above instruction tells Apache to block any request to view wp-config.php, install.php, php.ini, readme.html,bb-config.php, .htaccess, readme.txt, timthumb.php, thumb.php, error_log and error.log.

Using the above snippet in .htaccess  will prevent anyone but Apache (and anyone running as the Apache user/usergroup) from viewing any of the stated files. This means bots can’t view them, surfers can’t use them and you may only view them while logged into your server and using its own file browser or an FTP program.

Once added, you will notice that most attempts to find timthumb.php will cease after the first occurrence because of the “You do not have permission to view this file” or “Forbidden” message that Apache displays.


I found a better solution to blocking IP addresses and bad hosts.

.htaccess rewrite rules can be used to block many RFI, XSS and SQL Injection attacks.

Read WordPress Security Hardening Tips here.

What Next?

When possible, I contact website owners and their hosts (if the site owner fails to respond) to alert them to malicious scripts on their servers. Maybe you could do similar to help free the Net of malicious bots.

Suggestions for removing and updating TimThumb are given at WP Service Masters.

If do think you’ve been hacked then you should backup and download your wp-content directory, any files and directories you’ve created, and your database before deleting everything and re-installing WordPress. A good guide to this is found at WP Service Masters.


  1. says

    Thanks a ton! A client just notified me that their WP site had been hacked.

    The first thing I did was add the blocked IP addresses and access to timthumb within htaccess.

    And…instantly the malicious links that were showing within their site DISAPPEARED!

    I’ll keep investigating to see if I really need to reinstall WP or do some other damage control, but this post has already really helped me.


    • says

      As well as installing files on hacked servers, the hackers have been adding code to timthumb.php, wp-config.php, .htaccess, other WordPress core files, the index.php file of different themes… hence my recommendation to reinstall WordPress or, at minimum, its core files (via an update), all themes and all plugins.

      There is another option to reinstalling everything. Use the free site scanner provided by Sucuri. It’ll give you an idea of where any malicious scripts reside (that is my affiliate link).

      Jeff, I’m glad I helped. I update the block list daily so keep watch for new IPs being added.

  2. says

    It would be nice if we could use add_image_size in the same fashion, but that only impacts images uploaded after the fact… with the dynamic resizing we can set the sizes at any time….

    • says

      Scan the contents of scripts on the server for known malicious code (I use Securi to monitor specific domains), reinstall applications then check modification timestamps of all files and manually read any file with an older timestamp than the freshly installed ones because older ones might not be files you put there. Also check for suspicious processes and traffic. A good list of network monitoring tools can be found at

      pktstat shows the contents of GET and POST requests, Wireshark will do that and much, much more. pkstat is a command line program, Wireshark is graphical.

      Here’s an affiliate link to Securi.

    • says

      I’ve managed to block remote file insertion attempts with my .htaccess file so I’m no longer able to collect additional domains for this particular blocklist.

      The rewrite rule to to your .htaccess firewall blocks all query strings containing “src=”.

      Put something like this in your .htaccess file and you’ll not be far wrong (read the instructions too):
      RewriteBase /
      # white-list remote requests from your own host (none should be possible but...)
      # change the numbers in to those of your server's IP address
      RewriteCond %{REMOTE_ADDR} !^$
      # Add hosts you're willing to allow to make requests containing "src=" in them, e.g Disqus
      RewriteCond %{REMOTE_HOST} !$
      # block non white-listed hosts from making requests containing "src="
      RewriteCond %{QUERY_STRING} ^.*src=.*$ [NC,OR]
      RewriteCond %{THE_REQUEST} ^.*src=.*$ [NC]
      # Give bad request makers the finger
      RewriteRule .* index.php [F,L]

      Watch for side effects such as plugins not being able to update or login redirections not functioning properly. You can fix side effects by white-listing specific requests. The above will work for most sites, WordPress or not. Place the code in your site’s root .htaccess file and put it above any other rewrite rules to ensure they’re processed first.

  3. says

    Here’s another IP for the list:
    WordPress Timthumb Exploit Activity was seen today (1/13/12 5:12 AM) from this IP
    Thanks for sharing the IP list, suggested scripts and information

  4. Daniël Mostertman says

    You can remove the entry. It was one of our Shared Webhosting customers, and it’s cleaned up (a long time ago already).

  5. Daniël Mostertman says

    Thanks :) Just wondering, is it necessary to be able to access timthumb.php directly? Or could we just redirect all timthumb.php requests to a 404 page? It’s kind of a unique name so it shouldn’t do much harm in that case (when disabling it server-wide).

Leave a Reply