What is the CVSS score of CVE-2026-41678?

CVE-2026-41678 has a CVSS 4.0 base score of 7.2 (High). CVSS vector: 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. EPSS exploitation probability: 0.0%.

How to fix or mitigate CVE-2026-41678?

Within 24 hours: Identify all applications and services using rust-openssl and document current versions in use. Within 7 days: Upgrade rust-openssl to version 0.10.78 or later across all affected systems; validate the upgrade through staging environment testing. Within 30 days: Verify patch deployment completion across all production infrastructure and retire any systems unable to upgrade.

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

Buffer Overflow Memory Corruption Suse

7.2

CVSS 4.0 · Vendor: https://github.com/rust-openssl/rust-openssl

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Recon

Identify Rust service using rust-openssl < 0.10.78
Delivery

Craft malicious AES-wrapped key input
Exploit

Manipulate application logic to allocate undersized output buffer
Install

Trigger aes::unwrap_key() call with attacker-controlled sizes
C2

Out-of-bounds write corrupts heap memory
Execute

Overwrite critical memory structures
Impact

Achieve code execution or privilege escalation

Vulnerability Assessment

Weakness	CWE CWE-787 ASVS 5.0 V15 - Secure Coding and Architecture Bounds checking, write limits MITRE ATT&CK 2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Exploitation requires the application to use the aes::unwrap_key() function from rust-openssl versions prior to 0.10.78 AND allow attacker influence over buffer size parameters passed to this function. Specifically, the attacker must cause the application to allocate an output buffer smaller than in_.len() - 8 bytes while the inverted assertion still passes (out.len() + 8 <= in_.len()). This typically requires the application to derive buffer sizes from untrusted input such as API parameters, file metadata, or protocol fields rather than using fixed cryptographic key sizes. The vulnerability exists in safe Rust code, so standard Rust memory safety does not prevent exploitation. Limits on exploitation: applications using fixed-size buffers for standard key sizes (128/192/256-bit AES keys) are not vulnerable; applications that validate buffer sizes independently before calling the function may prevent exploitation; heap layout and allocator behavior affect reliability of memory corruption exploitation.
Impact	Real-world risk is moderate and highly context-dependent. The vulnerability requires attacker control over buffer size parameters passed to aes::unwrap_key(), which is not a common attack surface in most applications - key unwrapping typically operates on fixed-size cryptographic material from trusted sources. No CVSS vector is provided, but the vulnerability characteristics suggest CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (local attack vector, high complexity due to requiring specific buffer size control, low privileges). No EPSS score available. Absence from CISA KEV and lack of public POC indicate no observed exploitation. However, the clear documentation in the vendor advisory and straightforward nature of the bounds check error means exploit development is trivial once an attacker-controlled code path is identified. Primary risk is to applications that allow external input to influence buffer allocation for cryptographic operations, particularly in server-side Rust services handling untrusted cryptographic material. The patch is available and the fix is a simple assertion correction, making remediation straightforward.
Exploit ScenarioDerived	An attacker identifies a Rust web service that uses rust-openssl for key management and accepts encrypted key material via API. The attacker crafts a malicious request containing an AES-wrapped key (input buffer) and manipulates application logic to allocate an undersized output buffer for the unwrapped key - for example, by exploiting integer truncation in size calculation or providing malformed metadata. When the application calls aes::unwrap_key() with the attacker-controlled buffer sizes, the inverted assertion passes validation and the function writes unwrapped key bytes beyond the allocated output buffer, corrupting adjacent heap memory. The attacker leverages this memory corruption to overwrite function pointers, vtable entries, or other critical data structures, ultimately achieving code execution or privilege escalation within the service context.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Apr 23, 2026

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.

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.

Affected Packages

cargo openssl fix: 0.10.78

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in cargo

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when the next one hits your stack

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

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

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

Attack Requirements

Present

Privileges Required

None

User Interaction

None

Vulnerable system: Confidentiality

High

Vulnerable system: Integrity

High

Vulnerable system: Availability

High

Subsequent system: Confidentiality

None

Subsequent system: Integrity

None

Subsequent system: Availability

None

Lifecycle Timeline

CVSS changed

Apr 24, 2026 - 18:22 NVD

7.2 (HIGH)

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.

Executive ViewAI

Why It Matters

CVE-2026-41678 is a memory corruption vulnerability in rust-openssl's AES key unwrap function that allows attackers with control over buffer sizes to trigger out-of-bounds writes, potentially enabling code execution or denial of service in applications using this cryptographic function. Organizations running rust-openssl versions prior to 0.10.78 should prioritize patching to eliminate this memory safety risk in a widely-used cryptographic library.

Business Impact: High

Compensating Controls

Apply vendor patch. Vendor-released patch: openssl-v0.10.78 (GitHub commit 718d07ff). Until patching is complete, restrict use of the aes::unwrap_key() function or implement external input validation to reject undersized output buffers before calling the vulnerable function.

Threat Intelligence Overview

EPSS Score

0.0%

Top 87% exploitable

Threat Intel

1 source

Data Quality

6 sources

Confidence: High

NVD

CVE.org

EPSS

Vulnrichment GHSA Vendor

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.0%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision

Scheduled

Exploitation

None

System Exposure· derived

Open

Automatable

Human Impact

High

Technical Impact

Total

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +36

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Buffer Overflow HIGH

A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.

Memory Corruption HIGH

Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.

Affected Products (CPE)CVE.org

pkg:rust/openssl

Same weakness CWE-787 – Out-of-bounds Write

View all

CVE-2015-3113 CRITICAL POC

9.8

CVE-2011-2462 CRITICAL POC

9.8

CVE-2012-1889 HIGH POC

8.8

CVE-2010-3333 HIGH POC

7.8

CVE-2014-1761 HIGH POC

7.8

CVE-2009-3129 HIGH POC

7.8

CVE-2021-1732 HIGH POC

7.8

CVE-2013-3346 CRITICAL POC

9.8

Same technique Buffer Overflow

View all

CVE-2017-7269 CRITICAL POC

9.8

CVE-2015-5119 CRITICAL POC

9.8

CVE-2020-0796 CRITICAL POC

10.0

CVE-2019-11043 CRITICAL POC

9.8

CVE-2009-0927 HIGH POC

8.8

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

References

Advisories & patches

Search Externally

GitHub PoC

Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC

Back