CVE-2026-4428: Improper Check for Certificate Revocation in AWS-LC

AWS-LC provides cryptographic functions, including X.509 certificate validation for applications operating within the AWS ecosystem. When applications explicitly enable certificate revocation list (CRL) checking via the X509_V_FLAG_CRL_CHECK flag, the library parses and evaluates the provided CRLs against the active certificate chain. CVE-2026-4428 manifests as a logic error during this validation phase, specifically when handling partitioned CRLs.

Partitioned CRLs distribute revocation data across multiple lists to reduce file size and bandwidth consumption during validation. These specialized lists employ an Issuing Distribution Point (IDP) extension to define the specific subset of certificates they cover. The vulnerability occurs because AWS-LC incorrectly evaluates the scope of these IDPs, causing valid partitioned CRLs to be erroneously rejected as out of scope.

As a result, the validation routine concludes that no relevant revocation data exists for the evaluated certificate. The library subsequently permits the TLS handshake or certificate acceptance to proceed, treating the revoked certificate as entirely valid. This structural failure in the validation logic creates a direct path for attackers to utilize compromised cryptographic material against affected systems.

The root cause resides within the crl_crldp_check() function located in crypto/x509/x509_vfy.c. This function is responsible for determining whether a specific CRL contains revocation data applicable to the certificate currently under validation. The logic evaluates the DIST_POINT objects found within the certificate's CRL Distribution Points extension against the CRL's IDP extension.

The implementation contained a flawed conditional statement that mishandled the structural requirements defined in RFC 5280. The standard dictates that if a distribution point specifies reasons or CRLissuer fields, the validation library must apply special handling logic. The vulnerable code utilized a logical AND (&&) operator instead of a logical OR (||) operator when checking for the presence of these fields.

This operator error caused the special handling branch to execute only if both fields were present simultaneously. Furthermore, the logic responsible for executing the core URI matching routine, idp_check_dp(), was nested improperly inside this flawed conditional block. Consequently, standard distribution points containing only a URI completely bypassed the matching routine when evaluated against a CRL containing an IDP extension.

The exact nature of the vulnerability is evident when examining the specific logic flaw in the crl_crldp_check() function. The pre-patch implementation incorrectly grouped the evaluation of unsupported distribution point fields with the execution of the primary URI matching function. This structural mistake prevented the proper evaluation of standard distribution points.

// Pre-fix logic in crl_crldp_check
if (dp->reasons != NULL && dp->CRLissuer != NULL &&
    (!crl->idp || idp_check_dp(dp->distpoint, crl->idp->distpoint))) {
  return 1;
}

In the vulnerable snippet above, the use of && requires both reasons and CRLissuer to be non-null for the condition to proceed to the idp_check_dp evaluation. Because most certificates omit these fields, prioritizing only a URI, the condition evaluates to false immediately. The function then falls back to default logic that ultimately rejects the CRL as out of scope.

The patch applied in commit 47389586f8aa77c83245173793f4d44ed1d6c3a8 resolves this by decoupling the field checks from the URI matching.

// Fixed logic in crl_crldp_check (Commit 47389586f8aa77c83245173793f4d44ed1d6c3a8)
if (dp->reasons != NULL || dp->CRLissuer != NULL) {
  continue; // Correctly skip DPs that AWS-LC doesn't support in this context
}
 
// RFC 5280 Section 6.3.3 step b.2
if (!crl->idp || idp_check_dp(dp->distpoint, crl->idp->distpoint)){
  return 1; // Properly match clean DPs against the CRL's IDP
}

The corrected code utilizes a logical OR (||) to correctly identify and skip distribution points requiring unsupported features via the continue statement. The idp_check_dp() function is then called unconditionally for all standard distribution points, ensuring proper scope validation against the CRL's IDP extension.

Exploitation of CVE-2026-4428 requires an attacker to possess a valid certificate that has been formally revoked by the issuing Certificate Authority (CA). The attacker must possess the corresponding private key to complete the cryptographic proofs required during a TLS handshake or authentication protocol. The target system must be actively utilizing a vulnerable version of AWS-LC to perform X.509 certificate validation.

The victim application must be configured to enforce revocation checking by explicitly setting the X509_V_FLAG_CRL_CHECK flag. Additionally, the CA responsible for the attacker's certificate must utilize partitioned CRLs featuring the Issuing Distribution Point extension. If the CA issues standard, complete CRLs without this extension, the vulnerable code path is not triggered, and the revocation is processed correctly.

When the victim system connects to the attacker or processes the attacker's payload, AWS-LC attempts to validate the certificate chain. The library fetches the partitioned CRL, but the flawed logic in crl_crldp_check() incorrectly marks the CRL as out of scope. The validation routine completes without enforcing the revocation, and the application grants the attacker trusted access.

The primary impact of CVE-2026-4428 is the complete bypass of certificate revocation controls under specific configuration states. This failure permits an adversary to utilize compromised, stolen, or otherwise invalidated cryptographic identities. The vulnerability fundamentally undermines the trust model established by the Public Key Infrastructure (PKI) for the affected application.

The CVSS v3.1 base score of 7.4 reflects the high severity of the confidentiality and integrity impacts. An attacker successfully exploiting this flaw can establish an Adversary in the Middle (AitM) position, intercepting sensitive data, or bypass client-certificate authentication mechanisms. The vulnerability scores High for Attack Complexity (AC:H) due to the strict prerequisites regarding the CA's CRL configuration and the victim's application flags.

Systems that do not explicitly enable CRL checking, or those interacting with CAs that issue monolithic CRLs, are not exposed to this vulnerability. However, for organizations operating in environments where partitioned CRLs are standard, such as specific government or high-security enterprise PKIs, the risk of unauthorized access via revoked material is substantial.

The definitive remediation for CVE-2026-4428 is upgrading the AWS-LC library to version 1.71.0 or later. For environments utilizing the FIPS-validated branch, administrators must deploy AWS-LC-FIPS version 3.3.0 or later. These updates contain the logic corrections required to properly evaluate partitioned CRLs and enforce revocation status.

> [!NOTE] > Recompilation of statically linked applications is required to apply this fix. Applications dynamically linking to the library must be restarted after the shared objects are updated.

Organizations unable to immediately apply the patch can implement a temporary workaround at the CA level, provided they control the PKI infrastructure. Reconfiguring the Certificate Authority to issue complete, non-partitioned CRLs without the Issuing Distribution Point extension prevents the vulnerable code path from executing. This configuration ensures that AWS-LC processes the revocation data using standard validation logic.

Development teams should audit their applications to verify whether the X509_V_FLAG_CRL_CHECK flag is actively utilized. Applications that do not enable this flag are unaffected by this specific vulnerability, though operating without revocation checking presents its own separate security risks. Network administrators should also review TLS termination endpoints to ensure they are not inadvertently relying on vulnerable builds of AWS-LC.