Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:NSummary
CVE-2025-69419 is a high-severity Out-of-bounds Write (CWE-787) vulnerability in Openssl Openssl. Its CVSS base score is 7.4 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 37th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-69419 is an out-of-bounds write vulnerability in the OpenSSL library's PKCS12_get_friendlyname() function. It occurs when processing a maliciously crafted PKCS#12 file containing a BMPString (UTF-16BE) friendly name with non-ASCII BMP code points. The issue stems from the OPENSSL_uni2utf8() function's two-pass conversion process, where the bmp_to_utf8() helper incorrectly forwards the remaining UTF-16 source byte count as destination buffer capacity to UTF8_putc(). For BMP code points above U+07FF, this leads to a negative output length and a trailing NUL byte write at a negative offset from the heap-allocated buffer. The vulnerability affects OpenSSL versions 3.6, 3.5, 3.4, 3.3, 3.0, and 1.1.1; OpenSSL 1.0.2 and FIPS modules in affected versions are not vulnerable.
An attacker can exploit this by supplying a malicious PKCS#12 file to an application that invokes the public PKCS12_get_friendlyname() API during parsing. While PKCS12_parse() uses a different code path that avoids the issue, direct use of PKCS12_get_friendlyname() on attacker-controlled files triggers the flaw, resulting in a single zero byte write before the allocated buffer. This memory corruption can lead to various consequences, including denial of service, though the impact was assessed as low severity due to the limited nature of the write. The CVSS v3.1 base score is 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), mapped to CWE-787 (Out-of-bounds Write).
Mitigation involves applying patches from the OpenSSL repository, as detailed in the referenced GitHub commits: 41be0f216404f14457bbf3b9cc488dba60b49296, 7e9cac9832e4705b91987c2474ed06a37a93cecb, a26a90d38edec3748566129d824e664b54bee2e2, cda12de3bc0e333ea8d2c6fd15001dbdaf280015, and ff628933755075446bca8307e8417c14d164b535. Security practitioners should update affected OpenSSL installations promptly and audit applications for direct calls to PKCS12_get_friendlyname() on untrusted PKCS#12 files.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-206395
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and bounds checks) finds out-of-bounds write flaws before deployment.
Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.
Input validation can structurally reject or sanitize data that would otherwise trigger an out-of-bounds write.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices (static analysis, bounds checking, code review) are the primary means of preventing out-of-bounds writes.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance can detect and prevent out-of-bounds write defects.
Secure development life cycle mandates practices that prevent out-of-bounds writes.
Application security requirements can specify bounds-checking and safe memory handling.
Secure architecture and engineering principles reduce the likelihood of buffer overflows.
Secure coding directly addresses out-of-bounds writes through language choice and coding standards.
Change management can enforce review gates that catch unsafe memory operations before deployment.