Hacker News Reader

The exploit requires

> fastcgi_split_path_info ^(.+?\.php)(/.*)$;

If I'm not using this feature of PHP, what can I put in this config value to prevent the exploit from working?

>There must be a PATH_INFO variable assignment via statement fastcgi_param PATH_INFO $fastcgi_path_info;. At first, we thought it is always present in the fastcgi_params file, but it's not true.

This is also precondition, and fortunately it's not included in standard fastcgi_params files.

I don't think you can fix it there, because you probably need stuff like /foo.php?key=value to work. (Edit: not quite...see comment below)

The try_files config mentioned on the page mitigates the issue.

I don't think this line is required to make foo.php?key=value to work, because the query parameters aren't treated as part of the path. It's for URLs like foo.php/bar where you have some path after the PHP file that's passed to the script - this was supported out the box by Apache mod_php and there's a fair amount of code out there that relies on it. (Generally because cleaner methods of feeding a set of paths to one PHP script require server configuration that may not be available on cheap shared web hosting.)

Reply on news.ycombinator.com