CVE-2026-49457
Published:July 02, 2026
Updated:July 05, 2026
Impact 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. Patches 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). Workarounds None 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. Credit Reported by benmmurphy.
Affected Packages
quic (HEX):
Affected version(s) >=0.5.0 <1.4.4Fix Suggestion:
Update to version 1.4.4Related Resources (2)
Do you need more information?
Contact UsCVSS v4
Base Score:
9.3
Attack Vector
NETWORK
Attack Complexity
LOW
Attack Requirements
NONE
Privileges Required
NONE
User Interaction
NONE
Vulnerable System Confidentiality
HIGH
Vulnerable System Integrity
HIGH
Vulnerable System Availability
NONE
Subsequent System Confidentiality
NONE
Subsequent System Integrity
NONE
Subsequent System Availability
NONE
CVSS v3
Base Score:
9.1
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
NONE