OpenSSL up to 4.0.2 Record Layer improper validation of specified quantity in input

Summaryinfo

A vulnerability identified as problematic has been detected in OpenSSL up to 3.0.22/3.4.7/3.5.8/3.6.4/4.0.2. This affects an unknown function of the component Record Layer. Performing a manipulation results in improper validation of specified quantity in input. This vulnerability is identified as CVE-2026-75806. The attack can be initiated remotely. There is not any exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in OpenSSL up to 3.0.22/3.4.7/3.5.8/3.6.4/4.0.2. It has been classified as problematic. This affects some unknown functionality of the component Record Layer. The manipulation with an unknown input leads to a improper validation of specified quantity in input vulnerability. CWE is classifying the issue as CWE-1284. The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties. This is going to have an impact on availability. The summary by CVE is:

Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.

The advisory is shared at openssl-library.org. This vulnerability is uniquely identified as CVE-2026-75806 since 08/18/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 09/29/2026).

Upgrading to version 1.1.1zj, 3.0.23, 3.4.8, 3.5.9, 3.6.5 or 4.0.3 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Network Encryption Software

Name

• OpenSSL

Version

• 3.0.0
• 3.0.1
• 3.0.2
• 3.0.3
• 3.0.4
• 3.0.5
• 3.0.6
• 3.0.7
• 3.0.8
• 3.0.9
• 3.0.10
• 3.0.11
• 3.0.12
• 3.0.13
• 3.0.14
• 3.0.15
• 3.0.16
• 3.0.17
• 3.0.18
• 3.0.19
• 3.0.20
• 3.0.21
• 3.0.22
• 3.4.0
• 3.4.1
• 3.4.2
• 3.4.3
• 3.4.4
• 3.4.5
• 3.4.6
• 3.4.7
• 3.5.0
• 3.5.1
• 3.5.2
• 3.5.3
• 3.5.4
• 3.5.5
• 3.5.6
• 3.5.7
• 3.5.8
• 3.6.0
• 3.6.1
• 3.6.2
• 3.6.3
• 3.6.4
• 4.0.0
• 4.0.1
• 4.0.2

License

• open-source

Website

• Product: https://www.openssl.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion