Haskell TLS Vulnerability Lets Attackers Forge Trusted Certificates (CVE-2026-9648)

A critical Haskell TLS vulnerability is putting secure connections at risk across finance and enterprise systems. CERT/CC has warned that the widely used crypton-x509-validation libraries ignore a core certificate safeguard. As a result, attackers can forge certificates that Haskell clients trust without question.

What went wrong

The flaw, tracked as CVE-2026-9648, carries a high CVSS score of 9.1. At its heart sits a missing check for X.509 NameConstraints, a safeguard defined in RFC 5280.

NameConstraints tell a certificate authority exactly which domains it may cover. However, the affected Haskell libraries skip this check entirely. Other stacks, such as OpenSSL and Go, enforce the rule by default. The Haskell stack did not.

According to the official CVE description:

“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.”

Why it matters

Because of this gap, an attacker who compromises a name-constrained sub-CA can break out of its intended scope. Therefore, they can mint certificates for domains they were never authorized to cover. The result is full session visibility for the attacker.

In practice, the attacker stands up a malicious server and lures Haskell clients to it. Then they capture credentials, secrets, and sensitive traffic in transit. The advisory warns that a successful attack can expose “sensitive financial information, credential theft, and secret theft.”

This Haskell TLS vulnerability is especially dangerous for delegated PKI setups. Notably, banks, insurers, and other financial firms often rely on exactly that structure.

How to stay safe

There is some good news. CERT/CC stresses that pulling off the attack takes considerable setup and some victim interaction. Still, the risk is real, and every prior library version is affected.

Update now. Maintainers fixed the issue in version 1.9.1 of crypton-x509-validation, so upgrading is the clear next step. Ultimately, this case shows how one skipped check can unravel an entire trust model. Consequently, teams running Haskell backends should patch without delay.