CVE-2026-44662

What it actually does

rust-openssl versions 0.10.0 through 0.10.78 incorrectly calculate output buffer sizes in CipherCtxRef::cipher_update, CipherCtxRef::cipher_update_vec, and symm::Crypter::update when AES key-wrap-with-padding ciphers are used: EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, or EVP_aes_256_wrap_pad. If an attacker can influence a plaintext input length that is not a multiple of 8 bytes, OpenSSL may write up to 7 bytes beyond the end of the Rust caller’s buffer or Vec. The result is attacker-influenced heap corruption, which can cause process crashes, data corruption, or potentially limited integrity/availability impact depending on allocator behavior, surrounding heap layout, and how the vulnerable cryptographic operation is exposed by the application.

Why it matters to the business

Applications that use affected rust-openssl versions for AES key-wrap-with-padding operations may be vulnerable to crashes or unpredictable behavior when processing attacker-controlled input. The issue is narrow because it only affects specific AES wrap-pad cipher usage, has low EPSS, is not in the CISA KEV catalog, and currently has no known public exploit maturity, but the impact can still be operationally significant for services that unwrap or wrap externally supplied keys, tokens, encrypted payloads, or cryptographic material. Because the package is a common Rust OpenSSL binding, organizations should prioritize inventorying dependent applications and upgrading during normal patch cycles, with higher urgency for internet-facing or multi-tenant systems that process untrusted cryptographic input.

How an attack unfolds

An attacker first needs access to a code path in an application that uses rust-openssl 0.10.0 through 0.10.78 and invokes CipherCtxRef::cipher_update, CipherCtxRef::cipher_update_vec, or symm::Crypter::update with one of the AES key-wrap-with-padding EVP ciphers. The attacker then supplies or influences plaintext input whose length is not divisible by 8. During the update operation, the Rust binding allocates or expects an output buffer that is too small for OpenSSL’s actual output. OpenSSL can then write as many as 7 attacker-influenced bytes past the end of the buffer, corrupting adjacent heap memory. In practical exploitation, the most likely outcome is a denial-of-service crash or memory corruption-induced malfunction; reliable code execution would be highly context-dependent and is not indicated by currently available exploit intelligence.

How to fix it

Upgrade rust-openssl to version 0.10.79 or later. Regenerate lockfiles and rebuild all affected Rust applications, containers, and release artifacts so the fixed crate is actually included at runtime. If immediate upgrade is not possible, mitigate by avoiding AES key-wrap-with-padding ciphers through rust-openssl, validating that attacker-influenced plaintext lengths are multiples of 8 before invoking affected update functions, isolating services that process untrusted cryptographic material, and enabling process-level hardening such as allocator protections, crash supervision, and least-privilege execution. Transitive dependencies should be reviewed with cargo tree or software composition analysis tooling because applications may inherit rust-openssl indirectly.

How to confirm the fix worked

Confirm that Cargo.lock, SBOMs, and build artifacts no longer contain openssl crate versions 0.10.0 through 0.10.78 and instead use 0.10.79 or later. Use cargo tree -i openssl to identify dependency paths and cargo update -p openssl to refresh the crate where compatible. Rebuild and redeploy binaries and containers after dependency updates; checking source manifests alone is insufficient. For functional validation, test code paths that use AES wrap-pad ciphers with non-multiple-of-8 input under AddressSanitizer, Valgrind, Miri where applicable, or hardened allocator crash diagnostics to confirm no out-of-bounds write occurs. Review cryptographic code to verify whether EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, EVP_aes_256_wrap_pad, CipherCtxRef::cipher_update, CipherCtxRef::cipher_update_vec, or symm::Crypter::update are used with attacker-influenced lengths.

Typical attack path

1. Identify an application or service built with rust-openssl versions 0.10.0 through 0.10.78.
2. Determine whether the application exposes functionality using AES key-wrap-with-padding ciphers such as EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, or EVP_aes_256_wrap_pad.
3. Reach an input path where plaintext length is attacker-controlled or influenced before the AES wrap-pad operation.
4. Submit input with a length that is not a multiple of 8 bytes.
5. Trigger CipherCtxRef::cipher_update, CipherCtxRef::cipher_update_vec, or symm::Crypter::update to cause an undersized output buffer condition.
6. Cause heap memory corruption, potentially resulting in a crash, data corruption, or other process instability.

How to detect it

To determine whether this was already exploited, focus on applications known to use affected rust-openssl versions and AES key-wrap-with-padding operations. Review application logs, crash dumps, core files, container restart events, systemd journal entries, Kubernetes pod restart histories, and runtime security telemetry for crashes occurring during cryptographic key wrapping or unwrapping workflows. Look for allocator or sanitizer errors indicating heap buffer overflows, out-of-bounds writes, corrupted heap metadata, segmentation faults, aborts, or panics near rust-openssl/OpenSSL encryption update calls. Correlate crashes with requests or jobs containing unusually sized cryptographic inputs, especially plaintext lengths not divisible by 8. Source and dependency telemetry should be searched for vulnerable crate versions and use of EVP_aes_128_wrap_pad, EVP_aes_192_wrap_pad, EVP_aes_256_wrap_pad, CipherCtxRef::cipher_update, CipherCtxRef::cipher_update_vec, and symm::Crypter::update. There are no known public threat actors or ransomware campaigns associated with this vulnerability, so detection should be behavior- and artifact-based rather than actor-specific.

• openssl = "0.10.0"
• openssl = "0.10.78"
• name = "openssl"
• version = "0.10.78"
• CipherCtxRef::cipher_update
• CipherCtxRef::cipher_update_vec
• symm::Crypter::update
• EVP_aes_128_wrap_pad
• EVP_aes_192_wrap_pad
• EVP_aes_256_wrap_pad
• aes_128_wrap_pad
• aes_192_wrap_pad
• aes_256_wrap_pad
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• heap corruption
• corrupted size vs. prev_size
• malloc(): corrupted top size
• double free or corruption
• free(): invalid next size
• segmentation fault
• SIGSEGV
• SIGABRT

What your security team should do

• Inventory Rust applications and containers that include the openssl crate and flag versions 0.10.0 through 0.10.78.
• Prioritize remediation for services that process untrusted encrypted keys, wrapped keys, tokens, payloads, or customer-supplied cryptographic material.
• Upgrade rust-openssl to 0.10.79 or later, regenerate lockfiles, rebuild binaries, and redeploy affected artifacts.
• Search source repositories for AES key-wrap-with-padding usage and affected API calls to determine practical exploitability.
• Add regression tests or fuzzing for cryptographic input lengths, especially non-multiple-of-8 plaintext sizes, around AES wrap-pad operations.
• Monitor crash logs and memory-corruption signals in affected services until upgrades are complete.
• If upgrade timelines are delayed, add input-length validation or temporarily disable affected AES wrap-pad code paths exposed to untrusted input.