Add advisory for kawa Transfer-Encoding request smuggling (fixed in 0.7.0)

[UncleJ4ck]

Affected crate(s)

• kawa (37,218 all-time downloads, 3,660 recent per crates.io). It is the HTTP/1
  parser used by the sozu reverse proxy (65,795 all-time downloads), so the affected
  position is a proxy front end.

Links to upstream issue(s) or PR(s)

• Upstream fix: fix(h1): require chunked as the final transfer-coding, trim OWS CleverCloud/kawa#19 (merged 2026-07-15), plus
  follow-up fix(h1): exclude surrounding OWS from header field values CleverCloud/kawa#21
• Released in kawa https://github.com/CleverCloud/kawa/releases/tag/v0.7.0 and v0.7.1
• sozu 2.2.0 depends on kawa ^0.7.1; its release notes describe the change as
  "HTTP/1 Transfer-Encoding smuggling hardening"
• Original issue this regressed from: Handling of content-length/transfer-encoding allows request smuggling sozu-proxy/sozu#726
  (the fix commit's own code comment states it closes this issue)

Reported privately to security@clever.cloud on 2026-07-10, the contact published in
Clever Cloud's .well-known/security.txt, with a full write-up and a self-contained
reproduction. I received no reply, but the maintainers fixed and shipped it four days
later. There is currently no GHSA, no CVE, and no RustSec entry.

Severity

HTTP request smuggling (CWE-444) at a proxy front end.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (7.5).

kawa selected chunked framing with a suffix-only comparison on the raw
Transfer-Encoding value, with no OWS trim and no requirement that chunked be the
final transfer-coding:

const CHUNKED: &[u8] = b"chunked";
if val.len() >= CHUNKED.len()
    && compare_no_case(&val[val.len() - CHUNKED.len()..], CHUNKED)

So chunked\t, chunked and chunked,identity did not select chunked framing. With a
Content-Length also present, kawa framed by Content-Length and forwarded the
Transfer-Encoding header unchanged instead of rejecting the message (RFC 9112 6.3). A
stricter downstream server frames the same message as chunked, which desynchronizes the
two and lets an attacker prepend bytes to the next request on a reused back end
connection, bypassing authentication or ACLs enforced only at the proxy.

Affected: all published versions before 0.7.0. Verified empirically on 0.6.8 via sozu
2.1.0 and 2.1.1. The unfixed handling is present by inspection in 0.6.5, 0.6.7 and 0.6.8;
0.6.3 and earlier use an exact-match compare that likewise neither normalizes nor rejects
an obfuscated value.

Checklist

• Advisory filename(s) starts with RUSTSEC-0000-0000 as the ID
• date field is set to the public disclosure date (2026-07-15, the kawa 0.7.0
  release that shipped the fix publicly)
• Contains a concise and descriptive title after advisory metadata
• Asked maintainer(s) if publishing an advisory is appropriate

On the last item: I reported privately to the documented security contact and got no
reply in 32 days, though the fix shipped. Following @djc's note, I am now asking the kawa
maintainers directly on their fix PR for approval, and will link their response here.

I could not run rustsec-admin lint locally (it requires rustc 1.96, this machine has
1.94), so I validated by hand against the README template and RUSTSEC-2021-0078. The
"Lint advisories" CI job passes. Happy to adjust anything.

[djc]

Please use the pull request template. In particular, we'll need approval from one of the maintainers.

[UncleJ4ck]

Following up on the maintainer-approval point: I have now asked the kawa maintainers directly on their fix PR, CleverCloud/kawa#19 (comment CleverCloud/kawa#19 (comment)), for a word on whether an advisory is appropriate and to confirm the report. I will link their reply here as soon as there is one.