There is a website which takes the user image as the input and processes it and then store it in some directory. I can't see the directory, all i can see in the src attribute of img tag is the name of the php file which is rendering that image.

<img src="rendering-image.php">

Furthermore after uploading image, the website shows the image on the webpage and when I type www.site.com/rendering-image.php. It gives me all the raw data of image (not the displayable image). I inserted some PHP code in between the raw data so that I can manipulate the filters, but it's not working. The PHP code I entered for testing was

<?php $n3=2+2; echo $n3;?>

After inserting it in the raw data of image, my jpg image raw data looked something like this

        ÿØÿà JFIFHHÿápExifMM*;nÒ‡iæ<?php 
$n3=2+2; echo $n3;?>¢£–hàŒÉ4‰/VvÀ‰®sQñ•¬ ­Œfå¿ç¡;#Sø...

I was expecting some answer as the result of PHP execution but I didn't get any answer.

So what's actually happening here? Is there any vulnerability here? If it is then how can I exploit it?

  • No vulnerability. The code is taken as data and not as code. Commented Aug 9, 2016 at 11:42

4 Answers 4


There could be any vulnerability anywhere, but there is no evidence of one here. Here is what happens:

  • you browser sends a request for a page to a server
  • the server sends an HTML page containing a reference for an image ()
  • the browser analyses the HTML page (eventually begins to display it) and sees that it needs to ask for an image at URL original_page_URL/rendering-image.php
  • the browser sends a new request at that URL, problably saying that it wants an image
  • the server sends back the data of the image and declares in the HTTP headers the type of the image
  • the browser expects an image, reads the response, finds the type of the image, gets its data and displays it

The problem when you directly write the URL in your browser, is that browsers often use the extension part to guess the type of the response, and here it wrongly guesses that php should return text. But other things could happen here:

  • as the browser has no idea of what is rendering-image.php, it could declare that it want text/html data
  • the server obeys and declare to also send text, but still sends the image data

You should use a tool like wireshark to get the headers of the request and response to know exactly what has happened.


A vulnerability could exist if you wish to attack the server hosting rendering-image.php. Usually this consists of finding a vulnerability in ImageMagick or GD and exploiting it. Those are the two most common image processing libraries for PHP.

They could also attack the script itself. There was a pretty big attack a few years ago involving timthumb.php. TimThumb is a drop in script that does image manipulation. Many web developers including lots of WordPress theme developers used this. The vulnerability allowed remote command execution against the web server.

Why this is of no concern for a client side attack is how it is used in the HTML markup.

If the web developer coded the following an attacker could exploit the script to return information and modify the markup to send to the client:

<img src="<?php include('processing-image.php') ?>">

Which could of be exploited to return the following:

echo "\"><script>alert('attack poc');<script/><\"";

And this would be rendered as:

<img src=""><script>alert('attack poc');<script/><"">

However the markup is actually:

<img src="processing-image.php">

So the information is going to be treated as image data and attempt to render it instead of change the contents of the page. With this said they might be able to malform the image where they could attack the rendering engine of the browser. But it is a highly unlikely and difficult thing to attack.

  • And how can <img src="<?php include('processing-image.php') ?>"> be converted into <img src=""><script>alert('attack poc');<script/><""> ? Commented Aug 9, 2016 at 22:53
  • @FarrukhMehmood It is theoretical situation that if a vulnerability did exist they could possibly modify the output to malform the HTML markup. This is only possible if they called this with include(), require(), or similar though. This processes the PHP on the page opposed to getting the results of another post-process PHP page.
    – Bacon Brad
    Commented Aug 9, 2016 at 23:00
  • @FarrukhMehmood To further clarify the PHP script would basically be exploited to execute echo "\"><script>alert('attack poc');<script/><\"";.
    – Bacon Brad
    Commented Aug 9, 2016 at 23:22

Certainly, there could be vulnerabilities in the image processing code. For example, there were recently a few serious vulnerabilities in ImageMagick, a popular image processing library. One of those vulnerabilities could lead to remote code execution (RCE), which is as bad as it gets severity wise.


Instead of injecting PHP code into the raw data of the image, try injecting some javascript so that instead of

    ÿØÿà JFIFHHÿápExifMM*;nÒ‡iæ<?php 
    $n3=2+2; echo $n3;?>¢£–hàŒÉ4‰/VvÀ‰®sQñ•¬ ­Œfå¿ç¡;#Sø...

it comes out as

    ÿØÿà JFIFHHÿápExifMM*;nÒ‡iæ"><script>prompt('password please') 
    </script>¢£–hàŒÉ4‰/VvÀ‰®sQñ•¬ ­Œfå¿ç¡;#Sø...

If the Javascript executes, I would call that a vulnerability.

  • javascript is not working also. Commented Aug 9, 2016 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .