CVE-2025-69419: Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion
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.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.
OpenSSL 1.0.2 is not affected by this issue.
Security readout for executives and security teams
Plain-English summary
A malicious PKCS#12 certificate file can trigger memory corruption in OpenSSL when an application calls PKCS12_get_friendlyname(). The most clearly stated impact is denial of service, although the CVSS data rates confidentiality and integrity impact as high. OpenSSL assessed the issue as Low because exploitation is constrained to a one-byte zero write before a heap buffer.
Executive priority
Treat this as a targeted remediation item, not an emergency based on current evidence. Prioritize systems that import untrusted PKCS#12 files or automate certificate handling. Broad OpenSSL exposure still warrants inventory and planned patching because affected versions span multiple supported branches.
Technical view
The bug is an out-of-bounds write in OPENSSL_uni2utf8() during BMPString friendly-name conversion. A negative return from UTF8_putc() is added to the output length without validation, causing the trailing NUL to be written before the allocated buffer. PKCS12_parse() reportedly avoids this path; PKCS12_get_friendlyname() reaches it.
Likely exposure
Exposure is most likely in applications that accept attacker-controlled PKCS#12 files and explicitly call PKCS12_get_friendlyname(). OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, and 1.1.1 are listed as vulnerable. OpenSSL 1.0.2 and the named FIPS modules are not affected.
Exploitation context
The bundle does not show active exploitation, and KEV is false. Exploitation requires a crafted PKCS#12 file and a vulnerable application code path. The vendor notes the attacker can trigger only a one zero-byte write before the allocated buffer, limiting practical exploitability.
Researcher notes
Key differentiator is API reachability: PKCS12_parse() is stated to avoid the vulnerable path, while PKCS12_get_friendlyname() invokes it. Validate real-world impact by mapping application call paths and input trust boundaries, not by assuming all OpenSSL usage is exploitable.
Mitigation direction
Upgrade affected OpenSSL 3.x branches to vendor-fixed releases where available.
For OpenSSL 1.1.1 deployments, check vendor or support-channel guidance.
Avoid processing untrusted PKCS#12 files with PKCS12_get_friendlyname() until patched.
Inventory products that bundle OpenSSL and track supplier advisories.
Prioritize internet-facing or automated certificate-import workflows.
Validation and detection
Identify OpenSSL versions in hosts, containers, appliances, and packaged applications.
Search code for direct PKCS12_get_friendlyname() usage.
Confirm whether PKCS#12 files can be supplied by untrusted users or systems.
Verify patched OpenSSL builds include the referenced branch fixes.
Review vendor advisories for third-party products using OpenSSL.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-787: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
8Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.