nginx 0day exploit for nginx + fastcgi PHP

Michael Shadle mike503 at
Fri May 21 21:28:16 MSD 2010

Question is, what functionality is lost by changing

cgi.fix_pathinfo = 0

Looks like the other workaround is something like this:

if ( $fastcgi_script_name ~ \..*\/.*php ) {
 return 403;

Which i basically saying what exactly? If there is a period and slash
somewhere prior to the last "filename" to return a 403?

Ideally while this is being thought out it would be cool to fix the
common "no input file specified" issue that a lot of people have -
have it return a 404 instead. Not sure if it's a simple php.ini change
(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?

On Fri, May 21, 2010 at 10:07 AM, Avleen Vig <avleen at> wrote:
> This is currently doing the rounds, so I thought it pertinent to post
> it here too.
> I don't know what nginx should do to fix this, but there are two
> workarounds given.
> If you allow file uploads (especially things like images) and use PHP
> FastCGI in the back end, you should take a loot at this now.
> The exploit allows for any arbitrary file which is uploaded, to be
> executed as PHP.
> _______________________________________________
> nginx mailing list
> nginx at

More information about the nginx mailing list