Security Resilience

CVE-2023-5363

Openssl 3.0.0 – 3.0.12

Published
25 October 2023
Modified
12 May 2026
Patch / advisory
CVSS Score v3.1 7.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score 0.033 88th percentile
Risk Priority 65 floored blend · peak EPSS

CVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.

Summary

CVE-2023-5363 is a high-severity Incorrect Provision of Specified Functionality (CWE-684) vulnerability in Openssl Openssl. Its CVSS base score is 7.5 (High).

Operationally, ranked in the top 12% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.

Deeper analysis AI-assisted summary

Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.

A bug in OpenSSL 3.0 and 3.1 affects the handling of key and initialization vector lengths when applications call EVP_EncryptInit_ex2, EVP_DecryptInit_ex2, or EVP_CipherInit_ex2. After the key and IV are initially set, any subsequent changes supplied through an OSSL_PARAM array using the "keylen" or "ivlen" parameters are ignored, producing truncation or overruns for the RC2, RC4, RC5, CCM, GCM, and OCB algorithms. The OpenSSL TLS stack and the FIPS providers are unaffected.

An unauthenticated remote attacker who can supply crafted OSSL_PARAM values to a vulnerable application may truncate the IV for GCM, CCM, or OCB, violating uniqueness requirements and enabling loss of confidentiality; the same conditions can also produce incorrect cryptographic results or memory faults from key or IV overruns. Because altering key or IV lengths after initialization is uncommon and the affected API is recent, the likelihood that an application actually exercises the vulnerable code path is assessed as low, although any such instance would be rated severe.

The OpenSSL project advisory and associated commits recommend upgrading to fixed versions that ensure length parameters supplied via OSSL_PARAM are processed before the key and IV are finalized. The referenced patches (commits 0df40630850fb2740e6be6890bb905d3fc623b2d and 5f69f5c65e483928c4b28ed16af6e5742929f1ee) implement the corrected ordering. EPSS scores have remained low and essentially flat since disclosure.

EU & UK References

Vulnerability Data

Issue summary: A bug has been identified in the processing of key and initialisation vector (IV) lengths. This can lead to potential truncation or overruns during the initialisation of some symmetric ciphers. Impact summary: A truncation in the IV can…

more

result in non-uniqueness, which could result in loss of confidentiality for some cipher modes. When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after the key and IV have been established. Any alterations to the key length, via the "keylen" parameter or the IV length, via the "ivlen" parameter, within the OSSL_PARAM array will not take effect as intended, potentially causing truncation or overreading of these values. The following ciphers and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB. For the CCM, GCM and OCB cipher modes, truncation of the IV can result in loss of confidentiality. For example, when following NIST's SP 800-38D section 8.2.1 guidance for constructing a deterministic IV for AES in GCM mode, truncation of the counter portion could lead to IV reuse. Both truncations and overruns of the key and overruns of the IV will produce incorrect results and could, in some cases, trigger a memory exception. However, these issues are not currently assessed as security critical. Changing the key and/or IV lengths is not considered to be a common operation and the vulnerable API was recently introduced. Furthermore it is likely that application developers will have spotted this problem during testing since decryption would fail unless both peers in the communication were similarly vulnerable. For these reasons we expect the probability of an application being vulnerable to this to be quite low. However if an application is vulnerable then this issue is considered very serious. For these reasons we have assessed this issue as Moderate severity overall. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because the issue lies outside of the FIPS provider boundary. OpenSSL 3.1 and 3.0 are vulnerable to this issue.

CWE(s)

Related Threats

CVEs Like This One

CVE-2023-2898Same product: Debian Debian Linux
CVE-2023-2124Same product: Debian Debian Linux
CVE-2023-26545Same product: Debian Debian Linux
CVE-2023-3111Same product: Debian Debian Linux
CVE-2023-2007Same product: Debian Debian Linux
CVE-2023-0045Same product: Debian Debian Linux
CVE-2024-33599Same product: Debian Debian Linux
CVE-2022-29155Same product: Debian Debian Linux
CVE-2023-4236Same product: Debian Debian Linux
CVE-2023-35788Same product: Debian Debian Linux

Affected Assets

openssl
openssl
3.0.0 — 3.0.12 · 3.1.0 — 3.1.4
debian
debian linux
12.0
netapp
h300s firmware
all versions
netapp
h410s firmware
all versions
netapp
h500s firmware
all versions
netapp
h700s firmware
all versions
netapp
h410c firmware
all versions

Mitigating Controls

Likely Mitigating Controls AI

Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.

addresses: CWE-684

Periodic checks confirm that specified security and privacy functions are actually provided and operating.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

blocks

A.8.25 requires that security be designed and implemented in the SDLC (including secure coding, requirements, testing and checkpoints), but does not itself stop incorrect functionality from being exploitable once the code is written and deployed; the weakness can still be present and reachable.

blocks

Explicit application security requirements and acceptance criteria help ensure the delivered software matches its intended specifications.

finds

Security testing in development and acceptance validates that implemented functionality conforms to specifications before release.

blocks

Change management processes reduce the chance of unintended functional deviations during updates, though they do not directly address initial specification conformance.

Hardening callouts derived

DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.

  • No fine-grained STIG row for CWE-684, a class-level weakness, and none of its children carries one either.

References