QUIC has Broken TLS verification

published 2026-07-01 4 mo ago modified 2026-09-18 51 d ago also GHSA-2r8v-p65x-3663 , EUVD-2026-58756

cvss: 9.1; version 3.1, CNA
cisa kev: Not listed; not in CISA's catalog
epss: 0.2%; EPSS 0.2% chance of exploitation in 30 days, percentile 16%
public exploits: 0; none known

erlang_quic is a pure Erlang QUIC implementation. Prior to version 1.4.4, the QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. This is fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). No known workarounds are available before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents.

Patch / fix

fixed in 1

hex quic 1.4.4

CISA SSVC

Exploitation: none
Automatable: yes
Technical impact: total
Assessed: 2 mo ago (2026-08-14)

Exploit prediction

0.25% chance of exploitation in the next 30 days, higher than 16% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by	version	score	vector
CNA	3.1	9.1	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
GitHub	3.1	9.1	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Affected packages

ecosystem	package	affected	fixed in
hex	quic	<1.4.4	1.4.4

Affected products

benoitc erlang_quic

Classification

Weakness

CWE-295 Improper Certificate Validation
CWE-297 Improper Validation of Certificate with Host Mismatch

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

Summary