{"ecosystem":"cargo","package":"hyper","version":null,"bugs":[{"id":867,"ecosystem":"cargo","package_name":"hyper","affected_version":null,"fixed_version":"0.14.12","bug_id":"osv:GHSA-f67m-9j94-qv9j","title":"Parser creates invalid uninitialized value","description":"Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate).\nThis is unsound, since `Header` contains references and thus must be non-null.\n \nThe flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.\n","severity":"high","status":"fixed","source":"osv","source_url":"https://github.com/hyperium/hyper/pull/2545","labels":["RUSTSEC-2022-0022"],"created_at":"2026-04-19T04:32:02.540806+00:00","updated_at":"2026-04-19T04:32:02.540806+00:00"},{"id":876,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.0.0-0","fixed_version":"0.14.12","bug_id":"osv:RUSTSEC-2022-0022","title":"Parser creates invalid uninitialized value","description":"Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate).\nThis is unsound, since `Header` contains references and thus must be non-null.\n \nThe flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["GHSA-f67m-9j94-qv9j"],"created_at":"2026-04-19T04:32:02.546107+00:00","updated_at":"2026-04-19T04:32:02.546107+00:00"},{"id":875,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.0.0-0","fixed_version":"0.14.10","bug_id":"osv:RUSTSEC-2021-0079","title":"Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss","description":"When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,\nthis could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.\n\nTo be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send\nrequests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,\nany upstream proxies must accept a chunk size greater than 64 bits.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2021-32714","GHSA-5h46-h7hh-c6x9"],"created_at":"2026-04-19T04:32:02.545621+00:00","updated_at":"2026-04-19T04:32:02.545621+00:00"},{"id":874,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.0.0-0","fixed_version":"0.14.10","bug_id":"osv:RUSTSEC-2021-0078","title":"Lenient `hyper` header parsing of `Content-Length` could allow request smuggling","description":"`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.\nDue to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.\n\nTo be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents\nbut still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2021-32715","GHSA-f3pg-qwvg-p99c"],"created_at":"2026-04-19T04:32:02.545113+00:00","updated_at":"2026-04-19T04:32:02.545113+00:00"},{"id":873,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.14.0-0","fixed_version":"0.14.3","bug_id":"osv:RUSTSEC-2021-0020","title":"Multiple Transfer-Encoding headers misinterprets request payload","description":"hyper's HTTP server code had a flaw that incorrectly understands some requests\nwith multiple transfer-encoding headers to have a chunked payload, when it\nshould have been rejected as illegal. This combined with an upstream HTTP proxy\nthat understands the request payload boundary differently can result in\n\"request smuggling\" or \"desync attacks\".","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2021-21299","GHSA-6hfq-h8hq-87mf"],"created_at":"2026-04-19T04:32:02.544627+00:00","updated_at":"2026-04-19T04:32:02.544627+00:00"},{"id":872,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.11.0","fixed_version":"0.12.34","bug_id":"osv:RUSTSEC-2020-0008","title":"Flaw in hyper allows request smuggling by sending a body in GET requests","description":"Vulnerable versions of hyper allow GET requests to have bodies, even if there is\nno Transfer-Encoding or Content-Length header.  As per the HTTP 1.1\nspecification, such requests do not have bodies, so the body will be interpreted\nas a separate HTTP request.\n\nThis allows an attacker who can control the body and method of an HTTP request\nmade by hyper to inject a request with headers that would not otherwise be\nallowed, as demonstrated by sending a malformed HTTP request from a Substrate\nruntime.  This allows bypassing CORS restrictions.  In combination with other\nvulnerabilities, such as an exploitable web server listening on loopback, it may\nallow remote code execution.\n\nThe flaw was corrected in hyper version 0.12.34.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2020-35863","GHSA-h3qr-rq2j-74w4"],"created_at":"2026-04-19T04:32:02.544116+00:00","updated_at":"2026-04-19T04:32:02.544116+00:00"},{"id":871,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.10.0","fixed_version":"0.10.2","bug_id":"osv:RUSTSEC-2017-0002","title":"headers containing newline characters can split messages","description":"Serializing of headers to the socket did not filter the values for newline bytes (`\\r` or `\\n`),\nwhich allowed for header values to split a request or response. People would not likely include\nnewlines in the headers in their own applications, so the way for most people to exploit this\nis if an application constructs headers based on unsanitized user input.\n\nThis issue was fixed by replacing all newline characters with a space during serialization of\na header value.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2017-18587","GHSA-q89x-f52w-6hj2"],"created_at":"2026-04-19T04:32:02.543425+00:00","updated_at":"2026-04-19T04:32:02.543425+00:00"},{"id":870,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.0.0-0","fixed_version":"0.9.4","bug_id":"osv:RUSTSEC-2016-0002","title":"HTTPS MitM vulnerability due to lack of hostname verification","description":"When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not\nperform hostname verification when making HTTPS requests.\n\nThis allows an attacker to perform MitM attacks by preventing any valid\nCA-issued certificate, even if there's a hostname mismatch.\n\nThe problem was addressed by leveraging rust-openssl's built-in support for\nhostname verification.","severity":"medium","status":"fixed","source":"osv","source_url":"https://crates.io/crates/hyper","labels":["CVE-2016-10932","GHSA-9xjr-m6f3-v5wm"],"created_at":"2026-04-19T04:32:02.542701+00:00","updated_at":"2026-04-19T04:32:02.542701+00:00"},{"id":869,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.10.0","fixed_version":"0.10.2","bug_id":"osv:GHSA-q89x-f52w-6hj2","title":"Headers containing newline characters can split messages in hyper","description":"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.\n\nThis issue was fixed by replacing all newline characters with a space during serialization of a header value.","severity":"medium","status":"fixed","source":"osv","source_url":"https://nvd.nist.gov/vuln/detail/CVE-2017-18587","labels":["CVE-2017-18587","RUSTSEC-2017-0002"],"created_at":"2026-04-19T04:32:02.541926+00:00","updated_at":"2026-04-19T04:32:02.541926+00:00"},{"id":865,"ecosystem":"cargo","package_name":"hyper","affected_version":null,"fixed_version":"0.9.4","bug_id":"osv:GHSA-9xjr-m6f3-v5wm","title":"HTTPS MitM vulnerability due to lack of hostname verification","description":"When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.\n\nThis allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch.\n\nThe problem was addressed by leveraging rust-openssl's built-in support for hostname verification.","severity":"medium","status":"fixed","source":"osv","source_url":"https://nvd.nist.gov/vuln/detail/CVE-2016-10932","labels":["CVE-2016-10932","RUSTSEC-2016-0002"],"created_at":"2026-04-19T04:32:02.539722+00:00","updated_at":"2026-04-19T04:32:02.539722+00:00"},{"id":864,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.14.0","fixed_version":"0.14.3","bug_id":"osv:GHSA-6hfq-h8hq-87mf","title":"HTTP Request Smuggling in hyper","description":"### Summary\n\nhyper'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\".\n\n### Vulnerability\n\nThe flaw was introduced in https://github.com/hyperium/hyper/commit/26417fc24a7d05df538e0f39239b373c5c3d61f6, released in v0.12.0.\n\nConsider this example request:\n\n```\nPOST /yolo HTTP/1.1\nTransfer-Encoding: chunked\nTransfer-Encoding: cow\n```\n\nThis 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\".\n\nThere 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.\n\nRead more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn\n\n### Impact\n\nTo determine if vulnerable, all these things must be true:\n\n- **Using hyper as an HTTP *server*.** The client is not affected.\n- **Using HTTP/1.1.** HTTP/2 does not use `transfer-encoding`.\n- **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.\n\n### Patches\n\nWe have released and backported the following patch versions:\n\n- v0.14.3\n- v0.13.10\n\n### Workarounds\n\nBesides upgrading hyper, you can take the following options:\n\n- Reject requests that contain a `transfer-encoding` header.\n- Ensure any upstream proxy handles `transfer-encoding` correctly.\n\n### Credits\n\nThis issue was initially reported by ZeddYu Lu From Qi An Xin Technology Research Institute.","severity":"medium","status":"fixed","source":"osv","source_url":"https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf","labels":["CVE-2021-21299","RUSTSEC-2021-0020"],"created_at":"2026-04-19T04:32:02.539116+00:00","updated_at":"2026-04-19T04:32:02.539116+00:00"},{"id":863,"ecosystem":"cargo","package_name":"hyper","affected_version":null,"fixed_version":"0.14.10","bug_id":"osv:GHSA-5h46-h7hh-c6x9","title":"Integer Overflow in Chunked Transfer-Encoding","description":"### Summary\n\nhyper'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\".\n\n### Vulnerability\n\nExample:\n\n```\nGET / HTTP/1.1\nHost: example.com\nTransfer-Encoding: chunked\n\nf0000000000000003\nabc\n0\n\n```\n\nhyper 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.\n\nRead more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn\n\n### Impact\n\nTo determine if vulnerable to _data loss_, these things must be true:\n\n- **Using HTTP/1.1.** Since HTTP/2 does not use chunked encoding, it is not vulnerable.\n- **Using hyper as a server or client.** The body would be improperly truncated in either case.\n- **Users send requests or responses with chunk sizes greater than 18 exabytes**.\n\nTo determine if vulnerable to _desync attacks_, these things must be true:\n\n- **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.\n\n### Patches\n\nWe have released the following patch versions:\n\n - v0.14.10 (to be released when this advisory is published)\n\n### Workarounds\n\nBesides upgrading hyper, you can take the following options:\n\n- Reject requests manually that contain a `Transfer-Encoding` header.\n- Ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.\n\n\n### Credits\nThis issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.","severity":"medium","status":"fixed","source":"osv","source_url":"https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9","labels":["CVE-2021-32714","RUSTSEC-2021-0079"],"created_at":"2026-04-19T04:32:02.538027+00:00","updated_at":"2026-04-19T04:32:02.538027+00:00"},{"id":866,"ecosystem":"cargo","package_name":"hyper","affected_version":null,"fixed_version":"0.14.10","bug_id":"osv:GHSA-f3pg-qwvg-p99c","title":"Lenient Parsing of Content-Length Header When Prefixed with Plus Sign","description":"### Summary\n\nhyper'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\".\n\n### Vulnerability\n\nThe 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).\n\nExample:\n\n```\nGET / HTTP/1.1\nHost: example.com\nContent-Length: +3\n\nabc\n```\n\nThis 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\".\n\nIn 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.\n\nRead more about desync attacks: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn\n\n### Impact\n\nTo determine if vulnerable, all these things must be true:\n\n- **Using hyper as an HTTP server**. While the lenient decoder also exists in the client, a vulnerability does not exist around _responses_.\n- **Using HTTP/1**. The HTTP/2 code uses a stricter parser.\n- **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.\n\n### Patches\n\nWe have released the following patch versions:\n\n- v0.14.10 (to be released when this advisor is published)\n\n### Workarounds\n\nBesides upgrading hyper, you can take the following options:\n\n- Reject requests manually that contain a plus sign prefix in the `Content-Length` header.\n- Ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix.\n\n### Credits\nThis issue was initially reported by [Mattias Grenfeldt](https://grenfeldt.dev/) and Asta Olofsson.","severity":"low","status":"fixed","source":"osv","source_url":"https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c","labels":["CVE-2021-32715","RUSTSEC-2021-0078"],"created_at":"2026-04-19T04:32:02.540237+00:00","updated_at":"2026-04-19T04:32:02.540237+00:00"},{"id":868,"ecosystem":"cargo","package_name":"hyper","affected_version":"0.11.0","fixed_version":"0.12.34","bug_id":"osv:GHSA-h3qr-rq2j-74w4","title":"HTTP Request Smuggling in hyper","description":"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.\n\nThis 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.\n\nThe flaw was corrected in hyper version 0.12.34.","severity":"critical","status":"fixed","source":"osv","source_url":"https://nvd.nist.gov/vuln/detail/CVE-2020-35863","labels":["CVE-2020-35863","RUSTSEC-2020-0008"],"created_at":"2026-04-19T04:32:02.541364+00:00","updated_at":"2026-04-19T04:32:02.541364+00:00"}],"total":14,"_cache":"miss"}