{"vuid":"VU#862559","idnumber":"862559","name":"crypton-x509-validation Haskell libraries do not enforce X.509 NameConstraints","keywords":null,"overview":"### Overview\r\n\r\nA vulnerability has been discovered in the Haskell TLS software stack, commonly used by applications built in the Haskell programming language to securely connect to servers over the internet. Specifically, the libraries \"crypton-x509-validation\" fail to enforce a key security feature called NameConstraints, a standard defined in RFC 5280 that helps organizations control which domains a certificate authority (CA) is allowed to issue certificates for. This vulnerability allows an attacker with access to the sub-CA to create certificates that will validate successfully with any Haskell TLS connection, allowing the attacker access to full session visibility. Version 1.91 for crypton-x509-validation have been released to address the vulnerability, tracked as CVE-2026-9648.\r\n \r\n### Description\r\n\r\nHaskell is a programming language often used in enterprise, academic, and financial systems such as banks, insurance companies, and data processing platforms, which use it for backend services like fraud detection, risk modeling, and other sensitive connections. The Haskell TLS software stack is the  implementation used by Haskell applications to establish secure HTTPS or TLS connections to servers, just like OpenSSL or Go’s TLS libraries do in other ecosystems. A vulnerability has been discovered within the stack; `crypton-x509-validation`, which do not enforce the `NameContstraints` security feature that other libraries, such as OpenSSL or Go, do.\r\n\r\nThe description for CVE-2026-9648 is as follows:\r\n\r\n> 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.\r\n\r\nNameConstraints are a security mechanism in digital certificates that tell a CA exactly which domains it’s allowed to issue certificates for. The `crypton-x509-validation`, which handle certificate validation in Haskell’s TLS connections, ignore these constraints entirely, so they never check whether a certificate’s Subject Alternative Name (SAN) falls within what the issuing CA is permitted to cover. \r\n\r\nThis enables a threat actor who gains access to a sub-CA key to create a certificate that includes a SAN for a protected domain, tricking Haskell clients into accepting it and enabling full impersonation of those services. Practically, a TA could set up a web server presenting the malicious CA, tracking any Haskell client to connect to the malicious web server, allowing them to capture any credentials or sensitive data transferred during the process. \r\n\r\n### Impact\r\n\r\nAn attacker that successfully exploits CVE-2026-9648 can capture any traffic sent between a Haskell client to their server, potentially giving access to sensitive financial information, credential theft, and secret theft. \r\n\r\nThis vulnerability is likely to affect industries that use delegated PKI structures, or structures that allow delegated systems to create and assign their own CAs. This is typical in banks or other financial industries. \r\n\r\n### Solution\r\n\r\nThe vulnerability requires considerable setup and victim interaction in order to be successful, but vulnerable parties should update their libraries to version 1.9.1 of the `crypton-x509-validation` libraries as soon as possible, as all version prior are vulnerable. \r\n\r\n### Acknowledgements\r\nThanks to the reporter, Ben Smyth.This document was written by Christopher Cullen.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://github.com/kazu-yamamoto/crypton-certificate/pull/30/changes/f4b77edf6ead77f4a886da40e41eab20f0180e39","https://hackage.haskell.org/package/crypton-x509-validation-1.9.1/revisions/","https://github.com/haskell/security-advisories/pull/332","https://github.com/kazu-yamamoto/crypton-certificate/pull/30","https://github.com/haskell/security-advisories/pull/332"],"cveids":["CVE-2026-9648"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-06-11T14:30:20.360983Z","publicdate":"2026-06-11T14:30:20.179238Z","datefirstpublished":"2026-06-11T14:30:20.378598Z","dateupdated":"2026-06-11T14:30:20.179231Z","revision":1,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":205}