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
18 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
CipherCtxRef::cipherupdateinplace incorrectly sized output buffers when used with AES key-wrap-with-padding ciphers (EVPaes{128,192,256}wrappad). For a non-multiple-of-8 input, OpenSSL writes up to 7 bytes past the end of the caller's buffer or Vec, producing attacker-controllable heap corruption when the plaintext length is attacker-influenced. This only impacts users using AES key-wrap-with-padding ciphers. This method was missed in the fix for GHSA-xv59-967r-8726
Recommended action: Upgrade to 0.10.80 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CipherCtxRef::cipherupdate, CipherCtxRef::cipherupdatevec, and symm::Crypter::update incorrectly sized output buffers when used with AES key-wrap-with-padding ciphers (EVPaes{128,192,256}wrappad). For a non-multiple-of-8 input, OpenSSL writes up to 7 bytes past the end of the caller's buffer or Vec, producing attacker-controllable heap corruption when the plaintext length is attacker-influenced. This only impacts users using AES key-wrap-with-padding ciphers.
Recommended action: Upgrade to 0.10.79 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
X509Ref::ocspresponders returns OCSP responder URLs from a certificate's AIA extension as OpensslString, whose Deref<Target = str wraps the raw bytes with str::fromutf8unchecked. OpenSSL does not enforce that the underlying IA5String is ASCII, so a certificate with non-UTF-8 bytes in its OCSP accessLocation causes safe Rust code to construct a &str that violates the UTF-8 invariant — resulting in undefined behavior.
Recommended action: Upgrade to 0.10.79 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deriver::derive (and PkeyCtxRef::derive) sets len = buf.len() and passes it as the in/out length to EVPPKEYderive, relying on OpenSSL to honor it. On OpenSSL 1.1.x, X25519, X448, DH and HKDF-extract ignore the incoming keylen, unconditionally writing the full shared secret (32/56/prime-size bytes). A caller passing a short slice gets a heap/stack overflow from safe code. OpenSSL 3.x providers do check, so this only impacts older OpenSSL.
Recommended action: Upgrade to 0.10.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The frompemcallback APIs did not validate the length returned by the user's callback. A password callback that returns a value larger than the buffer it was given can cause some versions of OpenSSL to over-read this buffer. OpenSSL 3.x is not affected by this.
Recommended action: Upgrade to 0.10.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
aes::unwrapkey() has an incorrect bounds assertion on the out buffer size, which can lead to out-of-bounds write. Details aes::unwrapkey() contains an incorrect assertion: it checks that out.len() + 8 <= in.len(), but this condition is reversed. The intended invariant is out.len() = in.len() - 8, ensuring the output buffer is large enough. Because of the inverted check, the function only accepts buffers at or below the minimum required size and rejects larger ones. If a smaller buffer is provided the function will write past the end of out by in.len() - 8 - out.len() bytes, causing an out-of-bounds write from a safe public function. Impact Vulnerable applications using AES keywrap and allowing attacker controlled buffer sizes could have an attacker trigger an out-of-bounds write.
Recommended action: Upgrade to 0.10.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
EVPDigestFinal() always writes EVPMDCTXsize(ctx) to the out buffer. If out is smaller than that, MdCtxRef::digestfinal() writes past its end, usually corrupting the stack. This is reachable from safe Rust.
Recommended action: Upgrade to 0.10.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The FFI trampolines behind SslContextBuilder::setpskclientcallback, setpskservercallback, setcookiegeneratecb, and setstatelesscookiegeneratecb forwarded the user closure's returned usize directly to OpenSSL without checking it against the &mut [u8] that was handed to the closure. This can lead to buffer overflows and other unintended consequences.
Recommended action: Upgrade to 0.10.78 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a Some(...) value was passed to the properties argument of either of these functions, a use-after-free would result. In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior). The maintainers thank quitbug for reporting this vulnerability to us.
Recommended action: Upgrade to 0.10.72 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact ssl::selectnextproto can return a slice pointing into the server argument's buffer but with a lifetime bound to the client argument. In situations where the server buffer's lifetime is shorter than the client buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client. Patches openssl 0.10.70 fixes the signature of ssl::selectnextproto to properly constrain the output buffer's lifetime to that of both input buffers. Workarounds In standard usage of ssl::selectnextproto in the callback passed to SslContextBuilder::setalpnselectcallback, code is only affected if the server buffer is constructed within the callback. For example: Not vulnerable - the server buffer has a 'static lifetime: Not vulnerable - the server buffer outlives the handshake: Vulnerable - the server buffer is freed when the callback returns: References https://github.com/sfackler/rust-openssl/pull/2360
Recommended action: Upgrade to 0.10.70 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Previously, MemBio::getbuf called slice::fromrawparts with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.
Recommended action: Upgrade to 0.10.66 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This function returned a reference into an OpenSSL datastructure, but there was no way to ensure OpenSSL would not mutate the datastructure behind one's back. Use of this function should be replaced with X509StoreRef::allcertificates.
Recommended action: Upgrade to 0.10.60 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When this function was passed an empty string, openssl would attempt to call strlen on it, reading arbitrary memory until it reached a NUL byte.
Recommended action: Upgrade to 0.10.55 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenSSL has a modified bit that it can set on on X509NAME objects. If this bit is set then the object is not thread-safe even when it appears the code is not modifying the value. Thanks to David Benjamin (Google) for reporting this issue.
Recommended action: Upgrade to 0.10.48 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SubjectAlternativeName and ExtendedKeyUsage arguments were parsed using the OpenSSL function X509V3EXTnconf. This function parses all input using an OpenSSL mini-language which can perform arbitrary file reads. Thanks to David Benjamin (Google) for reporting this issue.
Recommended action: Upgrade to 0.10.48 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
These functions would crash when the context argument was None with certain extension types. Thanks to David Benjamin (Google) for reporting this issue.
Recommended action: Upgrade to 0.10.48 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the openssl crate before 0.10.9 for Rust. A use-after-free occurs in CMS Signing.
Recommended action: Upgrade to 0.10.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All versions of rust-openssl prior to 0.9.0 contained numerous insecure defaults including off-by-default certificate verification and no API to perform hostname verification. Unless configured correctly by a developer, these defaults could allow an attacker to perform man-in-the-middle attacks. The problem was addressed in newer versions by enabling certificate verification by default and exposing APIs to perform hostname verification. Use the SslConnector and SslAcceptor types to take advantage of these new features (as opposed to the lower-level SslContext type).
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.