EUVD-2026-36248
GHSA-7jx5-vvgh-vcjw
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Attacker must hold a constrained sub-CA key (PR:L) and achieve MITM to exploit (AC:H); MITM yields full read and tamper of TLS data (C:H/I:H) but no availability impact (A:N).
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from Vendor (certcc).
CVSS VectorVendor: certcc
Lifecycle Timeline
5DescriptionCVE.org
The crypton-x509-validation Haskell library fails to enforce X.509 NameConstraints, allowing TLS clients to accept certificates whose Subject Alternative Names fall outside the issuing CA’s permitted subtrees. This oversight enables an attacker who compromises a name-constrained sub-CA to impersonate domains beyond its intended scope.
AnalysisAI
Certificate impersonation in the crypton-x509-validation Haskell library (versions 1.6.12 through 1.9.0, and the paired crypton-x509 from 1.7.6) lets a TLS client accept certificates whose Subject Alternative Names lie outside an issuing sub-CA's permitted subtrees, because the X.509 NameConstraints extension was never evaluated during chain validation. An adversary holding a name-constrained sub-CA key can mint certificates for arbitrary domains and mount man-in-the-middle attacks against clients built on these libraries. There is no public exploit identified at time of analysis and EPSS is very low (0.02%), but a vendor patch (1.9.1) exists and the source fix is public, tracked as CERT/CC VU#862559 and HSEC-2026-0008.
Technical ContextAI
The affected component is the certificate-chain validation logic in the crypton-x509 family - Haskell PKI libraries maintained by Kazu Yamamoto that underpin the tls stack used by HTTP clients and servers in the Haskell ecosystem. X.509 NameConstraints (RFC 5280 §4.2.1.10) is a critical extension placed on a CA certificate that limits the DNS/IP/email namespaces (permitted and excluded subtrees) for which that CA and any subordinate CA may issue. The root cause is CWE-295 (Improper Certificate Validation): validatePure ran leaf, v3 and key-usage checks but never walked the chain to enforce NameConstraints, so a constrained sub-CA's boundary was effectively ignored. The PR-30 fix adds a doCheckNameConst pass that builds a NameConstSpec per chain element, propagates 'stricter' constraints down the chain, and calls validateNamesInSubtrees to reject SANs outside permitted subtrees; it also stops treating unknown critical extensions as opaque.
RemediationAI
Vendor-released patch: crypton-x509-validation 1.9.1 and crypton-x509 1.9.1 - upgrade both to 1.9.1 or later and rebuild any TLS clients/servers that depend on them, then verify via Hackage (https://hackage.haskell.org/package/crypton-x509-validation-1.9.1/revisions/) and PR-30 (https://github.com/kazu-yamamoto/crypton-certificate/pull/30). Projects still on the unmaintained x509/x509-validation packages have no fix and should migrate to the crypton- forks at 1.9.1+. Where immediate upgrade is impossible, the effective compensating control is to remove reliance on NameConstraints as a trust boundary: stop delegating to name-constrained intermediate CAs and instead pin or explicitly allowlist the specific end-entity certificates or CAs you expect (certificate pinning), accepting the operational cost of managing pins on rotation; alternatively restrict the trust store to full CAs you fully trust so a constrained sub-CA compromise gains no extra scope. Consult HSEC-2026-0008 and CERT/CC VU#862559 (https://www.kb.cert.org/vuls/id/862559) for advisory details.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today