Lenient Parsing of Content-Length Header When Prefixed with Plus Sign

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with `rustc` v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the `Content-Length` header or ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.

Source published

7 Jul 2021 20:05:11 UTC

Source modified

3 Aug 2024 23:25:31 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 3.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with `rustc` v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the `Content-Length` header or ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.

Source published

Jul 7, 2021, 8:05:11 PM (timezone not stated)

Source modified

Aug 3, 2024, 11:25:31 PM (timezone not stated)

Observed here

9 Nov 2026 22:11:53 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 3.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with `rustc` v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the `Content-Length` header or ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.

Source published

7 Jul 2021 20:15:08 UTC

Source modified

17 Jun 2026 03:53:29 UTC

Observed here

24 Oct 2026 18:17:28 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 3.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

CVSS 3.1 · [email protected] · Primary · 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

CVSS 2.0 · [email protected] · Primary · 4.3 AV:N/AC:M/Au:N/C:N/I:P/A:N

### Summary hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a `Content-Length` header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such `Content-Length` headers, but forwards them, can result in "request smuggling" or "desync attacks". ### Vulnerability The flaw exists in all prior versions of hyper, if built with [`rustc` v1.5.0 or newer](https://github.com/rust-lang/rust/pull/28826/commits/123a83326fb95366e94a3be1a74775df4db97739). Example: ``` GET / HTTP/1.1 Host: example.com Content-Length: +3 abc ``` This request gets accepted and hyper reads the body as abc. The request _should_ be rejected, according to RFC 7230, since the ABNF for `Content-Length` only allows for `DIGIT`s. This is due to using the `FromStr` implementation for `u64` in the standard library. By differing from the spec, it is possible to send requests like these to endpoints that have different HTTP implementations, with different interpretations of the payload semantics, and cause "desync attacks". In this particular case, an upstream proxy would need to error when parsing the `Content-Length`, but _not_ reject the request (swallowing its own error), and forwarding the request as-is with the `Content-Length` still included. _Then_ the upstream proxy and hyper would disagree on the length of the request body. The combination of these factors would be extremely rare. Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn ### Impact To determine if vulnerable, all these things must be true: - **Using hyper as an HTTP server**. While the lenient decoder also exists in the client, a vulnerability does not exist around _responses_. - **Using HTTP/1**. The HTTP/2 code uses a stricter parser. - **Using a vulnerable HTTP proxy upstream to hyper**. If an upstream proxy correctly rejects the illegal `Content-Length` header, *OR* can parse the length with the plus sign, the desync attack cannot succeed. ### Patches We have released the following patch versions: - v0.14.10 (to be released when this advisor is published) ### Workarounds Besides upgrading hyper, you can take the following options: - Reject requests manually that contain a plus sign prefix in the `Content-Length` header. - Ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix. ### Credits This issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.

Source published

12 Jul 2021 16:54:20 UTC

Source modified

10 Sep 2026 03:49:06 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

Publisher rating · LOW

`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers. Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error. To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.

Source published

7 Jul 2021 12:00:00 UTC

Source modified

12 Oct 2026 18:00:03 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N