CVE-2026-22795: Missing ASN1_TYPE validation in PKCS#12 parsing
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.
The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS12 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
CVE-2026-22795 can crash software that uses OpenSSL to process a specially malformed PKCS#12 file. It is not described as allowing data theft or code execution. Business urgency is usually low unless your systems accept certificate bundles from untrusted users or partners.
Executive priority
Handle through normal patch governance, with faster action for public-facing or partner-facing certificate upload workflows. The known impact is denial of service, not compromise, and the vendor describes practical exploitation as constrained.
Technical view
OpenSSL PKCS#12 parsing can access an ASN1_TYPE union member without validating its type, causing type confusion and an invalid or NULL pointer read. The vendor describes pointer control as constrained to the zero page, making denial of service the expected impact. CVSS is 5.5.
Likely exposure
Exposure is most likely in applications that parse or import PKCS#12 files using OpenSSL 3.6.0, 3.5.0, 3.4.0, 3.3.0, 3.0.0, or 1.1.1. Risk is lower where PKCS#12 files are only handled from trusted administrative sources.
Exploitation context
The source bundle does not show active exploitation, and KEV is false. Exploitation requires a user or application to process a malicious PKCS#12 file. OpenSSL says this is uncommon because PKCS#12 files usually contain private keys and are normally trusted inputs.
Researcher notes
The issue sits outside the OpenSSL FIPS module boundary. OpenSSL 1.0.2 is listed as not affected. The evidence supports denial of service only; do not assume code execution, credential exposure, or active exploitation from the provided sources.
Mitigation direction
Upgrade OpenSSL 3.6 deployments to the 3.6.1 patched line.
Upgrade OpenSSL 3.5, 3.4, 3.3, and 3.0 to patched releases referenced by OpenSSL commits.
For OpenSSL 1.1.1, check vendor or support-channel guidance before accepting residual risk.
Restrict PKCS#12 import paths to trusted users and trusted certificate-management workflows.
Do not treat OpenSSL FIPS module status alone as proof the linked OpenSSL library is unaffected.
Validation and detection
Inventory products and services linking to OpenSSL versions listed as vulnerable.
Identify applications that import, parse, upload, or convert PKCS#12 files.
Confirm deployed OpenSSL package versions include the relevant PKCS#12 parsing fix.
Review certificate-management portals for unauthenticated or low-trust PKCS#12 upload paths.
Prioritize testing where PKCS#12 files can come from external users or partners.
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-754: 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.
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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-754 · source CWE mapping
Improper Check for Unusual or Exceptional Conditions
Improper Check for Unusual or Exceptional Conditions represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.