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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
