CVE-2026-95692OpenSSL out-of-bounds read
CVE-2026-95692 is a out-of-bounds read in OpenSSL, not yet scored.
Why this priority: Not scored yet, and no exploitation signal.
Published · Updated · NVD status: Awaiting Analysis
What it is
Code reads past the end of a buffer, leaking memory contents or crashing.
How it is reached
The record does not say yet how the flaw is reached; the description below is the best guide until it is scored.
What an attacker gains
Its impact has not been scored yet. In practice, this kind of flaw lets an attacker crash the process, read memory, or in the worst case run code.
Is it being exploited?
There is no public report of exploitation yet.
What to do
- Upgrade OpenSSL to a fixed version for your release line (4.1.1, 4.0.4, 3.5.10).
Description from NVD
Issue summary: Setting an AES-GCM-SIV IV shorter than the expected nonce length via EVP_CipherInit_ex() may trigger a heap out-of-bounds read. Supplying a longer IV is silently truncated instead of rejected.
Impact summary: An application passing a caller-supplied IV of the wrong length may crash or read beyond its buffer. Because trailing IV bytes are ignored, an attacker who knows one message and tag may forge messages under a different IV.
CWE: CWE-125: Out-of-bounds Read
Description: AES-GCM-SIV copies the caller-supplied IV or nonce into its internal state using a copy whose length is taken from the expected nonce size rather than from the length the caller actually provided. When the caller passes a shorter IV, the copy reads past the end of the caller's buffer; AddressSanitizer confirms a heap out-of-bounds read reached through EVP_CipherInit_ex() into ossl_aes_gcm_siv_init(). When the caller passes a longer IV, the implementation silently discards the trailing bytes instead of rejecting the length.
The truncation breaks the binding between the IV and the computed authentication tag. An attacker who has observed a message and its tag under one IV can produce a message and tag that verify under a different IV whose first bytes match, since the surplus bytes never influence the computation. The message itself is unchanged, so this is a failure of IV commitment rather than a classic existential forgery.
Only applications that call EVP_CipherInit_ex() (or the equivalent provider cipher initialization) with an IV length other than the standard 12 bytes for AES-GCM-SIV are affected. The severity is limited because the out-of-bounds read is small and attacker-controlled only in length, and the forgery requires an unusual IV length choice by the application.
FIPS impact: no The FIPS modules are not affected by this issue, as AES-GCM-SIV is not an approved algorithm.
What this means for your architecture.
A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.
Components it touches
- Native code: operating systems, browsers and firmware. The flaw sits wherever native code reads untrusted data.
- Network appliances and media or file parsers. The flaw sits wherever native code reads untrusted data.
Trust boundaries in play
- Wherever native code reads untrusted data. An attacker who crosses it can crash the process, read memory, or in the worst case run code.
Questions to answer about your own systems
- Where does OpenSSL run in your systems, and at which version?
- Which of those instances are reachable by people you do not trust?
- What can it reach once compromised: which data stores, secrets and services?
Read more
Sources
- CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
- Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
- Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
- Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.