CVE-2023-5363 is a high-severity OpenSSL vulnerability, disclosed in October 2023, in which key and initialization vector (IV) length parameters are processed after the cipher is already keyed, potentially truncating the IV or overrunning the key. In plain terms, CVE-2023-5363 means that under specific API usage, OpenSSL can silently use a shorter IV than the caller requested, and IV reuse breaks the confidentiality guarantees of several cipher modes. It carries a CVSS score of 7.5 (High).
What actually goes wrong
The bug lives in how OpenSSL handles the OSSL_PARAM array passed to the newer cipher-init functions. When an application calls EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2(), or EVP_CipherInit_ex2() and supplies a key or IV length through that parameter array, the parameters are processed after the key and IV have already been established. A change to the IV length made this way can therefore truncate the IV, and a change to the key length can cause a read overrun.
The affected ciphers and modes are RC2, RC4, RC5, CCM, GCM, and OCB. The practical worry is IV truncation in the AEAD modes: GCM, CCM, and OCB all depend on IV uniqueness for security. If the IV is silently shortened, distinct messages can end up sharing an effective IV, and IV reuse in GCM in particular is catastrophic for confidentiality.
Who is affected by CVE-2023-5363
The bug affects OpenSSL 3.0 and OpenSSL 3.1. Several important carve-outs narrow the real-world blast radius:
- The SSL/TLS implementation is not affected. OpenSSL's own TLS stack does not trigger the vulnerable path, so a stock HTTPS server using OpenSSL for TLS is not exposed through this CVE.
- The FIPS providers for 3.0 and 3.1 are not affected, because the issue sits outside the FIPS provider boundary.
- You are exposed only if your application code sets a non-default key or IV length via the
OSSL_PARAMarray on one of the newer*_ex2init functions.
That last point matters. This is primarily a risk for applications that do their own symmetric crypto with custom IV lengths, not for the average service that terminates TLS and nothing else.
A concrete example of the risky pattern
The vulnerable shape is code that establishes the cipher and then tries to change the IV length through parameters:
/* Illustrative: setting IV length via OSSL_PARAM after init on a
vulnerable OpenSSL build can truncate the IV for GCM. */
OSSL_PARAM params[2];
params[0] = OSSL_PARAM_construct_size_t("ivlen", &ivlen);
params[1] = OSSL_PARAM_construct_end();
EVP_CipherInit_ex2(ctx, cipher, key, iv, 1, params);
If your code never touches key or IV length through OSSL_PARAM, and uses default lengths, you will not hit the truncation. But relying on that by inspection is fragile; patching removes the question entirely.
How to fix it
The fix is a straightforward version upgrade:
- OpenSSL 3.0 users should upgrade to OpenSSL 3.0.12.
- OpenSSL 3.1 users should upgrade to OpenSSL 3.1.4.
Because OpenSSL is almost always a transitive dependency (bundled in language runtimes, base images, and system packages) rather than something you install directly, the harder part is finding every copy. A single host can carry the system libssl, a statically linked copy inside an application binary, and another copy inside a container base layer.
# Check the version your shell openssl reports
openssl version
# Find shared libraries on the host
find / -name 'libssl.so*' 2>/dev/null
That distributed footprint is exactly why a software composition analysis tool that walks container layers and language lockfiles is more reliable than manual openssl version checks. An SCA tool such as Safeguard can flag CVE-2023-5363 in bundled copies you would not find by hand.
Prioritization: is this an emergency?
For most organizations, CVE-2023-5363 is a "patch on the normal cadence" item rather than a drop-everything emergency, precisely because TLS and FIPS paths are unaffected and the trigger requires a specific coding pattern. The exceptions are products that implement custom symmetric encryption (VPNs, storage encryption layers, messaging apps) using the 3.0/3.1 *_ex2 APIs with configurable IV lengths. Those should be assessed and patched with priority, and their crypto code reviewed for IV reuse.
FAQ
What is the CVSS score of CVE-2023-5363?
It is rated 7.5, which is High severity. The impact is loss of confidentiality for certain cipher modes rather than remote code execution.
Which OpenSSL versions are affected by CVE-2023-5363?
OpenSSL 3.0 and 3.1. Fixes shipped in 3.0.12 and 3.1.4 respectively. The FIPS providers and the TLS implementation are not affected.
Does CVE-2023-5363 affect my HTTPS server?
Not through TLS. OpenSSL's SSL/TLS implementation does not trigger the vulnerable code path. You are only exposed if your own application sets custom key or IV lengths via OSSL_PARAM on the newer cipher-init functions.
How do I find every vulnerable copy of OpenSSL?
Do not rely on openssl version alone. OpenSSL is frequently statically linked or bundled in container layers, so scan lockfiles and image layers with a composition analysis tool to catch copies a host-level check misses.