A serious vulnerability marked as CVE-2023-25690 was disclosed in Apache HTTP Server, versions 2.4. through 2.4.55, that allows HTTP Request Smuggling attacks. This issue is present when mod_proxy is used together with Rewrite rules containing broad patterns that reinsert user-supplied URL data into proxied backend requests.
This post gives a clear look at how this bug works, why it’s dangerous, shows code examples, and explains how to secure your servers.
1. What Is HTTP Request Smuggling?
HTTP request smuggling is a class of attacks where attackers exploit discrepancies in the processing of HTTP requests between different servers in a chain (for example, between a proxy and a backend). This allows attackers to:
2. Who’s Vulnerable?
The bug applies to Apache HTTP Server 2.4. – 2.4.55 when mod_proxy is enabled, along with RewriteRule or ProxyPassMatch configurations that take user input from the URL and re-inject it into the outgoing request to the backend.
The vulnerable configuration usually looks something like this
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:808/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:808/
> Any instance where you take URL data from the client and map it to a backend in this way can be risky.
Here’s a simplified exploitation sequence
1. User sends a specially crafted HTTP request with malicious characters (like line feeds) in the URL.
2. The RewriteRule or ProxyPassMatch copies the URL piece with the malicious data into the outgoing backend request.
The backend gets confused, interpreting the inserted data as the start of a new HTTP request.
4. This leads to “smuggling” multiple requests through the proxy with only one real request, allowing:
Bypassing of security rules in the proxy
- Unauthorized access to URLs/data
The attacker sends a GET request to the Apache proxy
GET /here/elsewhere%d%aX-Smuggled-Header:%20smuggled HTTP/1.1
Host: vulnerable.example.com
The RewriteRule rewrites this into the backend request like so
GET /elsewhere?elsewhere%d%aX-Smuggled-Header:%20smuggled HTTP/1.1
Host: example.com:808
...
The %d%a decodes to a new HTTP header or even a new request at the backend, depending on its configuration. This is request smuggling in action.
Bypass access controls: Attackers may access URLs or data the proxy is supposed to block.
- Confuse backend servers: Smuggle or split requests, affecting how requests are logged or handled.
5. Fix and Mitigation
Update immediately to Apache HTTP Server 2.4.56 or later
This release includes fixes for this vulnerability.
References
- Apache security advisory for CVE-2023-25690
- RedHat security page
If you can’t upgrade right away
- Avoid using generic capture groups (e.g., (.*)) that take unchecked user input in your RewriteRule or ProxyPassMatch rules.
An example of better (but still risky) configuration
RewriteEngine on
RewriteRule "^/here/([a-zA-Z-9_-]+)$" "http://example.com:808/elsewhere?$1"; [P]
But the only guaranteed safe path is upgrading.
6. Testing Vulnerability
You can check your setup with tools like smuggler.py or by manually crafting requests containing encoded line breaks (%d%a) in the URL segments matched by your Rewrite/ProxyPass rules.
7. Conclusion
CVE-2023-25690 is a highly critical bug for anyone running mod_proxy with Rewrite rules in Apache 2.4.–2.4.55. The safest response: patch to 2.4.56 or newer as soon as possible. Never copy unchecked user input directly into backend requests, especially with pattern-based rules.
Further Reading and Official References
- CVE-2023-25690 NIST advisory
- Apache official announcement
- Request smuggling in practice, PortSwigger
Timeline
Published on: 03/07/2023 16:15:00 UTC
Last modified on: 03/14/2023 15:41:00 UTC