CVE-2026-45784: rust-openssl Buffer Overflow Vulnerability

CVE-2026-45784 Overview

CVE-2026-45784 is a heap buffer overflow vulnerability in rust-openssl, the crate that provides OpenSSL bindings for the Rust programming language. The flaw resides in CipherCtxRef::cipher_update_inplace within openssl/src/cipher_ctx.rs and affects versions 0.10.50 through 0.10.79. When callers use AES key-wrap-with-padding ciphers (EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, EVP_aes_256_wrap_pad) with an input length that is not a multiple of 8, OpenSSL writes up to 7 bytes past the end of the caller's buffer. The issue is fixed in version 0.10.80 and is classified under [CWE-131] (Incorrect Calculation of Buffer Size).

Critical Impact
Attacker-influenced plaintext lengths can trigger heap corruption in any Rust process linking a vulnerable version of rust-openssl and using AES wrap-pad ciphers.

Affected Products

rust-openssl crate versions 0.10.50 through 0.10.79
Rust applications invoking CipherCtxRef::cipher_update_inplace with EVP_aes_{128,192,256}_wrap_pad
Downstream crates and binaries statically linking a vulnerable openssl dependency

Discovery Timeline

2026-07-17 - CVE-2026-45784 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-45784

Vulnerability Analysis

The defect is an incorrect output-buffer size calculation in the in-place cipher update path. cipher_update_inplace asserted that the caller's buffer was at least inlen + block_size bytes. For AES key-wrap-with-padding, OpenSSL reports a block size of 8, but the actual output for a non-multiple-of-8 input is inlen rounded up to the next multiple of 8, then padded with an 8-byte integrity check value. The required output can therefore exceed inlen + block_size by up to 7 bytes, so OpenSSL writes past the end of the caller's &mut [u8] or Vec<u8>.

Because cipher_update_inplace operates on caller-provided heap memory, the overflow corrupts adjacent heap allocations. When the plaintext length is influenced by an attacker, the resulting write is bounded but controllable in both offset and content, producing a classic heap corruption primitive.

Root Cause

The root cause is that OpenSSL's EVP_CIPHER_block_size returns a value that does not reflect the true output size requirement of wrap-pad ciphers. The Rust wrapper trusted this value when validating buffer capacity. The fix replaces the ad-hoc calculation with cipher_update_output_size(inlen), which correctly accounts for wrap-pad behavior.

Attack Vector

Exploitation requires a local context in which an attacker can influence the length of plaintext passed to a Rust application performing AES key wrap with padding through rust-openssl. Suitable targets include key management daemons, credential vaults, and secure enclaves that key-wrap attacker-supplied secrets. No authentication or user interaction is required beyond reaching the vulnerable API surface.

rust

// Patch from openssl/src/cipher_ctx.rs (rust-openssl commit 19eceb2)
    inlen: usize,
) -> Result<usize, ErrorStack> {
    assert!(inlen <= data.len(), "Input size may not exceed buffer size");
-   let block_size = self.block_size();
-   if block_size != 1 {
-       assert!(
-           data.len() >= inlen + block_size,
-           "Output buffer size must be at least {} bytes.",
-           inlen + block_size
-       );
-   }
+   let min_output_size = self.cipher_update_output_size(inlen);
+   assert!(
+       data.len() >= min_output_size,
+       "Output buffer size must be at least {} bytes.",
+       min_output_size
+   );

    let inlen = c_int::try_from(inlen).unwrap();
    let mut outlen = 0;

Source: rust-openssl commit 19eceb2

Detection Methods for CVE-2026-45784

Indicators of Compromise

Unexpected process crashes or SIGABRT signals from Rust binaries linking openssl at a version between 0.10.50 and 0.10.79
Heap corruption reports from allocator hardening features such as glibc's MALLOC_CHECK_ or scudo in Rust services performing AES key wrapping
Presence of openssl = "0.10.x" with x < 80 in Cargo.lock for shipped binaries

Detection Strategies

Scan Cargo.lock and SBOM artifacts across the fleet for openssl crate versions 0.10.50 through 0.10.79
Audit source code for calls to CipherCtxRef::cipher_update_inplace combined with Cipher::aes_128_wrap_pad, aes_192_wrap_pad, or aes_256_wrap_pad
Correlate crash telemetry from EDR or crash reporters with processes matching the affected crate signature

Monitoring Recommendations

Monitor for repeated abnormal terminations of key management or cryptographic services that could indicate probing for the overflow
Enable heap allocator diagnostics in staging builds to surface out-of-bounds writes before production exposure
Track newly built container images and packages for the vulnerable dependency range in your CI/CD pipeline

How to Mitigate CVE-2026-45784

Immediate Actions Required

Upgrade the openssl crate to 0.10.80 or later and rebuild all downstream Rust artifacts
Inventory production binaries for the vulnerable version range and prioritize services that perform AES key wrapping
Restrict attacker influence over plaintext length passed to key-wrap operations until patched builds are deployed

Patch Information

The fix is available in rust-openssl v0.10.80 and is tracked in GHSA-phqj-4mhp-q6mq. See the corresponding pull request discussion for review context. Update Cargo.toml to require openssl = ">=0.10.80" and run cargo update -p openssl.

Workarounds

Avoid cipher_update_inplace for aes_*_wrap_pad ciphers and use the non-in-place cipher_update variant with a suitably oversized output buffer
Round caller-provided buffers up to ((inlen + 7) & !7) + 8 bytes before invoking the vulnerable API to absorb the overflow
Reject or normalize inputs whose length is not a multiple of 8 before passing them to key-wrap routines

bash

# Update the vulnerable dependency
cargo update -p openssl --precise 0.10.80

# Verify no vulnerable versions remain in the dependency tree
cargo tree -i openssl | grep -E 'openssl v0\.10\.(5[0-9]|6[0-9]|7[0-9])'