OpenSSL X.400 address type confusion in X.509 GeneralName can expose memory or cause denial of service

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.

OpenSSL is marked affected in these release branches:

• 3.0: from 3.0.0 through versions before 3.0.8.
• 1.1.1: from 1.1.1 through versions before 1.1.1t.
• 1.0.2: from 1.0.2 through versions before 1.0.2zg.

The normalized record sets the default status of unlisted versions to unaffected. A product that bundles OpenSSL must still be assessed using the library version it actually ships and the product vendor's own security guidance.

The flaw is in X.400 address processing inside an X.509 GeneralName. X.400 addresses are parsed as ASN1_STRING, but the public GENERAL_NAME structure definition incorrectly declares the x400Address field as ASN1_TYPE. When GENERAL_NAME_cmp processes that field as ASN1_TYPE instead of ASN1_STRING, the data can be misinterpreted and arbitrary pointers may reach memcmp. Exploitation requires an application to enable CRL checking with X509_V_FLAG_CRL_CHECK and to allow externally controlled certificate or CRL data into certificate verification. In the usual scenario, the attacker must provide both the certificate chain and the CRL; neither input needs a valid signature. If the attacker controls only one input, the other must already contain an X.400 address in a CRL distribution point, which is uncommon. Public evidence does not establish a reliable memory-read primitive, specific pointer values, or a general exploit path beyond these conditions.

The flaw is network-reachable in applications that implement their own network retrieval of CRLs. The supplied assessment describes no required authentication and no user interaction, but high attack complexity because the certificate chain, CRL, and CRL-checking conditions must align. In most cases, the attacker must control both the certificate chain and CRL, and their signatures do not need to be valid. If only one input is controlled, the other must contain an X.400 address as a CRL distribution point. The record does not establish exploitation in the wild; its public-exploit field is false and known exploitation status is not established.

Crafted certificate or CRL data may cause a type-confused pointer to be used by memcmp, potentially disclosing memory contents or crashing the certificate-processing process. The assessment supplied with the record describes network reachability, no required privileges, and no user interaction, but high attack complexity. The documented technical effects primarily concern confidentiality and availability of the affected process; the record provides no evidence of data modification or crossing a separate trust boundary. Practical exposure is limited by the requirement to enable CRL checking and, in the usual case, to control both the certificate chain and CRL. The evidence does not establish how to turn the potential memory-access primitive into a controlled read or code execution.

• Data confidentiality: Crafted inputs may cause the process to call memcmp with arbitrary pointers, creating a potential path to disclose memory contents from the affected process.
• Service availability: The same condition may crash the application or interrupt certificate validation, causing denial of service.
• Operational scope: The risk is concentrated in applications that enable CRL checking and implement their own network retrieval of CRLs, rather than automatically affecting every OpenSSL consumer.
• Limits: The evidence does not confirm data modification, arbitrary code execution, or a specific compromise scenario.

1. Upgrade OpenSSL by release branch: users on the 3.0 branch should upgrade to 3.0.8; users on the 1.1.1 branch should upgrade to 1.1.1t; users on the 1.0.2 branch should upgrade to 1.0.2zg. The 1.0.2 fix is available only to premium support customers.
2. Check products and appliances that bundle OpenSSL and apply the corresponding vendor update, rather than updating only the operating system's OpenSSL package.
3. Prioritize applications that enable X509_V_FLAG_CRL_CHECK and retrieve CRLs over a network, especially when certificate chains or CRLs can come from untrusted sources.
4. The reviewed evidence does not provide an OpenSSL-confirmed workaround. Do not disable CRL checking if doing so would weaken the application's certificate-validation requirements.

• Inventory processes and products linked against OpenSSL, then verify the library version actually loaded rather than relying only on the installed package record.
• Review code or configuration for X509_V_FLAG_CRL_CHECK and for certificate or CRL validation paths that accept untrusted input.
• Identify applications that implement their own network retrieval of CRLs, because the OpenSSL advisory identifies this as the more likely exposure pattern.
• Review certificate and CRL stores handled by those applications for CRL distribution points containing X.400 addresses, especially where an external party controls only one of the two inputs.
• As a precaution, monitor for crashes or abnormal behavior in certificate-verification processes, but treat this as generic monitoring rather than a confirmed indicator. Absence of log evidence or crashes does not prove that a system is safe.