Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2025-69421 is a high-severity NULL Pointer Dereference (CWE-476) vulnerability in Openssl Openssl. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked in the top 45% of CVEs by exploit likelihood; 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-69421 is a NULL pointer dereference vulnerability in the OpenSSL cryptographic library, specifically within the PKCS12_item_decrypt_d2i_ex() function. The issue arises when processing a malformed PKCS#12 file, as the function fails to check whether the 'oct' parameter is NULL before dereferencing it; this parameter can be NULL when called from PKCS12_unpack_p7encdata(). Affected versions include OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1, and 1.0.2. The FIPS modules in versions 3.6, 3.5, 3.4, 3.3, and 3.0 are not affected, as the PKCS#12 implementation falls outside the FIPS module boundary. The vulnerability is classified under CWE-476 with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
An attacker can exploit this vulnerability by supplying a specially crafted malformed PKCS#12 file to any application that processes such files using a vulnerable OpenSSL version. Successful exploitation triggers a crash, resulting in a denial-of-service condition for the affected application. The issue is confined to DoS and cannot be leveraged for code execution or memory disclosure, leading to a low severity assessment under the project's security policy due to the need for an attacker to deliver the malformed file directly.
Mitigation involves applying patches from the OpenSSL repository, as detailed in the following commit references: https://github.com/openssl/openssl/commit/3524a29271f8191b8fd8a5257eb05173982a097b, https://github.com/openssl/openssl/commit/36ecb4960872a4ce04bf6f1e1f4e78d75ec0c0c7, https://github.com/openssl/openssl/commit/4bbc8d41a72c842ce4077a8a3eccd1109aaf74bd, https://github.com/openssl/openssl/commit/643986985cd1c21221f941129d76fe0c2785aeb3, and https://github.com/openssl/openssl/commit/a2dbc539f0f9cc63832709fa5aa33ad9495eb19c. Security practitioners should prioritize updating affected OpenSSL deployments that handle PKCS#12 files.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-206393
Vulnerability Data
Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer dereference in the PKCS12_item_decrypt_d2i_ex() function. Impact summary: A NULL pointer dereference can trigger a crash which leads to Denial of Service for an application processing PKCS#12 files. The…
more
PKCS12_item_decrypt_d2i_ex() function does not check whether the oct parameter is NULL before dereferencing it. When called from PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can be NULL, causing a crash. The vulnerability is limited to Denial of Service and cannot be escalated to achieve code execution or memory disclosure. Exploiting this issue requires an attacker to provide a malformed PKCS#12 file to an application that processes it. 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, 1.1.1 and 1.0.2 are vulnerable to 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 static analysis) directly finds null-dereference bugs before deployment.
Documented development standards and tools can enforce null-safety rules and safe pointer usage.
Engineering principles can mandate defensive coding such as explicit null checks before dereference.
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 SDLC practices (static analysis, code review, safe coding standards) directly prevent NULL dereference bugs during development.
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 can detect NULL dereference defects before release.
Secure SDLC mandates defensive coding practices that can prevent NULL dereferences.
Application security requirements can specify input validation and pointer-safety rules.
Secure architecture principles encourage defensive design that avoids unsafe pointer use.
Secure coding standards directly require NULL-pointer checks and safe dereference patterns.