Haskell TLS Library Flaw Lets Sub-CAs Impersonate Any Domain

TLS client libraries in the Haskell ecosystem have shipped without enforcing X.509 NameConstraints since day one, leaving any application relying on delegated CA structures wide open to impersonation. The bug, tracked as CVE-2026-9648 and reported by Ben Smyth, lives in the crypton-x509-validation library (versions prior to 1.9.1). NameConstraints are a standard RFC 5280 mechanism that tells a subordinate CA exactly which domains it may issue certificates for. The Haskell validation code simply never checks whether a certificate's Subject Alternative Name falls within those permitted subtrees.

What a Sub-CA Can Do With This

An attacker who compromises a name-constrained sub-CA can mint a certificate for any domain — even one completely outside the sub-CA's intended scope. Because the library never inspects the constraints, the forged certificate validates normally. Practically, this means a threat actor can stand up a malicious web server, trick a Haskell client into connecting (via phishing, DNS spoofing, or on-path position), and capture credentials, session tokens, or secrets in transit. Industries like banking, insurance, and high-frequency trading — heavy Haskell users for backend risk modeling and fraud detection — are the most exposed.

The Fix and What It Means

Version 1.9.1 of crypton-x509-validation patches the gap. The fix is a single pull request (kazu-yamamoto/crypton-certificate#30) that wires up the NameConstraints check that other TLS stacks like OpenSSL and Go have enforced for years. Anyone running Haskell applications that make TLS connections — especially behind delegated PKI hierarchies — should update immediately. The attack surface is narrow (requires sub-CA compromise and some victim interaction), but the consequence is total: full TLS session visibility for the attacker across any domain the victim reaches. This is the kind of silent, confidence-based bug that makes delegated trust models dangerous when only some implementations actually enforce the rules.

Source: VU#862559: crypton-x509-validation Haskell libraries do not enforce X.509 NameConstraints
Domain: kb.cert.org