hyper

A protective and efficient HTTP library for all.

View on Cargo

Activity

Latest release: 3w ago
Total releases: 253
Cadence: ~34 days
Last 12 months: 8

Reach

Downloads: 978.7M

Details

License: MIT
First release: Nov 22, 2014

Releases

Version	Released
`1.12.0` minor	Oct 06, 2026
`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

1–50 of 253

Dependencies (31)

Depends on

1.12.0

Used by

6999

Supply-chain exposure

6,999 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (7)

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

https://github.com/hyperium/hyper/pull/2545
https://github.com/hyperium/hyper
https://rustsec.org/advisories/RUSTSEC-2022-0022.html

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2021-21299 GHSA-6hfq-h8hq-87mf RUSTSEC-2021-0020 Aug 25, 2021

HTTP Request Smuggling in hyper

4.8 / 10
Medium
Network High None None Unchanged Low Low None

Summary

hyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".

Vulnerability

The flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0.

Consider this example request:

POST /yolo HTTP/1.1 Transfer-Encoding: chunked Transfer-Encoding: cow

This request should be rejected, according to RFC 7230, since it has a Transfer-Encoding header, but after folding, it does not end in chunked. hyper would notice the chunked in the first line, and then check the second line, and thanks to a missing boolean assignment, not set the error condition. hyper would treat the payload as being chunked. 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".

There are several parts of the spec that must also be checked, and hyper correctly handles all of those. Additionally, hyper's client does not allow sending requests with improper headers, so the misunderstanding cannot be propagated further.

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. The client is not affected.

Using HTTP/1.1. HTTP/2 does not use transfer-encoding.

Using a vulnerable HTTP proxy upstream to hyper. If an upstream proxy correctly rejects the illegal transfer-encoding headers, the desync attack cannot succeed. If there is no proxy upstream of hyper, hyper cannot start the desync attack, as the client will repair the headers before forwarding.

Patches

We have released and backported the following patch versions:

v0.14.3

v0.13.10

Workarounds

Besides upgrading hyper, you can take the following options:

Reject requests that contain a transfer-encoding header.

Ensure any upstream proxy handles transfer-encoding correctly.

Credits

This issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.

Fixed in

0.12.360.13.100.14.3

References

https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf
https://nvd.nist.gov/vuln/detail/CVE-2021-21299
https://github.com/hyperium/hyper/commit/8f93123efef5c1361086688fe4f34c83c89cec02
https://github.com/hyperium/hyper
https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
https://rustsec.org/advisories/RUSTSEC-2021-0020.html

Updated Jul 08, 2026 · Source: OSV.dev
CVE-2020-35863 GHSA-h3qr-rq2j-74w4 RUSTSEC-2020-0008 Aug 25, 2021

HTTP Request Smuggling in hyper

9.8 / 10
Critical
Network Low None None Unchanged High High High

Vulnerable versions of hyper allow GET requests to have bodies, even if there is no Transfer-Encoding or Content-Length header. As per the HTTP 1.1 specification, such requests do not have bodies, so the body will be interpreted as a separate HTTP request.

This allows an attacker who can control the body and method of an HTTP request made by hyper to inject a request with headers that would not otherwise be allowed, as demonstrated by sending a malformed HTTP request from a Substrate runtime. This allows bypassing CORS restrictions. In combination with other vulnerabilities, such as an exploitable web server listening on loopback, it may allow remote code execution.

The flaw was corrected in hyper version 0.12.34.

Fixed in

0.12.34

References

https://nvd.nist.gov/vuln/detail/CVE-2020-35863
https://github.com/hyperium/hyper/issues/1925
https://github.com/hyperium/hyper
https://rustsec.org/advisories/RUSTSEC-2020-0008.html

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2016-10932 GHSA-9xjr-m6f3-v5wm RUSTSEC-2016-0002 Aug 25, 2021

HTTPS MitM vulnerability due to lack of hostname verification

4.8 / 10
Medium
Network High None None Unchanged Low Low None

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.

This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch.

The problem was addressed by leveraging rust-openssl's built-in support for hostname verification.

Fixed in

0.9.4

References

https://nvd.nist.gov/vuln/detail/CVE-2016-10932
https://github.com/hyperium/hyper/issues/472
https://github.com/hyperium/hyper/commit/01160abd92956e5f995cc45790df7a2b86c8989f
https://github.com/hyperium/hyper/blob/master/CHANGELOG.md#v094-2016-05-09
https://rustsec.org/advisories/RUSTSEC-2016-0002.html

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2017-18587 GHSA-q89x-f52w-6hj2 RUSTSEC-2017-0002 Aug 25, 2021

Headers containing newline characters can split messages in hyper

5.3 / 10
Medium
Network Low None None Unchanged None Low None

Serializing of headers to the socket did not filter the values for newline bytes (\r or \n), which allowed for header values to split a request or response. People would not likely include newlines in the headers in their own applications, so the way for most people to exploit this is if an application constructs headers based on unsanitized user input.

This issue was fixed by replacing all newline characters with a space during serialization of a header value.

Fixed in

0.9.180.10.2

References

https://nvd.nist.gov/vuln/detail/CVE-2017-18587
https://github.com/hyperium/hyper
https://github.com/hyperium/hyper/wiki/Security-001
https://rustsec.org/advisories/RUSTSEC-2017-0002.html

Updated Nov 08, 2023 · 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

https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
https://nvd.nist.gov/vuln/detail/CVE-2021-32714
https://github.com/hyperium/hyper
https://rustsec.org/advisories/RUSTSEC-2021-0079.html

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

https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
https://nvd.nist.gov/vuln/detail/CVE-2021-32715
https://github.com/rust-lang/rust/pull/28826/commits/123a83326fb95366e94a3be1a74775df4db97739
https://github.com/hyperium/hyper/commit/1fb719e0b61a4f3d911562a436a2ff05fd7cb759
https://github.com/hyperium/hyper
https://rustsec.org/advisories/RUSTSEC-2021-0078.html

Updated Sep 10, 2026 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

minor 1
patch 1
unknown 251

253 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More