Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:HSummary
CVE-2023-0286 is a high-severity Type Confusion (CWE-843) vulnerability in Stormshield Stormshield Network Security. Its CVSS base score is 7.4 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked in the top 1.0% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
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-2023-0286 is a type confusion vulnerability in X.509 certificate processing that affects OpenSSL and LibreSSL. It stems from incorrect ASN.1 handling of X.400 addresses within the GENERAL_NAME structure: the x400Address field is defined as ASN1_TYPE in the public header but is actually parsed as an ASN1_STRING, causing the GENERAL_NAME_cmp function to misinterpret the data when comparing names.
An attacker who can supply both a certificate chain and a CRL can exploit the flaw when an application enables CRL checking via the X509_V_FLAG_CRL_CHECK flag. By presenting a malicious X.400 address, the attacker can supply arbitrary pointers to an internal memcmp call, resulting in either disclosure of memory contents or a denial of service. The attack does not require valid signatures on the supplied chain or CRL in most cases, although it is primarily relevant to applications that implement their own network-based CRL retrieval rather than relying on local files.
Patches addressing the issue are available in OpenSSL (commits 2c6c9d439b, 2f7530077e, and fd2af07dc0) and LibreSSL 3.6.2, which correct the type definition and comparison logic for the affected field. The associated EPSS score has remained near its peak of 0.89 since disclosure.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-0817
Vulnerability Data
There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This…
more
field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V3.2.3V15.3.5
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 directly prevent type-confusion flaws via safe typing, static analysis, and code review while the control itself addresses many additional weaknesses.
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 can detect type-confusion vulnerabilities through fuzzing and static analysis.
Secure SDLC mandates type-safe design and review that can catch type-confusion flaws.
Application security requirements can specify strong typing and interface contracts that reduce type confusion.
Secure architecture principles promote type-safe languages and memory-safety mechanisms that mitigate type confusion.
Secure coding standards directly forbid unsafe type casts and require static-analysis checks for type confusion.