La vulnerabilidad HTTPoxy, cuyo nombre no tiene un significado especial, llamó la atención por primera vez en marzo de 2001. El programador Randal L. Schwartz la descubrió en la biblioteca libwww-perl del lenguaje de programación Perl y así se lo transmitió a Gisle Aas, el desarrollador de dicha biblioteca. Este solucionó la brecha de seguridad inmediatamente en la actualización 5.51, mientras que los nombres de las variables a través de los que se controla la configuración del proxy se modificaron en CGI_HTTP_PROXY. Durante el mismo año también salió a la luz la vulnerabilidad en el programa de transferencia de datos curl, con lo que el desarrollador Daniel Stenberg adaptó el software, de modo que en lo sucesivo solo afectara a las variantes http_proxy escritas en minúscula para la determinación del servidor proxy —destacando al mismo tiempo que, en general, esto no es suficiente para los sistemas Microsoft, aunque las versiones actuales de Windows ya no presentarían este problema.
Alrededor de una década después, en julio de 2012, el equipo de Ruby se topó con la problemática HTTPoxy ya olvidada durante la implementación de la clase NET::HTTP, una API para los clientes HTTP diseñada para las aplicaciones hechas con Ruby. Para evitar el problema, se retira al HTTP_PROXY su estatus de variable estándar. En los años siguientes, las aplicaciones de servidor web NGINX (2013) y Apache (2015) formaron parte de los casos más famosos en los que los usuarios más perspicaces informaron a los desarrolladores de los posibles riesgos.
En 2016, el equipo de seguridad de la empresa de desarrolladores Vend puso de manifiesto que la vulnerabilidad HTTPoxy, aun 15 años después de que saliera a la luz, todavía constituía un riesgo para PHP y otros lenguajes de programación, así como en bibliotecas, siempre y cuando esta se usara en combinación con CGI o con un entorno en tiempo de ejecución equiparable con variables configurables. Muchas aplicaciones afectadas que permiten la utilización de HTTPoxy fueron clasificadas como especificaciones oficiales para las brechas de seguridad, lo que se conoce como CVE (Common Vulnerabilities and Exposures o, en español, exposiciones y vulnerabilidades comunes):
- 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