Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 0.14.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.14.3, 0.13.10 or 0.12.36 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.12.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.10.2 or 0.9.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.14.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.14.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.