I just tested the vulnerability on one of my websites and successfully managed to get the source of my index.php.<p>However, I then also tried to run remote code execution and couldn't. The only differences to my stack is that it's running Nginx and hops accross a few proxies (nginx -> varnish -> nginx (for SSL and SSI)) in between. I'm not sure why I can't run -d or -n, but any other options seems to always return the source.<p>Anyone else running nginx in fastcgi noticing similar? It seems like it's vulernable to the source download, however not remote execution. I'm about to work on a rewrite rule now just in case.<p>(Not sure why it's vulnerable to the source download, as comment below says, it's set up to not be vulnerable?)<p>Edit: Not sure what part of my comment deserved the down vote. I trust that what you say is true, in that fastcgi is <i>explicitly set up to negate this vulnerability</i>, but the truth remains that I am experiencing it. If anything I'd have wanted to reach out to other nginx users...<p>The only way I could ever show that fastcgi under nginx is vulnerable, would be by linking to my live vulnerable server running nginx.. and the wiseman inside of me knows that to be a bad idea! Ha.
"FB playing with the vulnerability" - <a href="https://facebook.com/?-s" rel="nofollow">https://facebook.com/?-s</a><p>They really do have a sense of humour...
Did anyone find any interesting sites with this vulnerability? I found a Chinese exchange program and an 'ask Army' *.mil site that has since been patched.
"In the wild" in this case was just their honeypots. Actually vulnerable site should be very rare.<p>Also, one would assume that any website still using php-cgi has plenty of other security vulnerabilities.
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.
I feel this needs to be stressed again: FastCGI implementations are NOT vulnerable to this bug.<p>I myself run LigHTTPD and PHP through FastCGI, and this was worrying me a lot, until someone pointed me to the Eindbazen site which stated this.<p>(BTW: Eindbazen is Dutch for "Final boss" in a video game context.)