Skip to main content

rust-openssl CVE-2026-41678

HIGH
Out-of-bounds Write (CWE-787)
2026-04-22 https://github.com/rust-openssl/rust-openssl GHSA-8c75-8mhr-p7r9
7.2
CVSS 4.0 · Vendor: https://github.com/rust-openssl/rust-openssl
Share

Severity by source

Vendor (https://github.com/rust-openssl/rust-openssl) PRIMARY
7.2 HIGH
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
SUSE
7.4 HIGH
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

Primary rating from Vendor (https://github.com/rust-openssl/rust-openssl).

CVSS VectorVendor: https://github.com/rust-openssl/rust-openssl

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

6
Re-analysis Queued
Apr 24, 2026 - 18:22 vuln.today
cvss_changed
CVSS changed
Apr 24, 2026 - 18:22 NVD
7.2 (HIGH)
Analysis Generated
Apr 23, 2026 - 06:54 vuln.today
Analysis Generated
Apr 22, 2026 - 21:46 vuln.today
Patch released
Apr 22, 2026 - 21:46 nvd
Patch available
CVE Published
Apr 22, 2026 - 21:17 nvd
HIGH 7.2

DescriptionCVE.org

Summary

`aes::unwrap_key()` has an incorrect bounds assertion on the out buffer size, which can lead to out-of-bounds write.

Details

`aes::unwrap_key() 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.

AnalysisAI

Out-of-bounds memory write in rust-openssl's AES key unwrap function allows attackers who control buffer sizes to corrupt memory via safe API misuse. The aes::unwrap_key() function contains an inverted bounds assertion that accepts undersized output buffers and rejects correctly sized ones, causing the function to write beyond allocated memory by in_.len() - 8 - out.len() bytes. Vendor patch available via GitHub PR #2604 and commit 718d07ff, released in openssl-v0.10.78. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept at time of analysis, but the logic flaw is clearly documented in vendor advisory GHSA-8c75-8mhr-p7r9.

Technical ContextAI

The rust-openssl crate provides Rust bindings to the OpenSSL cryptographic library. AES Key Wrap (RFC 3394) is a deterministic authenticated encryption algorithm used to encrypt cryptographic key material. The vulnerable aes::unwrap_key() function implements the key unwrapping operation but contains a reversed bounds check assertion: it validates out.len() + 8 <= in_.len() when the correct invariant should be out.len() >= in_.len() - 8 (output buffer must be at least 8 bytes smaller than input). This maps to CWE-787 (Out-of-bounds Write), a memory safety vulnerability class. The inverted logic creates a double failure: it rejects safe buffer sizes while accepting dangerous undersized buffers, transforming a defensive assertion into an exploitability condition. Because this occurs in a safe Rust function (not marked unsafe), it violates Rust's memory safety guarantees at the API boundary.

RemediationAI

Upgrade rust-openssl to version 0.10.78 or later, released by the vendor with the corrected bounds assertion (https://github.com/rust-openssl/rust-openssl/releases/tag/openssl-v0.10.78). The fix is implemented in commit 718d07ff8ff7be417d5b7a6a0a0047f1607520b3b6 and merged via pull request #2604 (https://github.com/rust-openssl/rust-openssl/pull/2604). For applications that cannot immediately upgrade, implement strict validation of buffer sizes before calling aes::unwrap_key() by ensuring output buffer length exactly equals input buffer length minus 8 bytes (out.len() == in_.len() - 8), though this workaround still relies on the vulnerable function and should be considered temporary. Audit all code paths that call aes::unwrap_key() to verify buffer sizes are not derived from untrusted input. Review Cargo.lock to identify dependency chains that may transitively include vulnerable versions.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
Container suse/sl-micro/6.0/baremetal-os-container:latest Affected
Container suse/sl-micro/6.0/toolbox:latest Affected
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-Azure Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Fixed

Share

CVE-2026-41678 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy