CVE-2026-9648: X.509 NameConstraints Bypass in crypton-x509-validation

Executive Summary

A critical certificate validation bypass vulnerability has been disclosed in the Haskell crypton-x509-validation library. Tracked as CVE-2026-9648 with a CVSS score of 9.1 (Critical), the flaw allows TLS clients to accept X.509 certificates whose Subject Alternative Names (SANs) fall outside the permitted subtrees defined in a name-constrained intermediate CA's NameConstraints extension.

An attacker who compromises a name-constrained sub-CA — or who obtains a fraudulently issued certificate from one — can present a certificate for any domain to affected TLS clients, bypassing the intended restriction mechanism.

Vulnerability Overview

Root Cause

The crypton-x509-validation library fails to enforce X.509 NameConstraints during certificate chain validation. NameConstraints is an X.509v3 extension that limits the namespace within which a sub-CA may issue valid certificates. When an intermediate CA is issued with nameConstraints: permittedSubtrees: [example.com], it should only be able to issue valid certificates for the example.com domain hierarchy.

The library's validator does not check whether the SAN values in the end-entity certificate actually fall within the sub-CA's permitted subtrees, negating the entire NameConstraints mechanism.

Technical Details

How NameConstraints Should Work

X.509 NameConstraints (RFC 5280, Section 4.2.1.10) allows a CA to constrain the namespace of subordinate CAs. A properly constrained sub-CA issued with permittedSubtrees: [.corp.example.com] may only issue certificates with SANs within that domain. Any certificate issued by that sub-CA for evil.com should be rejected by a conforming validator.

The Bypass

crypton-x509-validation validates the certificate signature chain (i.e., it checks that each certificate is signed by its stated issuer) but does not validate that the SAN values in leaf certificates comply with NameConstraints defined in intermediate certificates.

This means:

1. An attacker obtains a name-constrained sub-CA certificate (e.g., by compromising an enterprise PKI)
2. Issues a certificate for an arbitrary domain (e.g., bank.com) using that sub-CA
3. The victim's Haskell TLS client, built on crypton-x509-validation, accepts the fraudulent certificate as valid

Affected Ecosystem

The crypton Haskell library is a fork of the cryptonite library widely used in Haskell TLS implementations. Applications using tls (Haskell), http-client-tls, or any library that delegates to crypton-x509-validation for certificate chain validation are affected.

Attack Scenarios

Scenario 1: Enterprise PKI Compromise

1. Attacker compromises an enterprise's name-constrained intermediate CA (e.g., through key theft or CA misconfiguration)
2. Issues rogue certificates for external domains (e.g., payment processors, SaaS tools)
3. Intercepts Haskell-based service-to-service traffic via MitM position
4. Affected services accept the fraudulent certificates — credentials and data are exposed

Scenario 2: Certificate Misissuance

1. Attacker tricks a name-constrained public sub-CA into issuing a certificate for a domain outside its permitted subtrees (CT log misissuance)
2. Affected Haskell TLS clients accept the misissued certificate
3. MitM attack against Haskell applications succeeds

Affected Versions

All versions of crypton-x509-validation that do not include the NameConstraints enforcement fix are vulnerable. Check your cabal.project or stack.yaml for crypton and crypton-x509-validation pinned versions.

Remediation

Immediate Actions

1. Update crypton-x509-validation to the patched version as soon as it is available via Hackage
2. Audit your Haskell TLS dependencies — check for direct or transitive use of crypton-x509-validation
3. Review PKI architecture — if name-constrained sub-CAs are used, validate that your TLS stack enforces NameConstraints
4. Apply defense-in-depth — do not rely solely on NameConstraints as a PKI boundary; use certificate pinning for high-value connections

Dependency Check

# Check for crypton-x509-validation in your project
cabal list-dependencies | grep x509-validation
# or with Stack:
stack list-dependencies | grep x509-validation

Detection

Applications using crypton-x509-validation in a network-accessible TLS context are potentially exposed to MitM attacks that exploit this bypass. There are no runtime indicators of active exploitation — the bypass is invisible to the application layer.

To detect if you are affected:

1. Search your codebase and dependencies for crypton-x509-validation
2. Test with a certificate signed by a constrained sub-CA for a domain outside the permitted subtrees — a vulnerable system will accept it

References

• NVD — CVE-2026-9648
• RFC 5280 — Section 4.2.1.10 Name Constraints
• Hackage — crypton-x509-validation