nginx 0day exploit for nginx + fastcgi PHP

Michael Shadle mike503 at
Thu Jan 27 07:13:44 MSK 2011

it's not a vulnerability with nginx, it's a widespread configuration
misstep teamed up with what I consider to be somewhat lazy application
code (it should check filetype and/or convert and normalize it to site
specifications and/or strip extra stuff inside of it ...)

there's a couple different ways to address it with nginx
configuration, and there is a way to address it in application code

doesn't this fix basically say "if there is a period in the path
before the path ends with PHP throw a 403" - because then
/ would be denied, right?

location ~ \..*/.*\.php$ {
   return 403;

On Wed, Jan 26, 2011 at 8:07 PM, gdork <nginx-forum at> wrote:
> 40 of my servers were compromised because of this issue and I just found
> out about it...aarrrghhhh.
> There are php cmd shell trojans everywhere now!
> I was able to easily replicate this issue, and the cgi.fix_pathinfo=0
> fix did NOT work on my systems.
> Adding:
> location ~ \..*/.*\.php$ {
> return 403;
> }
> Did solve the issue however.
> It is VERY common for image hosting sites to allow file uploads to the
> web directory.
> Any can upload a php file as an image and immediately execute it.
> nginx should NOT allow the fastcgi backend to execute code in a file
> that does not even exist.
> /blah/blah/virusimage.jpg/hello.php should never execute the hidden php
> code inside the file virusimage.jpg
> I wonder how many sites have been trojaned because of this.  Ive been
> searching vulnerability databases for days and never came across this
> nginx issue. :(
> Posted at Nginx Forum:,88845,169953#msg-169953
> _______________________________________________
> nginx mailing list
> nginx at

More information about the nginx mailing list