Re: OpenSSL Security Advisory (corrected - added CVE-2026-22795 and CVE-2026-22796)

[Demi Marie Obenour <demiobenour () gmail com>]

On 1/27/26 10:48, Tomas Mraz wrote:
> OpenSSL Security Advisory [27th January 2026]
> =============================================
>
> Improper validation of PBMAC1 parameters in PKCS#12 MAC verification (CVE-2025-11187)
> =====================================================================================
>
> Severity: Moderate
>
> Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation
> which can trigger a stack-based buffer overflow, invalid pointer or NULL
> pointer dereference during MAC verification.
>
> Impact summary: The stack buffer overflow or NULL pointer dereference may
> cause a crash leading to Denial of Service for an application that parses
> untrusted PKCS#12 files. The buffer overflow may also potentially enable
> code execution depending on platform mitigations.
>
> When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2
> salt and keylength parameters from the file are used without validation.
> If the value of keylength exceeds the size of the fixed stack buffer used
> for the derived key (64 bytes), the key derivation will overflow the buffer.
> The overflow length is attacker-controlled. Also, if the salt parameter is
> not an OCTET STRING type this can lead to invalid or NULL pointer
> dereference.
>
> Exploiting this issue requires a user or application to process
> a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted
> PKCS#12 files in applications as they are usually used to store private
> keys which are trusted by definition. For this reason the issue was assessed
> as Moderate severity.

I would not at all be surprised if using untrusted private keys is
not uncommon.  It can be easier to upload a key pair and certificate
than to download a CSR, sign it, and then upload the certificates.

Also, programs may well assume that the PKCS#12 authenticated
encryption is sufficient to mitigate risks from an untrusted file.

> Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-15467)
> =======================================================================
>
> Severity: High
>
> Issue summary: Parsing CMS AuthEnvelopedData message with maliciously
> crafted AEAD parameters can trigger a stack buffer overflow.
>
> Impact summary: A stack buffer overflow may lead to a crash, causing Denial
> of Service, or potentially remote code execution.
>
> When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as
> AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is
> copied into a fixed-size stack buffer without verifying that its length fits
> the destination. An attacker can supply a crafted CMS message with an
> oversized IV, causing a stack-based out-of-bounds write before any
> authentication or tag verification occurs.
>
> Applications and services that parse untrusted CMS or PKCS#7 content using
> AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable.
> Because the overflow occurs prior to authentication, no valid key material
> is required to trigger it. While exploitability to remote code execution
> depends on platform and toolchain mitigations, the stack-based write
> primitive represents a severe risk.

If an application calls PKCS7_d2i() and then checks a signature,
is it affected?

> Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion (CVE-2025-69419)
> ==================================================================================
>
> Severity: Low
>
> Issue summary: Calling PKCS12_get_friendlyname() function on a maliciously
> crafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containing
> non-ASCII BMP code point can trigger a one byte write before the allocated
> buffer.
>
> Impact summary: The out-of-bounds write can cause a memory corruption
> which can have various consequences including a Denial of Service.
>
> The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12
> BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,
> the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16
> source byte count as the destination buffer capacity to UTF8_putc(). For BMP
> code points above U+07FF, UTF-8 requires three bytes, but the forwarded
> capacity can be just two bytes. UTF8_putc() then returns -1, and this negative
> value is added to the output length without validation, causing the
> length to become negative. The subsequent trailing NUL byte is then written
> at a negative offset, causing write outside of heap allocated buffer.
>
> The vulnerability is reachable via the public PKCS12_get_friendlyname() API
> when parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses a
> different code path that avoids this issue, PKCS12_get_friendlyname() directly
> invokes the vulnerable function. Exploitation requires an attacker to provide
> a malicious PKCS#12 file to be parsed by the application and the attacker
> can just trigger a one zero byte write before the allocated buffer.
> For that reason the issue was assessed as Low severity according to our
> Security Policy.

One byte out of bound writes have been exploited before.
See https://projectzero.google/2016/12/chrome-os-exploit-one-byte-overflow-and.html

> Missing ASN1_TYPE validation in TS_RESP_verify_response() function (CVE-2025-69420)
> ===================================================================================
>
> Severity: Low
>
> Issue summary: A type confusion vulnerability exists in the TimeStamp Response
> verification code where an ASN1_TYPE union member is accessed without first
> validating the type, causing an invalid or NULL pointer dereference when
> processing a malformed TimeStamp Response file.
>
> Impact summary: An application calling TS_RESP_verify_response() with a
> malformed TimeStamp Response can be caused to dereference an invalid or
> NULL pointer when reading, resulting in a Denial of Service.
>
> The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()
> access the signing cert attribute value without validating its type.
> When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory
> through the ASN1_TYPE union, causing a crash.

Is the data read from the bad pointer returned to the caller?

> Missing ASN1_TYPE validation in PKCS#12 parsing (CVE-2026-22795)
> ================================================================
>
> Severity: Low
>
> Issue summary: An invalid or NULL pointer dereference can happen in
> an application processing a malformed PKCS#12 file.
>
> Impact summary: An application processing a malformed PKCS#12 file can be
> caused to dereference an invalid or NULL pointer on memory read, resulting
> in a Denial of Service.
>
> A type confusion vulnerability exists in PKCS#12 parsing code where
> an ASN1_TYPE union member is accessed without first validating the type,
> causing an invalid pointer read.
>
> The location is constrained to a 1-byte address space, meaning any
> attempted pointer manipulation can only target addresses between 0x00 and 0xFF.
> This range corresponds to the zero page, which is unmapped on most modern
> operating systems and will reliably result in a crash, leading only to a
> Denial of Service. Exploiting this issue also requires a user or application
> to process a maliciously crafted PKCS#12 file. It is uncommon to accept
> untrusted PKCS#12 files in applications as they are usually used to store
> private keys which are trusted by definition. For these reasons, the issue
> was assessed as Low severity.
See above about private key import.

> ASN1_TYPE Type Confusion in the PKCS7_digest_from_attributes() function (CVE-2026-22796)
> ========================================================================================
>
> Severity: Low
>
> Issue summary: A type confusion vulnerability exists in the signature
> verification of signed PKCS#7 data where an ASN1_TYPE union member is
> accessed without first validating the type, causing an invalid or NULL
> pointer dereference when processing malformed PKCS#7 data.
>
> Impact summary: An application performing signature verification of PKCS#7
> data or calling directly the PKCS7_digest_from_attributes() function can be
> caused to dereference an invalid or NULL pointer when reading, resulting in
> a Denial of Service.
>
> The function PKCS7_digest_from_attributes() accesses the message digest attribute
> value without validating its type. When the type is not V_ASN1_OCTET_STRING,
> this results in accessing invalid memory through the ASN1_TYPE union, causing
> a crash.

Is the memory accessed through the bad pointer returned to the caller
in any way?

> Exploiting this vulnerability requires an attacker to provide a malformed
> signed PKCS#7 to an application that verifies it. The impact of the
> exploit is just a Denial of Service, the PKCS7 API is legacy and applications
> should be using the CMS API instead. For these reasons the issue was
> assessed as Low severity.
I know that EDK2 definitely uses the PKCS7 API.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature