While going through web logs I noticed some unexpected HTTP 500 errors where I would expect to see 404s. The requests are trying to access /cgi-bin/php* variants, but I’m also seeing calls to nonexistent *.php files returning 500 errors. This is on an IIS 7 server default site that currently isn’t supposed to be running any dynamic code.

HTTPoxy is a thing I hadn’t heard of, but it may be relevant to this. It’s been around for years, apparently, but an exploit in the wild was discovered in July 2016.

I have both IIS and nginx servers using PHP via fastcgi. If I understand correctly it isn’t the implemntation that’s vulnerable but apps or libaries that might use an http_proxy environment variable to fetch data on the server side. Due to the way httpd servers pass environment variables to cgi and fastcgi apps, “proxy” could become “HTTP_PROXY” and cause the server app to direct requests through an attacker’s proxy compromising data.

I’m not sure how this could cause 500 errors for nonexistent scripts, so maybe this isn’t my issue. I might have to go “nuking it from orbit is the only way to be sure” and redploy my websites on a new server. I was planning to Dockerize all my sites, anyway.

In summary, I think the log entries I identified are likely attempts to attack HTTPoxy, and I don’t like the way the server is responding.

Offhand I can’t think of any requests my dynamic sites make at all, and I can’t think of any data that could be compromised if they did, but I’ll keep investigating.

Some links:


  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
  • CVE-2016-6287: CHICKEN’s http-client
  • CVE-2016-1000104: mod_fcgi
  • CVE-2016-1000105: Nginx cgi script
  • CVE-2016-1000107: Erlang inets
  • CVE-2016-1000108: YAWS
  • CVE-2016-1000109: HHVM FastCGI
  • CVE-2016-1000110: Python CGIHandler
  • CVE-2016-1000111: Python Twisted
  • CVE-2016-1000212: lighttpd

Update: My problem wasn’t this at all. It was an old config that was intended to return 503 error pages instead of 404 back when I was fixing a number of downed sites. The config was wrong, so when it encountered a 404 it logged the 404 on the back end server but returned a 500 due to my bad error handling.