News for hackers. Stuff that matters.
Re:PHP-FPM remote code execution bug exploited in the wild by jstanley on Sunday October 27, 2019 @12:11PM (#21370607)
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?

Re:PHP-FPM remote code execution bug exploited in the wild by tomclancy on Sunday October 27, 2019 @12:45PM (#21370812)
>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.

Re:PHP-FPM remote code execution bug exploited in the wild by tyingq on Sunday October 27, 2019 @12:34PM (#21370729)
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.

Re:PHP-FPM remote code execution bug exploited in the wild by makomk on Sunday October 27, 2019 @01:01PM (#21370914)
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.)