Many reverse-proxy attack techniques reveal a dangerous assumption embedded in modern web architectures: backend systems often trust security-sensitive HTTP headers that arrive from upstream reverse proxies without verification. Unfortunately, this trust model frequently breaks down.
The flexibility built into HTTP specifications allows different servers and frameworks to interpret the same headers in different ways. Those inconsistencies create subtle gaps that attackers can exploit. Two recent vulnerabilities illustrate this systemic issue clearly. Rather than being isolated mistakes, they highlight a deeper architectural weakness in how proxy-to-backend trust relationships are implemented.
When CVE-2025-48865 in Fabio and CVE-2025-64484 in OAuth2-proxy allow the same attack pattern across completely different technologies, it becomes evident that the industry has misunderstood where real security boundaries exist. Both vulnerabilities show how mismatches in header processing between proxies and backend services can defeat security controls entirely. As a result, internal communication that should be trusted can instead become a pathway for authentication bypass or privilege escalation.
Key Takeaways
Two newly identified vulnerabilities — CVE-2025-48865 (Fabio) and CVE-2025-64484 (OAuth2-proxy) — expose a widespread flaw in how reverse proxies handle HTTP headers.
By exploiting behaviors such as hop-by-hop header stripping and differences in underscore-hyphen header normalization, attackers can circumvent proxy protections. These weaknesses allow malicious users to bypass authentication mechanisms or escalate privileges.
Importantly, these problems are not simply isolated bugs. They represent a deeper issue with trust boundaries in modern proxy-backend architectures.
Reverse Proxy Attack Vectors: Security Headers and Trust Boundaries
What is a reverse proxy trust boundary?
In most modern web deployments, reverse proxies sit between external users and internal backend services. Their role includes filtering traffic and managing security-related headers.
Typically, proxies remove any untrusted headers supplied by clients and then add their own trusted headers, such as:
- X-Forwarded-For
- X-Real-IP
Backend applications rely on these headers to make security decisions such as authentication checks, rate limiting, and access control.
The trust boundary lies in the assumption that any security header reaching the backend must have been inserted by the proxy itself — not by a malicious client.
Exploiting HTTP Connection Headers
This model becomes fragile because of how the HTTP protocol handles certain headers.
The Connection header allows a client to specify hop-by-hop headers, meaning headers that should only apply to the immediate recipient and should not be forwarded further down the chain.
An attacker can abuse this behavior.
For example, by sending:
Connection: close, X-Forwarded-Host
a client can cause a proxy to treat X-Forwarded-Host as a hop-by-hop header. The proxy may then strip it before forwarding the request.
If backend logic expects that header to be present for security checks, the protection can fail entirely.
This attack pattern has appeared repeatedly across different proxy technologies, including:
- Apache HTTP Server — CVE-2022-31813
- Traefik — CVE-2024-45410
- Fabio — CVE-2025-48865
CVE-2025-48865: Fabio’s Connection Header Vulnerability
The Fabio vulnerability demonstrates how dangerous header stripping can become when backend applications treat certain headers as authoritative.
Recent security research by ProjectDiscovery examining Versa Concerto showed a practical example of this attack.
In that system, the application relied on the X-Real-IP header to restrict external access to sensitive Spring Boot Actuator endpoints.
However, attackers discovered they could bypass this protection by including:
Connection: X-Real-IP
This caused Traefik to remove the X-Real-IP header before forwarding the request.
Because the backend no longer saw the header, its authentication check was never triggered. As a result, attackers could gain unauthorized access to sensitive endpoints.
What is a Hop-by-Hop Header Attack?
The Connection header in HTTP was originally designed to control which headers should only apply to a single network hop.
Attackers exploit this mechanism by listing security-sensitive headers — such as:
- X-Forwarded-For
- X-Real-IP
When the proxy interprets those headers as hop-by-hop, it removes them before forwarding the request.
If backend security checks depend on those headers, the logic can be bypassed.
Header Normalization: The Underscore-Hyphen Problem
Another attack surface comes from HTTP header normalization.
Research by Intruder has shown that many web frameworks automatically normalize header names during processing. This normalization can take several forms:
- Standardizing capitalization (e.g.,
client-verified→Client-Verified) - Treating uppercase and lowercase headers as identical
- Converting separators
These transformations can create subtle inconsistencies between proxies and backend frameworks.
Deutsche Telekom Security research highlighted one particularly dangerous example: underscore-hyphen normalization.
Different frameworks handle separators differently:
- Some convert hyphens to underscores
- Others treat both formats as equivalent
This inconsistency allows attackers to send headers in a form that a proxy fails to recognize but that the backend later normalizes and accepts as legitimate.
What is HTTP Header Normalization?
Header normalization occurs when a framework automatically standardizes header names during request processing.
For example:
x_forwarded_email
may be normalized into:
X-Forwarded-Email
Similarly:
x-real-ip
might become:
X-Real-IP
If a proxy only filters the canonical hyphenated version, attackers can send an alternate format such as underscores. Once the request reaches the backend, normalization converts the header into the trusted format, effectively bypassing the proxy’s filtering rules.
CVE-2025-64484: OAuth2-Proxy Header Smuggling Vulnerability
The vulnerability in OAuth2-proxy illustrates how normalization issues can lead directly to authentication bypass.
OAuth2-proxy functions as an authentication gateway positioned between users and backend applications. It handles OAuth2 or OIDC authentication for applications that do not implement authentication themselves.
The typical workflow is:
- A user requests a protected resource.
- OAuth2-proxy intercepts the request.
- The user is redirected to an identity provider for authentication.
- After successful authentication, the request is forwarded to the backend.
User identity information is passed through HTTP headers such as:
- X-Forwarded-User
- X-Forwarded-Email
This allows legacy applications or simple services to gain enterprise-grade authentication capabilities without modifying their code.
The Vulnerability
CVE-2025-64484 reveals a flaw in OAuth2-proxy’s header sanitization logic.
While the proxy correctly removes sensitive headers like X-Forwarded-Email from incoming client requests, it only filters the standard hyphenated format.
Variants that use underscores — such as:
X_Forwarded_Email
are not blocked.
These headers pass through the proxy untouched.
When they reach backend applications — particularly WSGI-based frameworks such as Django, Flask, or many PHP environments — the frameworks automatically normalize the header names.
The result:
X_Forwarded_Email → X-Forwarded-Email
Now the backend interprets the header as a legitimate authentication header.
This allows attackers to:
- impersonate users
- escalate privileges
- potentially take over accounts
The attack works because OAuth2-proxy sanitizes only some variants of security-critical headers, while backend frameworks normalize all variants.
Defending Against Proxy Trust Boundary Attacks
Mitigating these vulnerabilities requires careful attention to how HTTP headers are handled across every component in a request chain.
Key defensive strategies include:
Strict RFC-compliant handling of HTTP headers
Systems must carefully interpret ambiguous behaviors such as case sensitivity, hop-by-hop headers, and normalization.
Understanding proxy-backend interactions
Different frameworks and HTTP servers process headers differently. Security reviews must evaluate how these systems interact rather than analyzing components in isolation.
Cryptographic signing of security headers
One potential approach is to cryptographically sign authentication headers so backend services can verify their authenticity regardless of proxy behavior. However, this technique is rarely implemented in major production environments.
Backend verification
Most importantly, backend services should validate critical headers instead of automatically trusting them simply because they originate from a proxy.
The Systemic Nature of Proxy Trust Failures
These vulnerabilities are not rare edge cases.
The fact that CVE-2025-48865 and CVE-2025-64484 enable the same outcomes — authentication bypass and privilege escalation — across entirely different proxy systems indicates a deeper issue.
The problem lies in a flawed architectural assumption: that proxies and backends will interpret HTTP headers identically.
As long as the HTTP specification allows flexibility in header parsing, normalization rules, and hop-by-hop behavior, every proxy-backend interaction becomes a potential security boundary failure.
Instead of treating each vulnerability as an isolated bug, the industry must recognize the proxy-backend interface as an adversarial boundary. Security controls should assume inconsistencies will occur and should enforce verification at every layer of the architecture.
