[CVE-2025-12642] lighttpd Trailer Handling Bug Enables HTTP Header Smuggling

TL;DR
lighttpd version 1.4.80 accepts trailer fields such as “Connection” or “Forwarded” and silently folds them into the ordinary request headers. A single crafted request can confuse reverse proxies, evade WAF rules or inject data into downstream applications. The maintainers fixed the logic in 1.4.81. Administrators who serve traffic over HTTP/1.1 or through proxy chains should patch quickly even though no public exploit has surfaced yet.

1. Summary

lighttpd incorrectly processed HTTP/1.1 trailer fields that appeared after the message body. Instead of discarding or isolating them, the server appended each field to the request header map before handing control to modules or upstream services. By choosing trailer names that are normally filtered at the edge, an attacker can inject headers that modify authentication, caching or routing decisions.

2. Context – why a trailer parsing bug matters

lighttpd is popular on low-memory appliances, container images and embedded dashboards because of its tiny footprint and event-driven architecture. Many of these deployments front a FastCGI or reverse-proxy chain rather than serving static files. Header smuggling attacks target precisely this architecture: they exploit discrepancies between how the front server and the backend interpret a single request. If lighttpd merges a forbidden “Host”, “Content-Length” or “X-Original-URL” header, the gateway may apply policy to one set of headers while the backend sees another, opening the door to request splitting, cache poisoning or authentication bypass.

Although trailer fields are uncommon on the public Internet, they are fully legal in HTTP/1.1 and ignored by most security tooling, which increases the likelihood that malicious traffic will stay under the radar.

3. Technical Details – from RFC to vulnerable code

HTTP/1.1 allows senders to transmit additional header fields after the message body when the body is sent with Transfer-Encoding: chunked. These trailer fields are meant for integrity checks (Digest) or metadata that is expensive to compute up front. Section 4.4 of RFC 7230 explicitly forbids certain header names in trailers because mixing them with start-line headers breaks protocol invariants.

The vulnerable routine lives in src/request.c where lighttpd reads incoming chunks. When the final zero-length chunk arrives it parses the trailer block and calls an internal http_header_append. No validation step filtered out hop-by-hop headers such as “Connection” or restricted fields like “Content-Length”. The resulting request object therefore contained duplicate keys or semantic contradictions, which later modules resolved using naive “first seen wins” logic.

An attacker only needs to craft a request like the following:

POST /login HTTP/1.1
Host: secure.example
Transfer-Encoding: chunked
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

0
Connection: keep-alive
X-Original-URL: /admin

lighttpd merges “X-Original-URL” into the header table and forwards the request to its backend. If the backend trusts that header for route rewriting, the attacker gets privileged content while the access log still shows a POST to “/login”.

The patch in version 1.4.81 rejects trailers containing hop-by-hop fields and preserves a separate buffer for the rest, aligning behavior with the RFC.

4. Impact – practical scenarios

In real deployments the bug can:

• Bypass path-based access controls when a WAF in front of lighttpd filters on the initial request line but the backend honors a later “X-Original-URL” trailer.
• Poison shared caches by injecting a second “Host” or “Cookie” header seen only by a downstream proxy so that cached objects leak between tenants.
• Enable full request smuggling chains when lighttpd sits behind AWS ALB, nginx or HAProxy. By manipulating “Content-Length” versus “Transfer-Encoding” semantics, attackers can carry out response desynchronisation, hijack sessions or steal CSRF tokens.

Because the attack does not require authentication and runs over standard HTTP ports, external threat actors can probe Internet-facing servers with low risk of detection.

5. Remediation – what administrators should do

Upgrade to lighttpd 1.4.81 or newer. The release is a drop-in replacement with no configuration changes. If an immediate upgrade is impossible you can reduce exposure by disabling chunked request bodies with:

server.stream-request-body = 0

or by rejecting requests that advertise Transfer-Encoding: chunked at the edge proxy. Both workarounds may break legitimate clients that rely on chunked uploads, so they should only be temporary.

6. Timeline

7. References

• Patch commit: https://github.com/lighttpd/lighttpd1.4/commit/35cb89c103877de62d6b63d0804255475d77e5e1

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the tradditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• This CVE carries a CVSS 3.1 base score of 9.1, reflecting high confidentiality and integrity impact with network-level exploitability. CVSS captures technical severity but not real-world likelihood.
• EPSS assigns a probability of 0.0 because the model has not yet seen enough telemetry for a brand-new CVE.
• CISA has not listed the vulnerability in KEV, so there is no mandated federal patch deadline.

The Volerion Risk Score blends these objective metrics with additional factors such as product prevalence, exploit maturity and remediation cost. For CVE-2025-12642 the score is 7.9, placing it in our high-risk band despite the absence of a public exploit.