Skip to content

How to fix HTTPoxy vulnerability in cPanel, Plesk or other Linux / Windows servers

On 18th July, our security team was alerted to a series of vulnerabilities called HTTPoxy. It allows attackers to steal data from CGI enabled web servers.

As of this writing, patches only available for Litespeed, but we’ve identified ways to mitigate this vulnerability in Apache, Nginx, IIS and other web servers and proxies.

[ Update 21st July – cPanel released patches for Apache. Click here to know more ]

What is HTTPoxy?

HTTPoxy is a vulnerability with CGI environments, that allows an attacker to re-direct web traffic through an arbitrary proxy server. Here’s how it works:

Some web applications open outgoing HTTP connections, like fetching periodic weather data, posting data updates, etc. These connections are usually opened directly to the target servers.

However, a setting (aka variable) called “HTTP_PROXY” can be used to channel all outbound connections through a specific server. The HTTPoxy vulnerability allows attackers to remotely modify this setting to direct all traffic through a malicious proxy server.

how to fix HTTPoxy - How it works

The malicious proxy server can be used to gather sensitive data, or pass malware into the external servers after authentication.

Are your servers vulnerable?

To test if your servers are vulnerable, create a file called test.cgi in the “cgi-bin” directory of any domain. Put the following content in it, and give it 755 permissions, and the right ownership.

echo "Content-Type:text/plain"
echo ""

Then access the script with a “Proxy:” header, like this:

curl -H ‘Proxy: AFFECTED’ http://your-domain-name-here/cgi-bin/test.cgi

If you see the output HTTP_PROXY=’AFFECTED’ then your server is vulnerable.

Is there an easier way to know?

A lot of web servers allow CGI applications with HTTP_PROXY headers. For eg. if you have a LAMP stack, chances are you’d be using Mod_PHP or PHP-FPM in its default config, which is to allow this header.

So, the rule of thumb is, if your server is CGI enabled, and is a default installation, consider your server vulnerable.

This is especially true if you are a web hosting provider. Control panels like cPanel/WHM, Plesk, DirectAdmin, etc. allow you to run PHP apps in CGI mode.

How to fix HTTPoxy in cPanel/WHM Linux servers

cPanel/WHM runs on CentOSRedHat and CloudLinux servers. While it supports Apache by default, we’ve seen many installations with Nginx and Litespeed web servers.

Here’s what you can do to mitigate the vulnerability in these servers.


cPanel is due to release a patch for Apache (CVE-2016-5387) today (July 20th). [ Update Jul 21st – This patch is now available. ]

So, first do an EasyApache update by going to WHM >> Home >> Software >> EasyApache 3 (or 4)

How to fix HTTPoxy - EasyApache

If you are using EasyApache 3, its version should be changed to 3.34.2. If you are using EasyApache 4, the following command should give you an output (not blank).

# rpm -q --changelog ea-apache24 | grep CVE-2016-5387

If the above tests failed, you need to disable the HTTP_PROXY variable in CGI environments. You can do it by adding the following lines in /usr/local/apache/conf/httpd.conf

<IfModule headers_module>
 RequestHeader unset Proxy early

Then commit your changes with:

# /usr/local/cpanel/bin/apache_conf_distiller --update
# /scripts/rebuildhttpdconf
# service httpd restart


There are no official patches from cPanel for Nginx. So, you need to disable the HTTP_PROXY parameter by adding the following entry to http or server configuration contexts:

fastcgi_param HTTP_PROXY "";


Litespeed has already released a patch for this bug. So, just update your Litespeed to LSWS 5.1.7 or LSWS 5.0.19.

Mitigation with ModSecurity

If you use the mod_security Web Application Firewall, add the following rule to block any incoming connection with the “Proxy” header set.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Note: Use it with caution, as it could break functionalities of legitimate applications.

Fixing HTTPoxy in Plesk

Plesk runs on CentOS, RedHat, CloudLinuxDebian, Ubuntu and Windows servers. There are no patches available from Plesk yet.

So, in the Plesk servers of customers, we’ve mitigated this issue by disabling the HTTP_PROXY header.

Here’s how:


In Plesk, Apache configuration files are stored in a hierarchy. So, you’ll need to create a new sub-configuration file to disable HTTP_PROXY.

Create a new file called /etc/httpd/conf.d/disable_httpoxy.conf, and enter these lines:

<IfModule headers_module>
 RequestHeader unset Proxy early

Then restart your server:

# service httpd restart


In Nginx, the HTTP_PROXY parameter can be reset for the whole server by adding it in the “http context“.

Add these lines within the “http {” section of /etc/nginx/nginx.conf.

fastcgi_param HTTP_PROXY "";

In Ubuntu or Debian servers, a separate configuration file is available for FastCGI directives. It’ll be either at /etc/nginx/fastcgi_params or /etc/nginx/fastcgi.conf.

If so, enter the above configuration entries into that file, and restart Nginx.

Note : Nginx configuration are over-ridden in the context order Global –> Http –> Server –> If — Location. So, make sure your entry is not over-ridden in any subsequent context.

Mitigation using ModSecurity

Many Plesk servers use mod_security as a Web Application Firewall. The following ModSec rule blocks any connection with a “Proxy” header:

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Note: Use it with caution, as it could break functionalities of legitimate applications.

How to fix HTTPoxy in Windows / IIS

Microsoft web frameworks such as ASP is not vulnerable to HTTPoxy. But many web hosting control panels such as Plesk installs PHP or other CGI enabled frameworks in Windows servers.

So, if you have any such 3rd party frameworks, the recommended solution is to block incoming connections with the “Proxy:” header. You can do it by running the command:

appcmd set config /section:requestfiltering /+requestlimits.headerLimits.[header='proxy',sizelimit='0']

Alternatively, you can remove the contents of HTTP_PROXY using URL ReWrite. Just add the following re-write code:

    <rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
     <match url="*.*" />
       <set name="HTTP_PROXY" value="" />
     <action type="None" />


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
Shield Security