Many Reverse proxy attack vectors expose a flawed assumption in modern web architectures that backends can blindly trust security-critical headers from upstream reverse proxies. This assumption breaks down because HTTP RFC flexibility allows different servers to interpret the same headers in fundamentally different ways, creating exploitable gaps that attackers are increasingly targeting. I want to examine how two recent CVEs I found expose this systemic problem and demonstrate why these aren’t isolated bugs but symptoms of a much broader architectural flaw.
When CVE-2025-48865 in Fabio and CVE-2025-64484 in OAuth2-proxy both enable identical attack patterns across completely different technologies, it reveals that our industry has fundamentally misunderstood where the real security boundaries lie. These vulnerabilities demonstrate how implementation inconsistencies between proxy and backend components can completely undermine security controls, transforming what should be trusted internal communication into a vector for authentication bypass and privilege escalation.
Key Takeaways: Two newly discovered CVEs — CVE-2025-48865 in Fabio and CVE-2025-64484 in OAuth2-proxy — expose a systemic flaw in how reverse proxies handle HTTP headers. By exploiting hop-by-hop header stripping and underscore-hyphen normalization differences, attackers can bypass proxy security controls to achieve authentication bypass and privilege escalation. These aren’t isolated bugs; they’re symptoms of a fundamental trust boundary problem in modern proxy-backend architectures.
Reverse Proxy Attack Vectors: How Proxies Handle Security Headers
What is a reverse proxy trust boundary? In a typical web architecture, reverse proxies sit between users and backend servers. They strip untrusted client headers and inject their own security-critical ones — such as X-Forwarded-For and X-Real-IP — which backends then use for authentication and access control decisions. The “trust boundary” is the assumption that any security header arriving at the backend was legitimately set by the proxy, not injected by an attacker.
In a typical setup, reverse proxies strip untrusted client headers and inject their own security-critical ones (such as X-Forwarded-For and X-Real-IP), which backends can then use for authentication and access control decisions. However, HTTP’s Connection header allows clients to designate certain headers as “hop-by-hop,” meaning they should be processed only by the immediate recipient and stripped before forwarding. By setting Connection: close, X-Forwarded-Host, an attacker can trick proxies into removing security headers they would normally preserve and trust.
This attack pattern has surfaced across multiple reverse proxy implementations, including Apache HTTP Server (CVE-2022-31813), Traefik (CVE-2024-45410), and, most recently, Fabio (CVE-2025-48865).
CVE-2025-48865: Fabio’s Connection Header Vulnerability Strips Security Headers
This becomes a critical vulnerability when backend applications treat these manipulated headers as authoritative sources for security decisions. ProjectDiscovery’s recent security research into Versa Concerto demonstrates this perfectly: the vulnerable application used the X-Real-IP header to block external access to sensitive Spring Boot Actuator endpoints, but attackers could bypass this protection by using Connection: X-Real-IP to force Traefik to drop the header entirely. Without the X-Real-IP header present, the backend’s authentication logic never triggered, granting unauthorized access to endpoints.
Fabio Connection header attack strips security headers from the backend.
What is a hop-by-hop header attack? HTTP’s Connection header was designed to let clients specify which headers are “hop-by-hop” — meaning they should only be processed by the immediate recipient (the proxy) and removed before forwarding to the next server. Attackers abuse this by listing security-critical headers like X-Forwarded-For or X-Real-IP in the Connection header, tricking the proxy into stripping headers that the backend relies on for authentication and access control.
Header Normalization: The Underscore-Hyphen Problem Across Web Frameworks
Header normalization creates yet another attack vector that exploits the same fundamental trust boundary weakness. As documented in extensive research by Intruder, many web frameworks automatically normalize header names during processing. This normalization takes various forms: some frameworks capitalize each word and standardize separators (e.g., converting client-verified to Client-Verified), while others perform case normalization, treating X-Real-IP and x-real-ip identically. These normalization differences create systematic opportunities for attackers to smuggle headers using variations that proxies don’t recognize, but backends will normalize and process as trusted security headers.
Additionally, Deutsche Telekom Security’s research specifically highlighted the underscore-hyphen normalization problem across web frameworks. Different frameworks handle header normalization inconsistently: some convert hyphens to underscores, while others make headers accessible regardless of the original separator format, creating systematic opportunities for header smuggling attacks.
What is HTTP header normalization? HTTP header normalization is when a web framework automatically standardizes header names during processing. For example, a framework might convert x_forwarded_email (underscores) to X-Forwarded-Email (hyphens), or x-real-ip (lowercase) to X-Real-IP (mixed case). When a proxy’s security filters only check for one format but the backend normalizes all variants to the same canonical form, attackers can smuggle malicious headers past the proxy using an unfiltered variation.
CVE-2025-64484: OAuth2-Proxy Authentication Bypass via Header Smuggling
OAuth2-proxy’s vulnerability demonstrates the security implications of this normalization behavior. OAuth2-proxy is an authentication proxy that sits between users and backend applications, handling OAuth2/OIDC authentication flows for applications that don’t natively support them. When a user requests a protected resource, OAuth2-proxy intercepts the request, redirects them to an identity provider for authentication, and then forwards the authenticated request to the backend application, along with user information in HTTP headers such as X-Forwarded-User and X-Forwarded-Email. This design allows legacy applications or simple services to gain enterprise authentication capabilities without code changes.
CVE-2025-64484 exposes a critical flaw in OAuth2-proxy’s header sanitization logic. While OAuth2-proxy correctly strips security-critical headers, such as X-Forwarded-Email, from incoming client requests to prevent header injection attacks, it only filters them on the standard hyphenated versions. The proxy’s security controls completely miss underscore variants like X_Forwarded_Email, allowing these malicious headers to pass through unfiltered.
OAuth2-proxy underscore bypass gets normalized to a trusted header by the backend
When these underscore headers reach backend applications that normalize header names — such as WSGI frameworks like Django and Flask, or PHP applications — they get automatically converted back to the hyphenated form that the backend expects. The result is that an attacker can completely bypass OAuth2-proxy’s authentication by sending X_Forwarded_Email, which the backend processes as a trusted X-Forwarded-Email header for privilege escalation or account takeover. This attack succeeds because OAuth2-proxy fails to sanitize all variants of security-critical headers, creating a dangerous gap between the proxy’s filtering logic and the backend’s normalization behavior.
Defending Against Proxy Trust Boundary Attacks
Defending against these vulnerabilities requires precise HTTP RFC implementation, carefully handling ambiguous behaviors like header normalization and case sensitivity. Organizations must also understand how different HTTP servers and frameworks interact, as these implementation differences create the attack surface.
Another solution is to implement cryptographic signing of authentication headers so backends can verify their authenticity regardless of proxy behavior, although I’ve never seen this implemented in any major production servers. Most importantly, backends should validate rather than blindly trust security-critical headers from proxies.
The Systemic Nature of Proxy Security Boundaries
These aren’t edge cases. The fact that CVE-2025-48865 and CVE-2025-64484 enable identical attack patterns — authentication bypass and privilege escalation — across completely different proxy technologies tells us something important: the problem isn’t in any single implementation. It’s in the architectural assumption that proxies and backends will always interpret HTTP headers the same way.
As long as the HTTP specification allows flexibility in header parsing, normalization, and hop-by-hop behavior, every proxy-backend pair represents a potential trust boundary violation. The industry needs to stop treating these as isolated bugs to be patched one at a time and start treating the proxy-backend trust boundary as an adversarial interface that requires explicit verification at every layer.
Praetorian’s application security assessments regularly identify these trust boundary vulnerabilities. If you’re concerned about architectural security issues in your infrastructure, contact our team for a comprehensive security evaluation that covers the full range of application and infrastructure vulnerabilities.
Frequently Asked Questions
What is a reverse proxy header smuggling attack?
A reverse proxy header smuggling attack exploits differences in how proxy servers and backend applications parse HTTP headers. Attackers send specially crafted headers — using the Connection header to strip security headers (hop-by-hop attacks), or using underscore variants that bypass proxy filters but get normalized by backends (normalization attacks). Both techniques allow attackers to manipulate the security headers that backends rely on for authentication and access control, potentially enabling authentication bypass or privilege escalation.
How does CVE-2025-48865 in Fabio enable authentication bypass?
CVE-2025-48865 allows attackers to abuse the HTTP Connection header to trick Fabio into stripping security-critical headers like X-Forwarded-For, X-Real-IP, and X-Forwarded-Host before forwarding requests to the backend. When backend applications rely on these headers for access control — for example, restricting admin endpoints to internal IP addresses — removing them can cause the backend’s security logic to fail open, granting unauthorized access to protected resources.
How does CVE-2025-64484 in OAuth2-proxy enable privilege escalation?
CVE-2025-64484 exploits a gap in OAuth2-proxy’s header sanitization. OAuth2-proxy correctly strips the standard hyphenated version of security headers (e.g., X-Forwarded-Email) from client requests, but fails to filter underscore variants (e.g., X_Forwarded_Email). When backend frameworks like Django, Flask, or PHP applications normalize underscore headers to their hyphenated equivalents, the attacker’s injected header is treated as a trusted authentication header — allowing them to impersonate any user, including administrators.
What web frameworks are vulnerable to header normalization attacks?
WSGI-based frameworks like Django and Flask, PHP applications, and many other web frameworks automatically normalize HTTP header names during processing. This includes converting underscores to hyphens, standardizing capitalization, and treating different separator formats as equivalent. Any backend framework that normalizes header names can be vulnerable when paired with a proxy that doesn’t sanitize all header variants — the attack depends on the mismatch between the proxy’s filter logic and the backend’s normalization behavior.
How can organizations protect against proxy trust boundary vulnerabilities?
Organizations should implement defense in depth across the proxy-backend boundary: sanitize all header name variants (including underscore and case variations) at the proxy layer, block abuse of the Connection header by allowlisting legitimate hop-by-hop headers, implement backend-side verification of security headers using cryptographic signatures or mutual TLS, audit the specific proxy-backend framework combination in your stack for parsing mismatches, and keep all reverse proxy software patched against known CVEs.
