I don't think a lot of well-maintained websites still use the CGI option. Even without this vulnerability, it's a bad idea to run that configuration (as every single request starts a complete PHP process, compiles all the script files, runs them and then shuts down again). It's just incredibly wasteful, comparative to starting and terminating e.g. a complete servlet container with every request. PHP-FPM is now being bundled inside the standard PHP distro, there is really no valid reason to use plain old CGI.
If you use mod_php, every customer's code runs as the apache user, which is bad for security. If you use PHP-FPM, you end up needing at least one long-running process per user, which wastes resources.
You're right, I hadn't thought of that. The only shared hosting environment I use at the moment is mediaTemple's Grid Service, and it looks to me like they are configured for FastCGI regardless.
Comments
I don't think a lot of well-maintained websites still use the CGI option. Even without this vulnerability, it's a bad idea to run that configuration (as every single request starts a complete PHP process, compiles all the script files, runs them and then shuts down again). It's just incredibly wasteful, comparative to starting and terminating e.g. a complete servlet container with every request. PHP-FPM is now being bundled inside the standard PHP distro, there is really no valid reason to use plain old CGI.
Shared hosting.
If you use mod_php, every customer's code runs as the apache user, which is bad for security. If you use PHP-FPM, you end up needing at least one long-running process per user, which wastes resources.
You're right, I hadn't thought of that. The only shared hosting environment I use at the moment is mediaTemple's Grid Service, and it looks to me like they are configured for FastCGI regardless.