When Proxies Become the Attack Vectors in Web Architectures
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.
Concepts of a Cyberplan
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.
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).
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 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.
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 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.
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.
The post When Proxies Become the Attack Vectors in Web Architectures appeared first on Praetorian.
*** This is a Security Bloggers Network syndicated blog from Offensive Security Blog: Latest Trends in Hacking | Praetorian authored by n8n-publisher. Read the original post at: https://www.praetorian.com/blog/cve-2026-0953-bypass-tutor-lms-pro-auth-vulnerability/
About Author
