Many modern web applications rely on the flawed assumption 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 header field in fundamentally different ways, creating exploitable gaps that attackers are increasingly targeting through http header manipulation techniques. 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 security 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 through header injection attacks.
Key Takeaways: Two newly discovered CVEs — CVE-2025-48865 in Fabio and CVE-2025-64484 in OAuth2-proxy — expose a systemic vulnerability in how reverse proxies handle http header processing. 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 that affects web security across multiple browser and web server implementations.
CVE-2025-48865: HTTP Header Injection Through Hop-by-Hop Header Abuse in Fabio
In a typical setup, reverse proxies strip untrusted client headers and inject their own security-critical response header values (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 configure the proxy to remove security headers they would normally preserve and trust. This attack method has surfaced across multiple reverse proxy implementations, including Apache HTTP Server (CVE-2022-31813), Traefik (CVE-2024-45410), and, most recently, Fabio. As shown in the screenshot below, I discovered that Fabio was susceptible to the same abuse by including security-critical headers like Forwarded in the Connection header, causing Fabio to strip them before forwarding the http request to 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 the header is used to indicate information that should only be processed by the immediate recipient (the proxy) and removed before forwarding to the next web 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 request headers that the backend relies on for authentication and access control.
Diagram showing normal Fabio proxy behavior (top) where all security headers are forwarded to the backend, versus the attack flow (bottom) where including Forwarded in the Connection header causes Fabio to strip it before reaching the backend server
Fabio Connection header attack strips security headers from the backend through malicious injection.
To understand why stripping these headers is dangerous, consider what backends actually use them for. Headers like X-Real-IP and X-Forwarded-For often drive access control decisions, determining whether a request is internal or external, or whether a sensitive endpoint should be accessible. The http header is used by web applications to validate client origins and implement proper session management controls. For example, ProjectDiscovery’s research into Versa Concerto found that the application relied on X-Real-IP to restrict access to Spring Boot Actuator endpoints. If that header gets stripped, the security logic simply never triggers, creating a vulnerability that bypasses the web application firewall protections.
Header Normalization: The Underscore-Hyphen Problem Across Web Application 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 application 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 proxy servers don’t recognize, but backends will normalize and process as trusted security headers. The header can be used by browsers and servers to communicate protocol version information and handle http or https scheme transitions.
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 http header injection attacks. A misconfigured reverse proxy might forward malicious headers that the origin server processes incorrectly, leading to cache poisoning or other security issues.
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. This process affects how the header is set by different components and can lead to duplicate headers being processed differently.
CVE-2025-64484: OAuth2-Proxy Authentication Bypass via HTTP Response Header Underscore 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, performs a redirect to an identity provider for authentication, and then forward the authenticated request to the backend application, along with user information in http responses containing 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 while maintaining proper cache control and dns resolution.
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 for the standard hyphenated versions. The proxy’s security controls completely miss underscore variants such as X_Forwarded_Email, allowing these malicious headers to pass through unfiltered. When these underscore-based headers reach backend applications that normalize header names and convert them back to the hyphenated form, the backend may treat them as expected headers. The result is that an attacker can exploit OAuth2-proxy’s authentication by sending X_Forwarded_Email, which the backend processes as a trusted X-Forwarded-Email header, leading to privilege escalation or account takeover. This vulnerability affects how browsers handle cross-site scripting (xss) protection and same-origin policy enforcement.
Diagram showing the OAuth2-proxy underscore bypass attack where an attacker sends X_Forwarded_Email with underscores which passes through OAuth2-proxy filters undetected and gets normalized to the trusted X-Forwarded-Email header by the backend framework
OAuth2-proxy underscore bypass gets normalized to a trusted header by the backend through http header manipulation.
The x-forwarded-proto header indicates whether the original host requested the resource using https, and when this information gets manipulated, it can affect how the load balancer routes traffic and how the user agent processes response body content. Additionally, the header allows attackers to manipulate api responses and json data processing, potentially leading to stored cross-site scripting attacks through malicious javascript injection.
MITRE ATT&CK TTP Mapping for HTTP Header Injection Vulnerability
These header injection techniques map to several MITRE ATT&CK tactics and techniques. The primary attack pattern falls under Initial Access (T1190 – Exploit Public-Facing Application) when attackers target proxy configurations to bypass authentication controls. The vulnerability also enables Defense Evasion (T1562 – Impair Defenses) by circumventing proxy security filters through header normalization abuse. When successful, these attacks can lead to Privilege Escalation (T1068) by allowing attackers to inject authentication headers and impersonate legitimate users. The attacks may also facilitate Lateral Movement if the compromised authentication grants access to additional internal systems through firewall bypass.
Defending Against Proxy Trust Boundary Attacks and Cache Vulnerabilities
Defending against these vulnerabilities requires precise adherence to the HTTP RFC and careful handling of ambiguous behaviors, such as header normalization and case sensitivity. Organizations must also evaluate how different HTTP servers and frameworks interact before deployment, as these implementation differences create the attack surface. Another solution is to implement cryptographic signing of authentication headers so backends can validate and 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. Web cache systems should also sanitize input to prevent cache poisoning attacks, and administrators should configure appropriate mime type restrictions for api endpoints that process query string parameters.
Additional protective measures include implementing proper controls dns prefetching through security headers, ensuring that carriage return and line feed (crlf characters) are properly encoded in url processing, and preventing cross-origin resource sharing abuse. Organizations should also monitor for duplicate headers that might indicate manipulation attempts and unset any untrusted headers before processing. The nginx documentation provides guidance on how to properly sanitize headers and prevent injection of malicious content into the response body.
Praetorian’s application security assessments regularly uncover trust boundary issues. For organizations focused on architectural security, we provide evaluations covering both application and infrastructure risks.
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 through malicious query manipulation and domain name spoofing.
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 Forwarded 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. This technique can also be used to inject malicious urls that bypass normal validation checks.
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, and potentially encode malicious content in the headers.
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. These vulnerabilities particularly affect how frameworks process query parameters and handle cross-origin requests.
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. Additionally, configure proper session management controls and ensure that header indicates values are properly validated before processing.
What is HTTP Header Injection?
HTTP header injection is a type of injection attack where malicious actors manipulate HTTP request or response headers by injecting malicious content into header fields. This vulnerability occurs when applications fail to properly validate and encode user input that gets incorporated into HTTP headers. Attackers can exploit this to perform cache poisoning, cross-site scripting attacks, or bypass authentication mechanisms by crafting malicious headers that the backend server processes unexpectedly.
What causes HTTP header injection vulnerabilities?
HTTP header injection vulnerabilities are primarily caused by insufficient input validation and improper encoding of user-supplied data before it’s incorporated into HTTP headers. Applications that directly pass user input to header fields without sanitization create opportunities for attackers to inject malicious content. Poor configuration of firewalls, proxies, or backend systems can also contribute to these vulnerabilities, especially when they handle duplicate headers inconsistently.
How to Prevent Host Header Attacks?
Host header attacks can be prevented by implementing strict validation of the Host header field against a whitelist of allowed domain names and configuring your web server or firewall to reject requests with invalid hosts. Applications should avoid using the Host header for critical functionality like authentication or cache keys without proper validation. Additionally, configure your backend systems to handle HTTP requests consistently and ensure that load balancers or proxies forward requests securely to prevent DNS-based attacks.
How http header manipulation works
HTTP header manipulation works by modifying header fields in HTTP requests or HTTP responses to alter application behavior or exploit vulnerabilities. Attackers typically use tools like browser developer tools, proxy software, or custom scripts to inject malicious content into headers such as Host, X-Forwarded-For, or custom API headers. The manipulated headers are then processed by the backend server, potentially leading to cache poisoning, authentication bypass, or injection attacks depending on how the application handles the modified header data.
Why http header manipulation is important
HTTP header manipulation is important for security professionals to understand because headers control critical aspects of web communication including authentication, caching behavior, and content delivery. Proper header manipulation techniques are essential for legitimate purposes like API authentication, configuring cache policies, and implementing security controls through headers. However, malicious header manipulation can lead to severe vulnerabilities including cross-site scripting, cache poisoning, and authentication bypass, making it crucial for developers to implement proper validation and encoding mechanisms.
