hyper

Version	Released
`1.11.1` patch	Aug 28, 2026
`1.11.0` unknown	Jul 20, 2026
`1.10.1` unknown	May 29, 2026
`1.10.0` unknown	May 27, 2026
`1.9.0` unknown	Mar 31, 2026
`1.8.1` unknown	Nov 13, 2025
`1.8.0` unknown	Nov 11, 2025
`1.7.0` unknown	Aug 18, 2025
`1.6.0` unknown	Jan 28, 2025
`1.5.2` unknown	Dec 16, 2024
`0.14.32` unknown	Dec 16, 2024
`1.5.1` unknown	Nov 19, 2024
`1.5.0` unknown	Oct 15, 2024
`0.14.31` unknown	Oct 15, 2024
`1.4.1` unknown	Jul 09, 2024
`0.14.30` unknown	Jul 09, 2024
`1.4.0` unknown	Jul 01, 2024
`0.14.29` unknown	Jun 03, 2024
`1.3.1` unknown	Apr 16, 2024
`1.3.0` unknown	Apr 15, 2024
`1.2.0` unknown	Feb 21, 2024
`1.1.0` unknown	Dec 18, 2023
`0.14.28` unknown	Dec 18, 2023
`1.0.1` unknown	Nov 16, 2023
`1.0.0` unknown	Nov 15, 2023
`1.0.0-rc.4` unknown	Jul 10, 2023
`0.14.27` unknown	Jun 26, 2023
`0.14.26` unknown	Apr 13, 2023
`0.14.25` unknown	Mar 10, 2023
`1.0.0-rc.3` unknown	Feb 23, 2023
`0.14.24` unknown	Feb 02, 2023
`1.0.0-rc.2` unknown	Dec 29, 2022
`0.14.23` unknown	Nov 07, 2022
`0.14.22` unknown	Oct 31, 2022
`0.14.21` unknown	Oct 31, 2022
`1.0.0-rc.1` unknown	Oct 26, 2022
`0.14.20` unknown	Jul 07, 2022
`0.14.19` unknown	May 27, 2022
`0.14.18` unknown	Mar 22, 2022
`0.14.17` unknown	Feb 10, 2022
`0.14.16` unknown	Dec 09, 2021
`0.14.15` unknown	Nov 16, 2021
`0.14.14` unknown	Oct 22, 2021
`0.14.13` unknown	Sep 16, 2021
`0.14.12` unknown	Aug 24, 2021
`0.14.11` unknown 1 CVE	Jul 21, 2021
`0.14.10` unknown 1 CVE	Jul 07, 2021
`0.14.9` unknown 3 CVEs	Jun 07, 2021
`0.14.8` unknown 3 CVEs	May 25, 2021
`0.14.7` unknown 3 CVEs	Apr 22, 2021

1.11.1 patch

Aug 28, 2026

1.11.0 unknown

Jul 20, 2026

1.10.1 unknown

May 29, 2026

1.10.0 unknown

May 27, 2026

1.9.0 unknown

Mar 31, 2026

1.8.1 unknown

Nov 13, 2025

1.8.0 unknown

Nov 11, 2025

1.7.0 unknown

Aug 18, 2025

1.6.0 unknown

Jan 28, 2025

1.5.2 unknown

Dec 16, 2024

0.14.32 unknown

Dec 16, 2024

1.5.1 unknown

Nov 19, 2024

1.5.0 unknown

Oct 15, 2024

0.14.31 unknown

Oct 15, 2024

1.4.1 unknown

Jul 09, 2024

0.14.30 unknown

Jul 09, 2024

1.4.0 unknown

Jul 01, 2024

0.14.29 unknown

Jun 03, 2024

1.3.1 unknown

Apr 16, 2024

1.3.0 unknown

Apr 15, 2024

1.2.0 unknown

Feb 21, 2024

1.1.0 unknown

Dec 18, 2023

0.14.28 unknown

Dec 18, 2023

1.0.1 unknown

Nov 16, 2023

1.0.0 unknown

Nov 15, 2023

1.0.0-rc.4 unknown

Jul 10, 2023

0.14.27 unknown

Jun 26, 2023

0.14.26 unknown

Apr 13, 2023

0.14.25 unknown

Mar 10, 2023

1.0.0-rc.3 unknown

Feb 23, 2023

0.14.24 unknown

Feb 02, 2023

1.0.0-rc.2 unknown

Dec 29, 2022

0.14.23 unknown

Nov 07, 2022

0.14.22 unknown

Oct 31, 2022

0.14.21 unknown

Oct 31, 2022

1.0.0-rc.1 unknown

Oct 26, 2022

0.14.20 unknown

Jul 07, 2022

0.14.19 unknown

May 27, 2022

0.14.18 unknown

Mar 22, 2022

0.14.17 unknown

Feb 10, 2022

0.14.16 unknown

Dec 09, 2021

0.14.15 unknown

Nov 16, 2021

0.14.14 unknown

Oct 22, 2021

0.14.13 unknown

Sep 16, 2021

0.14.12 unknown

Aug 24, 2021

0.14.11 unknown

1 CVE

Jul 21, 2021

0.14.10 unknown

1 CVE

Jul 07, 2021

0.14.9 unknown

3 CVEs

GHSA-f67m-9j94-qv9j RUSTSEC-2022-0022 Jun 16, 2022

Parser creates invalid uninitialized value

High

Affected versions of this crate called mem::uninitialized() in the HTTP1 parser to create values of type httparse::Header (from the httparse crate). This is unsound, since Header contains references and thus must be non-null.

The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.

Fixed in


          0.14.12

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32714 GHSA-5h46-h7hh-c6x9 RUSTSEC-2021-0079 Jul 12, 2021

Integer Overflow in Chunked Transfer-Encoding

5.9 / 10

Medium

Network High None None Unchanged None None High

Summary

hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks".

Vulnerability

Example:

GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

f0000000000000003
abc
0

hyper only reads the rightmost 64-bit integer as the chunk size. So it reads f0000000000000003 as 3. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Impact

To determine if vulnerable to data loss, these things must be true:

Using HTTP/1.1. Since HTTP/2 does not use chunked encoding, it is not vulnerable.
Using hyper as a server or client. The body would be improperly truncated in either case.
Users send requests or responses with chunk sizes greater than 18 exabytes.

To determine if vulnerable to desync attacks, these things must be true:

Using an upstream proxy that allows chunks sizes larger than 64-bit. If the proxy rejects chunk sizes that are too large, that request won't be forwarded to hyper.

Patches

We have released the following patch versions:

v0.14.10 (to be released when this advisory is published)

Workarounds

Besides upgrading hyper, you can take the following options:

Reject requests manually that contain a Transfer-Encoding header.
Ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

Credits

This issue was initially reported by Mattias Grenfeldt and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32715 GHSA-f3pg-qwvg-p99c RUSTSEC-2021-0078 Jul 12, 2021

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

3.1 / 10

Low

Network High None Required Unchanged Low None None

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.

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 DIGITs. 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 and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

Jun 07, 2021

0.14.8 unknown

3 CVEs

GHSA-f67m-9j94-qv9j RUSTSEC-2022-0022 Jun 16, 2022

Parser creates invalid uninitialized value

High

Affected versions of this crate called mem::uninitialized() in the HTTP1 parser to create values of type httparse::Header (from the httparse crate). This is unsound, since Header contains references and thus must be non-null.

The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.

Fixed in


          0.14.12

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32714 GHSA-5h46-h7hh-c6x9 RUSTSEC-2021-0079 Jul 12, 2021

Integer Overflow in Chunked Transfer-Encoding

5.9 / 10

Medium

Network High None None Unchanged None None High

Summary

hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks".

Vulnerability

Example:

GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

f0000000000000003
abc
0

hyper only reads the rightmost 64-bit integer as the chunk size. So it reads f0000000000000003 as 3. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Impact

To determine if vulnerable to data loss, these things must be true:

Using HTTP/1.1. Since HTTP/2 does not use chunked encoding, it is not vulnerable.
Using hyper as a server or client. The body would be improperly truncated in either case.
Users send requests or responses with chunk sizes greater than 18 exabytes.

To determine if vulnerable to desync attacks, these things must be true:

Using an upstream proxy that allows chunks sizes larger than 64-bit. If the proxy rejects chunk sizes that are too large, that request won't be forwarded to hyper.

Patches

We have released the following patch versions:

v0.14.10 (to be released when this advisory is published)

Workarounds

Besides upgrading hyper, you can take the following options:

Reject requests manually that contain a Transfer-Encoding header.
Ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

Credits

This issue was initially reported by Mattias Grenfeldt and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32715 GHSA-f3pg-qwvg-p99c RUSTSEC-2021-0078 Jul 12, 2021

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

3.1 / 10

Low

Network High None Required Unchanged Low None None

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.

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 DIGITs. 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 and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

May 25, 2021

0.14.7 unknown

3 CVEs

GHSA-f67m-9j94-qv9j RUSTSEC-2022-0022 Jun 16, 2022

Parser creates invalid uninitialized value

High

Affected versions of this crate called mem::uninitialized() in the HTTP1 parser to create values of type httparse::Header (from the httparse crate). This is unsound, since Header contains references and thus must be non-null.

The flaw was corrected by avoiding the use of mem::uninitialized(), using MaybeUninit instead.

Fixed in


          0.14.12

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32714 GHSA-5h46-h7hh-c6x9 RUSTSEC-2021-0079 Jul 12, 2021

Integer Overflow in Chunked Transfer-Encoding

5.9 / 10

Medium

Network High None None Unchanged None None High

Summary

hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks".

Vulnerability

Example:

GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

f0000000000000003
abc
0

hyper only reads the rightmost 64-bit integer as the chunk size. So it reads f0000000000000003 as 3. A loss of data can occur since hyper would then read only 3 bytes of the body. Additionally, an HTTP request smuggling vulnerability would occur if using a proxy which instead has prefix truncation in the chunk size, or that understands larger than 64-bit chunk sizes.

Read more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Impact

To determine if vulnerable to data loss, these things must be true:

Using HTTP/1.1. Since HTTP/2 does not use chunked encoding, it is not vulnerable.
Using hyper as a server or client. The body would be improperly truncated in either case.
Users send requests or responses with chunk sizes greater than 18 exabytes.

To determine if vulnerable to desync attacks, these things must be true:

Using an upstream proxy that allows chunks sizes larger than 64-bit. If the proxy rejects chunk sizes that are too large, that request won't be forwarded to hyper.

Patches

We have released the following patch versions:

v0.14.10 (to be released when this advisory is published)

Workarounds

Besides upgrading hyper, you can take the following options:

Reject requests manually that contain a Transfer-Encoding header.
Ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

Credits

This issue was initially reported by Mattias Grenfeldt and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2021-32715 GHSA-f3pg-qwvg-p99c RUSTSEC-2021-0078 Jul 12, 2021

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

3.1 / 10

Low

Network High None Required Unchanged Low None None

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.

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 DIGITs. 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 and Asta Olofsson.

Fixed in


          0.14.10

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 22, 2021

Activity

Details