CVE-2026-41678

What it actually does

The flaw is an out-of-bounds write in the rust-openssl crate's safe public AES key unwrap API, aes::unwrap_key(), before version 0.10.78. The function validates the relationship between the input and output buffer lengths incorrectly: it accepts output buffers that are too small and rejects buffers that are sufficiently large. When called with an input buffer requiring in_.len() - 8 bytes of output but an output buffer shorter than that, the function can write past the end of the output buffer. Because this is reachable through a safe Rust API, applications may be exposed without using unsafe Rust directly. Depending on allocator layout, compiler settings, and surrounding application behavior, the result can range from process crash and denial of service to memory corruption with possible integrity or confidentiality impact.

Why it matters to the business

Applications that use affected versions of rust-openssl for AES key unwrapping may be vulnerable to crashes or memory corruption when processing attacker-influenced wrapped keys or key material. The highest-risk systems are services that accept encrypted keys, tokens, credentials, certificates, messages, or key-management inputs from untrusted users or external systems. Although the EPSS score is currently low, no known exploitation is reported, and it is not in the CISA KEV catalog, the CVSS severity is high because successful exploitation can affect confidentiality, integrity, and availability. Organizations with many Rust services or downstream dependencies using rust-openssl should treat this as a supply-chain remediation item and upgrade promptly.

How an attack unfolds

An attacker first identifies an application path that invokes rust-openssl's aes::unwrap_key() on data the attacker can influence, such as submitted wrapped keys, encrypted payload metadata, imported key blobs, or protocol messages. The vulnerable condition requires the application to call the API with an output buffer that is smaller than the required unwrapped size. If the application derives that output buffer length from attacker-controlled or incorrectly trusted metadata, the attacker can craft input where the function writes beyond the end of the output buffer. The immediate observable result may be a service crash. In more favorable memory-layout conditions, the overwrite could corrupt adjacent memory and potentially alter application behavior. There is no public exploit maturity indicated, and practical exploitability is likely to depend heavily on how each application sizes buffers around the API.

How to fix it

Upgrade the Rust openssl crate used by affected applications to version 0.10.78 or later. Regenerate dependency lockfiles and rebuild all affected binaries, containers, serverless artifacts, and packaged releases so the fixed crate is actually included at runtime. Use cargo update -p openssl --precise 0.10.78 where appropriate, or update Cargo.toml constraints to allow 0.10.78 or newer. If direct upgrade is temporarily blocked, avoid calling aes::unwrap_key() with output buffers whose length is less than input length minus 8, and add explicit precondition checks before every call. Treat this mitigation as temporary because downstream or transitive usage may still be difficult to audit completely.

How to confirm the fix worked

Confirm that no deployed build includes rust-openssl openssl crate versions earlier than 0.10.78. Review Cargo.lock files for the openssl package version, run cargo tree -i openssl to identify direct and transitive dependents, and verify software composition analysis results for compiled artifacts and container images. Add or run regression tests that call AES key unwrap with output buffers smaller than, equal to, and larger than the required size; fixed versions should reject undersized buffers and accept correctly sized or larger buffers without memory corruption. For critical services, rebuild from a clean dependency cache and verify the final artifact bill of materials shows openssl >= 0.10.78.

Typical attack path

1. Find an externally reachable feature that imports, unwraps, decrypts, or processes AES-wrapped key material using rust-openssl.
2. Send crafted wrapped-key input or metadata that causes the application to allocate or pass an undersized output buffer to aes::unwrap_key().
3. Trigger the vulnerable function so it writes in_.len() - 8 - out.len() bytes beyond the output buffer.
4. Observe process instability, crashes, corrupted responses, or service restarts as signs of memory corruption.
5. Iterate inputs to improve reliability; in favorable conditions, attempt to influence adjacent memory and escalate from denial of service to broader compromise.

How to detect it

There are no universal network indicators for this vulnerability because exploitation occurs inside an application-specific library call and payloads depend on the protocol or feature that passes data into AES key unwrap. To look for prior exploitation, review application logs for malformed wrapped-key imports, decryption/key unwrap failures followed by crashes, abrupt process termination, segmentation faults, allocator corruption messages, container restarts, core dumps, and unusual spikes in 4xx/5xx responses on endpoints that process encrypted keys or key material. Useful sources include application logs, API gateway logs, authentication/key-management service logs, systemd or init logs, Kubernetes pod restart history, container runtime logs, crash dumps, EDR process telemetry, and SIEM events around service instability. Correlate suspicious requests with process crashes or restarts occurring immediately afterward. If core dumps are available, inspect stack traces for rust-openssl/OpenSSL AES unwrap paths and memory corruption near unwrap_key execution. Absence of these signs does not prove non-exploitation, because memory corruption may be silent or crash reporting may be disabled.

What your security team should do

• Inventory Rust applications and libraries that depend on the openssl crate from rust-openssl, including transitive dependencies.
• Prioritize externally exposed services, key-management workflows, authentication systems, certificate-processing services, encrypted messaging paths, and APIs that process user-supplied wrapped key material.
• Upgrade affected dependencies to openssl crate version 0.10.78 or later, rebuild, redeploy, and confirm the fixed version in SBOMs and lockfiles.
• Add CI/CD dependency policy checks that fail builds using rust-openssl openssl crate versions earlier than 0.10.78.
• Review application code for aes::unwrap_key() usage and ensure output buffer lengths are validated as at least input length minus 8 before invocation.
• Monitor crash telemetry, service restarts, allocator errors, and malformed key-import requests for signs of attempted exploitation, especially on internet-facing services.
• Because there is no reported KEV status, ransomware association, or public exploit maturity, prioritize based on exposure and use of the vulnerable API rather than CVSS alone.