stricter request header parsing
Server accepts and normalizes invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a lighthttpd server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or request smuggling, the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy.
Similar bug in GO:
Request smuggling attack:
Hi, thanks for reporting this!
I disagree with RFC 7230 a little bit on this though: I think accepting and normalizing such headers should be acceptable behavior - the real problem are proxies which forward broken requests (without normalizing them) but still rely on having parsed them correctly (if they don't mix streams from different clients and don't cache there is probably no issue).
I'm not saying we shouldn't (or won't) change this, but I don't consider this CVE-worthy.
- Tracker changed from Bug to Feature
- Category set to core
- Status changed from New to Patch Pending
- Target version changed from 1.4.x to 1.4.55
This is already updated on my development branch. A response was previously sent to a reporter who sent email to security@
By default, lighttpd parses (and normalizes) requests before reverse-proxying them to backends. Doing so thwarts the attacks mentioned in https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn to servers upstream from lighttpd.
However, as mentioned by stbuehler above, proxies downstream from lighttpd might pass anything to lighttpd.
The change that will be made in the next release of lighttpd will be to reject requests with space or tab after field-name and before the colon, but only when lighttpd is configured in the (default) mode of strict http header parsing.
Also available in: Atom