Safeguard
Vulnerability Analysis•

CVE-2025-12642: Critical Header Smuggling in lighttpd 1.4.80

CVE-2025-12642 is a critical header smuggling flaw in lighttpd 1.4.80, fixed in 1.4.81. Upgrade, and review rules that trust request headers behind it.

Safeguard Security Team
4 min read

CVE-2025-12642 is a critical request smuggling weakness (CVSS 9.1) in lighttpd 1.4.80. The server merged HTTP trailer fields into the request headers after parsing. The upstream commit says the bug was introduced in 1.4.80 and fixed in 1.4.81, so upgrade to 1.4.81 or later.

What's affected

Only lighttpd 1.4.80 is named. The record says: "This issue affects lighttpd1.4.80". The upstream commit message confirms the scope: the bug was introduced in 1.4.80 and fixed in 1.4.81. Earlier releases are not described as affected, and 1.4.81 or later carries the fix.

The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. It is network reachable with no privileges, high confidentiality and integrity impact and no availability impact.

The record lists three possible consequences: bypassing access control rules, injecting unsafe input into backend logic that trusts request headers, and HTTP request smuggling under some conditions. The commit message narrows that last point. lighttpd's proxy module sends Connection: close to backends, so the commit says the bug is not exploitable to send additional requests to a backend that closes the connection properly. The remaining risk is that trailers could incorrectly change the request headers sent to the backend, which might bypass policy that checks those headers.

How to check if you're exposed

Check the version of every lighttpd binary you run:

lighttpd -v

If it reports 1.4.80, you are in range. Also check container images and appliances that bundle lighttpd, because the version is often hidden behind a product name. A package manager query helps on Linux hosts:

dpkg -l | grep lighttpd
rpm -qa | grep lighttpd

Then find out whether anything in your configuration depends on request headers for decisions. Look at access rules, proxy header handling and backends that trust headers set by the front server. The risk comes from the pairing of a vulnerable front end and a backend that trusts what it receives.

For images and repositories, run the free in-browser scan to see whether a 1.4.80 package is pulled in, and use the Gold page for CVE-2025-12642 for the record.

What to do now

  1. Upgrade lighttpd to 1.4.81 or later. This is the fix version named in the upstream commit message.
  2. Rebuild and redeploy container images and appliances that bundle lighttpd 1.4.80.
  3. Until the upgrade is done, review rules that allow or deny requests based on headers. Consider enforcing them in the backend as well.
  4. Confirm your proxy sends Connection: close to backends, as the upstream notes describe for mod_proxy, and that your backends honour it.
  5. Check your distribution's advisory if you use a packaged build, since backports may use different version strings.
  6. Add a version check for lighttpd to your monitoring so the next release note is a lookup.

Try it yourself

Click through it at your own pace, or open it full screen.

Why it matters

HTTP trailers are fields sent after the body of a chunked request. They are legal, but they are not meant to rewrite the request headers a server already parsed. The upstream change rejects disallowed trailers. The record classifies the flaw as CWE-444, inconsistent interpretation of HTTP requests, which is the family behind smuggling bugs: two components read the same request differently, and a policy applied by one is skipped by the other.

The impact depends on your architecture. If a backend trusts headers that the front end checked, a trailer that alters them can undermine the check. The record does not flag CVE-2025-12642 as a CISA Known Exploited Vulnerability and does not claim exploitation in the wild.

Quick check

Which lighttpd versions are affected and which is fixed?

The record names 1.4.80. The upstream commit says the bug was introduced in 1.4.80 and fixed in 1.4.81.

Does this let an attacker send extra requests to my backend?

The upstream commit says not when mod_proxy is used and the backend closes the connection after Connection: close. The main concern is modified headers that bypass policy.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

We email you a link to confirm, and only then add you to the list. Unsubscribe in one click. Privacy

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.