nginx 0day exploit for nginx + fastcgi PHP

Igor Sysoev igor at
Fri May 21 22:11:35 MSD 2010

On Fri, May 21, 2010 at 10:48:19AM -0700, Michael Shadle wrote:

> On Fri, May 21, 2010 at 10:33 AM, Igor Sysoev <igor at> wrote:
> > I do not see why this is treated as nginx bug ?
> > Why is anyone able at all to upload images to /scripts directory ?
> It's not really a bug, like he said. However it is a configuration
> method that almost everyone uses for nginx.
> This is probably why "cgi-bin" was such a standard for so many years.
> "Only execute things in this directory!" but this gets around that due
> to the looser configuration most people have in nginx.

Well, why can not anynone upload index.php in /scripts directory ?
I do not see any difference between index.php and image.jpg.

> > Why does PHP have cgi.fix_pathinfo option ?
> I want to figure this out too. Once I can replicate this issue I'm
> going to disable it, see if it gets fixed, and then see if any other
> scripts are messed up by disabling that.
> from
> Provides real PATH_INFO/PATH_TRANSLATED support for CGI. PHP's
> previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and
> to not grok what PATH_INFO is. For more information on PATH_INFO, see
> the cgi specs. Setting this to 1 will cause PHP CGI to fix it's paths
> to conform to the spec. A setting of zero causes PHP to behave as
> before. Default is zero. You should fix your scripts to use
> I think lighttpd might not be touched because it doesn't use regex
> configurations to pass things to the PHP interpreter as "trusted" code
> to execute. It determines the real file internally and then parses the
> extension (is how I would think it works)

But what if lighty and fastcgi server are on different hosts ?

Igor Sysoev

More information about the nginx mailing list