Cyber 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

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-26545Same product: Debian Debian Linux
CVE-2023-3111Same product: Debian Debian Linux
CVE-2023-2124Same product: Debian Debian Linux
CVE-2023-2898Same product: Debian Debian Linux
CVE-2024-33599Same product: Debian Debian Linux
CVE-2023-0045Same product: Debian Debian Linux
CVE-2023-2007Same product: Debian Debian Linux
CVE-2022-29155Same product: Debian Debian Linux
CVE-2023-2269Same product: Debian Debian Linux
CVE-2023-4236Same 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

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)
  • 1 hardening rule · 1 OS baseline
Validate
Prove the fix (OWASP ASVS)

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 (NIST CSF 2.0) AI

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

PR.PS-06 mostly match
prevents

Secure SDLC practices directly enforce spec-compliant functionality and testing, while eliminating this weakness fulfills only part of the control's broader monitoring intent.

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.

finds

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

prevents

Secure development life cycle includes requirements and verification activities that directly reduce the risk of delivering functionality that deviates from published specifications.

prevents

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

prevents

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

Hardening callouts derived

Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).

RHEL 9 (1 rule)
  • V-258078 RHEL 9 must use a Linux Security Module configured to enforce limits on system services. prevents CWE-684

References