TL;DR
Reverse proxies sit at the perimeter of your network, routing traffic between the internet and your backend services. When they're vulnerable, attackers can bypass authentication, poison caches, or pivot directly into internal systems. This post covers the most significant reverse proxy CVEs in recent years — including Nginx, Apache httpd, and HAProxy — and outlines concrete steps Australian SMBs can take to harden their proxy infrastructure.
Why Reverse Proxy Vulnerabilities Are High-Impact
Get Our Weekly Cybersecurity Digest
Every Thursday: the threats that matter, what they mean for your business, and exactly what to do. Trusted by SMB owners across Australia.
No spam. No tracking. Unsubscribe anytime. Privacy
A reverse proxy is typically the first hop for inbound web traffic. It terminates TLS, enforces access policies, and shields backend applications from direct exposure. That central position makes it a high-value target. A single misconfiguration or unpatched vulnerability can undermine every service behind it.
Unlike application-layer bugs that affect one product, reverse proxy flaws tend to be systemic. They impact every tenant, every route, and every backend simultaneously. The 2024-2025 CVE landscape has shown a steady stream of path traversal, HTTP request smuggling, and header injection flaws across all major proxy implementations.
Free Resource
Weekly Threat Briefing — Free
Curated threat intelligence for Australian SMBs. Active campaigns, new CVEs, and practical mitigations — every week, straight to your inbox.
Subscribe Free →Notable Reverse Proxy CVEs
CVE-2024-7646 — Ingress-NGINX Path Traversal (Kubernetes)
Ingress-NGINX, the default ingress controller for Kubernetes clusters, was found to allow path traversal via specially crafted ingress objects. An attacker who could create or modify ingress resources could use path traversal to access the filesystem of the NGINX controller pod — potentially reading secrets, tokens, and configuration files. This affected versions prior to 1.11.0 and carried a CVSS score of 6.5. For any organisation running Kubernetes with NGINX ingress, this was a direct path to cluster compromise.
CVE-2024-24990 — HAProxy HTTP/2 Header Parsing
HAProxy disclosed a vulnerability in its HTTP/2 header parsing logic that could allow a remote attacker to trigger undefined behaviour through malformed HPACK-encoded headers. In certain configurations this could lead to request smuggling — where an attacker crafts a single HTTP request that the proxy and backend interpret as two separate requests, bypassing access controls. Versions before 2.9.7, 2.8.7, and 2.6.16 were affected.
CVE-2023-44487 — HTTP/2 Rapid Reset (Protocol-Level)
While not specific to a single reverse proxy, CVE-2023-44487 exploited the HTTP/2 protocol itself. An attacker could send a stream of requests and immediately cancel them, forcing the server to allocate and tear down resources at extreme speed. Nginx, Apache, HAProxy, and every other reverse proxy supporting HTTP/2 was affected. The resulting DDoS amplification was staggering — Cloudflare reported attacks exceeding 201 million requests per second. This CVE demonstrated that even standards-compliant proxy implementations can be weaponised.
CVE-2024-36391 — Apache httpd mod_proxy WebSocket Handling
Apache's mod_proxy module, widely used as a reverse proxy, contained a vulnerability where malicious WebSocket upgrade requests could cause the proxy worker to enter an inconsistent state. Under sustained attack, this led to worker exhaustion and denial of service. Apache httpd versions before 2.4.60 were affected.
CVE-2023-38408 — OpenSSH Agent Forwarding (Proxy-Jump Chains)
Although an OpenSSH vulnerability rather than a web proxy flaw, CVE-2023-38408 is relevant because reverse proxy architectures often rely on SSH proxy jumps and bastion hosts. A flaw in SSH agent forwarding allowed an attacker on a compromised intermediate host to use the forwarded agent to authenticate to other systems. For organisations using SSH-based proxy chains to reach internal services, this was a lateral movement goldmine.
ISO 27001 SMB Starter Pack — $97
Threat intelligence is one thing — having the policies and controls to respond is another. Get the complete ISO 27001 starter kit for SMBs.
Get the Starter Pack →Hardening Recommendations
Patch relentlessly. Every major reverse proxy vendor releases security advisories. Subscribe to the Nginx security mailing list, Apache httpd announcements, and HAProxy security advisories. Apply patches within 48 hours for critical CVEs — not next maintenance window.
Disable unused modules and protocols. If you don't need HTTP/2, turn it off. If you don't need WebSocket proxying, don't load the module. Every enabled feature is additional attack surface.
Validate and sanitise headers at the edge. Request smuggling thrives on inconsistencies between proxy and backend parsers. Strip unexpected headers, normalise paths, and set explicit Host headers rather than passing through whatever the client sends.
Segment your proxy infrastructure. Don't run a single reverse proxy for both public-facing services and internal management interfaces. Use separate proxy instances with different security policies so a compromise of one doesn't expose everything.
Monitor proxy logs for anomalous patterns. Rapid Reset attacks, path traversal attempts, and malformed HTTP/2 headers all leave signatures. Feed proxy access logs into a SIEM and alert on deviation from baseline traffic patterns.
FAQ
What exactly is a reverse proxy? A reverse proxy sits in front of web servers and forwards client requests to the appropriate backend. It handles TLS termination, load balancing, caching, and often acts as a web application firewall. Common examples include Nginx, Apache httpd with mod_proxy, HAProxy, and Traefik.
How do I check if my reverse proxy is vulnerable?
Identify the exact version and modules in use, then cross-reference against the vendor's security advisories and the NVD (National Vulnerability Database). Tools like nginx -v, apache2ctl -v, or haproxy -v will give you version numbers to check.
Is a CDN like Cloudflare a replacement for hardening my own reverse proxy? No. A CDN provides an additional layer of protection, but traffic still reaches your origin server. If your origin runs a vulnerable reverse proxy, an attacker who bypasses the CDN — or exploits a protocol-level flaw like HTTP/2 Rapid Reset at the origin — can still compromise your infrastructure.
How often should reverse proxy software be updated? At minimum, apply security patches within 48 hours of disclosure for critical vulnerabilities. For routine updates, follow a monthly cadence. Never let a reverse proxy go more than 90 days without a version review.
Conclusion
Reverse proxies are force multipliers — for your traffic management and, unfortunately, for attackers who find a way in. The CVEs above are not theoretical; they are actively exploited in the wild, and the next one is always around the corner. The organisations that weather these vulnerabilities are the ones that patch fast, minimise their attack surface, and monitor what matters.
Start by inventorying every reverse proxy in your environment, cataloguing the version and enabled modules, and checking each against current CVE databases. If you don't know where your proxies are or what they're running, you can't protect them.
Visit consult.lil.business for a free cybersecurity assessment.
References
- Nginx Security Advisories
- Apache HTTP Server Security Reports
- HAProxy Security Advisories
- NVD - CVE-2023-44487 HTTP/2 Rapid Reset
- Kubernetes Ingress-NGINX CVE-2024-7646 Advisory
Work With Us
Ready to strengthen your security posture?
lilMONSTER assesses your risks, builds the tools, and stays with you after the engagement ends. No clipboard-and-leave consulting.
Book a Free Consultation →
lilMONSTER Newsletter
Weekly cybersecurity insights, practical tips, no spam. Unsubscribe anytime.