Httpoxy vulnerability hits PHP installs using FastCGI with PHP-FPM, HHVM
Essentially an attacker could use this to send outbound traffic through their own proxy servers, which will essentially give them control over what is sent back to the server and possibly to the requesting client as well. PHP itself is not vulnerable, but libraries or applications that use HTTP to communicate to third parties can be.
The problem seems to have been known for years and has surfaced occasionally, but now popular PHP libraries such a Guzzle are found vulnerable, but only in environments that use a CGI based environment, where HTTP headers are automatically transformed into CGI environment variables.
It works so that the PHP process (PHP-FPM or HHVM) receives a request through the CGI backend and those HTTP headers are then mapped into environment variables automatically. These variables are prefixed with HTTP_.
So a header sent as Host: example.com is transformed into an environment variable HTTP_HOST=example.com. As any request can send any headers it wants, no environment variable with the prefix HTTP_ should be trusted.
However the use of the actual HTTP_PROXY environment variable is widely used to check if a proxy should be used when doing outgoing requests. So by simply sending a "proxy" header through a HTTP request will allow external users to control where outbound HTTP traffic from vulnerable libraries the server will be directed to.
The easiest way of mitigating the risk is to filer out the incoming proxy headers sent in HTTP requests. Updates to libraries like Guzzle have already been done to make them immune to the attack, but a web application firewall would work fine as well.
A universal filter for the proxy-header on the HTTP layer (Proxy, HTTP server) is the easiest and most universal way if you've got plenty of PHP applications.
How httpoxy vulnerability could be exploited
Even if you visit a website that fetches parts of the content via a HTTP API on a vulnerable machine, this does not make you directly vulnerable to attacks.
The Httpoxy exploit does not give the attacker direct access to your browser, but enables the attacker to possibly modify how the server runs.
Instead the attacker can make a request to the web server which will make a request to another service. With the exploit the attacker making the request can direct the outgoing request to a server they control.
Instead of receiving the expected data the server receives, the request can direct the feed to be received from the attackers server. At a minimum the results might be cosmetic, but having this kind of access can have significal implications as HTTP APIs are now used frequently for all sorts of activities on the web.
The attacker might gain access tokens to the legitimate endpoints directly and it's worth noting that the server applications are likely to have been built so that they consider the API endpoint trustworthy. So while the attacker may have limited exposure to the system via this method directly, it can likely be further exploited with XSS and data injection.
There are likely many ways that this vulnerability can be exploited. More details on the vulnerability on the site: httpoxy.org