Request Smuggling Via HTTP/2 - Is Phoenix Vulnerable?

The revival of HTTP request smuggling has led to devastating vulnerabilities in our modern application deployments. An HTTP request smuggled past the validation of an edge server can lead to serious consequences, including forged internal headers, access to internal management endpoints, and a variety of opportunities for privilege escalation.

HTTP/2 (or HTTP/3) is a promising solution to the issues we’ve faced with request smuggling, but support for HTTP/1.1 isn’t going away anytime soon. In the meantime, we’re still in for more surprises from our good friend HTTP/1.1.

In this post, I demonstrate how upgrading HTTP/1.1 connections to lesser-known HTTP/2 over cleartext (h2c) connections can allow a bypass of reverse proxy access controls, and lead to long-lived, unrestricted HTTP traffic directly to back-end servers.


Is phoenix vulnerable when used to directly serve requests to the internet?

How can we mitigate the risk when behind one of the vulnerable proxies?

1 Like

why should an edge proxy also handle access controls?

IMHO edge proxy should just do caching and load balancing.

Nowadays Its a common practice to do that at the edge, especially in enterprise systems.

Nginx has moved along time ago to be more then caching and load balancing:

You now also have API Gateways, they are a more elaborated version of what used to be a proxy for caching and/or load balancing.

1 Like