When reverse proxies translate HTTP/2 traffic to HTTP/1.1 for backend servers, they can generate malformed requests that bypass intended access controls. Researchers examining popular proxy implementations found that specific pseudo-header handling during protocol conversion creates paths for reaching internal systems. The flaws exploit the boundary between how HTTP/2 structures requests differently from HTTP/1.1 and how proxies reconstruct those requests for downstream servers.
What the Research Found
Modern web applications frequently use HTTP/2 between browsers and reverse proxies, then convert to HTTP/1.1 for backend communication. This translation step assumes incoming pseudo-header values conform to expectations—assumptions that three major proxy tools failed to enforce.
| Proxy | Affected Pseudo-header | Attack Outcome |
|---|---|---|
| Envoy Proxy | :method | Arbitrary request line content, internal host access |
| HAProxy | :scheme | Request line injection, virtual host routing bypass |
| Gunicorn | Protocol version field | Alternative path to internal routing manipulation |
Envoy Proxy** accepted arbitrary strings in the :method pseudo-header. By supplying a value like "GET http://victim-internal/secret/path?" with :path set to "/", Envoy would route normally on its side but embed the full arbitrary string into the backend request line when constructing the HTTP/1.1 request. The result could point to an internal host that should have been unreachable.
HAProxy** allowed unexpected values in the :scheme pseudo-header. Specifying a non-http/https scheme would be written directly into the backend request line, enabling similar routing manipulation.
Gunicorn** permitted arbitrary protocol version fields, providing another avenue for the same class of attack.
These behaviors enable reaching arbitrary virtual hosts behind the proxy, bypassing access control rules enforced at the proxy layer, and launching server-side request forgery attacks against internal services.
Why This Matters
The findings challenge a common architectural assumption: that reverse proxies enforce hostname-based access restrictions reliably. For teams using proxies to segment internal services from external traffic, these translation flaws expose a gap in that isolation model.
Security teams should treat protocol translation boundaries as untrusted inputs. Relying solely on the reverse proxy as an access control checkpoint creates exposure when translation logic fails. Developers building integrations that assume proxy-level isolation need to add defense-in-depth at the application layer.
From a scanning perspective, this research demonstrates that automated detection of these patterns is now feasible. Security tools that include specific checks for HTTP/2 translation vulnerabilities make configuration validation straightforward for teams with CI/CD pipelines or regular assessment schedules.
The practical implication: these are not code execution flaws but implementation deviations from expected protocol translation behavior. They can persist without obvious signs of compromise, making proactive scanning essential rather than waiting for anomalous logs.
Who Should Care
Security teams:** Add HTTP/2 translation checks to your scanning cadence. Evaluate whether your proxy configuration permits arbitrary pseudo-header values.
Infrastructure teams:** Review proxy-to-backend trust assumptions. Track vendor advisories for Envoy, HAProxy, and Gunicorn for patches addressing these behaviors.
Developers:** Treat all pseudo-header values as potentially malicious input. Ensure backend services validate incoming request lines independently rather than trusting proxy-layer enforcement alone.
What to Watch
Acunetix has added detection capabilities for SSRF patterns emerging from HTTP/2 handling. Other vulnerability scanners will likely follow. For teams running automated security testing, the availability of specific checks for this class of flaw will make configuration validation more straightforward.
Monitor release notes from affected vendors. Implementation-level fixes may arrive in upcoming versions, and understanding which release notes address pseudo-header validation will help prioritize updates.
The immediate mitigation is input validation restricting :method, :scheme, and :path to standard values during proxy configuration. This reduces risk while awaiting vendor patches or updated tooling.
Key takeaways
- Reverse proxies converting HTTP/2 to HTTP/1.1 can generate malformed backend requests when pseudo-header values deviate from expected formats
- Envoy, HAProxy, and Gunicorn each demonstrated distinct vulnerabilities enabling routing manipulation or SSRF
- Security scanning tools now include checks for these patterns, making active detection feasible
- Organizations should audit proxy-to-backend trust assumptions and avoid relying solely on reverse proxy configuration for access control
Frequently asked questions
Do these vulnerabilities require special conditions to exploit?
Exploitation requires sending a crafted HTTP/2 request to a publicly accessible reverse proxy that forwards traffic over HTTP/1.1 to a backend server. No elevated privileges are needed beyond network access to the proxy.
Does using HTTPS for backend connections protect against these flaws?
No. The vulnerability lies in how the proxy constructs the HTTP/1.1 request line before transport encryption is applied. TLS wrapping does not change the malformed content within the request.
Are there known active exploits using these techniques?
The facts do not indicate active exploitation in the wild. However, proof-of-concept details are public, which typically precedes adoption by threat actors.
How do I check if my reverse proxy is affected?
Review your proxy version against the affected releases mentioned in the research. If running Envoy, HAProxy, or Gunicorn in an HTTP/2-to-HTTP/1.1 translation role, testing with a security scanner that includes these checks is the most direct way to confirm exposure.
What is the recommended immediate action?
Evaluate whether your proxy configuration permits arbitrary pseudo-header values. Restricting :method, :scheme, and :path to standard values during input validation can reduce risk while awaiting vendor patches or updates to your tooling.