Description
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.
Published: 2026-08-14
Score: 9.1 Critical
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Prior to version 1.4.4, the erlang_quic QUIC client performed TLS 1.3 handshakes without validating the server’s CertificateVerify signature, certificate chain, or hostname. As a result, the client effectively accepted any presented certificate, enabling an attacker on the network path to impersonate any server and compromise both confidentiality and integrity of the connection. The vulnerability also applies to HTTP/3 clients that use the same library. Handshakes that use a pre‑shared key (PSK) are unaffected because no certificate is transmitted during session resumption.

Affected Systems

The vulnerable code is part of the erlang_quic project maintained by benoitc. Versions prior to 1.4.4 are affected. The same issue applies to any QUIC client that uses this library, including implementations of HTTP/3 that rely on it. Users of erlang_quic should verify that they are not deploying versions earlier than 1.4.4.

Risk and Exploitability

The CVSS score of 9.1 classifies this vulnerability as critical. The EPSS score is not available, but the lack of certificate validation provides a straightforward attack vector for a remote attacker who can position themselves between a client and a legitimate server. The vulnerability is not listed in the CISA KEV catalog, yet the simplicity of the exploit and the severity of the impact suggest a high likelihood of real‑world exploitation. An attacker could intercept and modify traffic, decrypt data, or inject malicious commands without detection.

Generated by OpenCVE AI on August 14, 2026 at 19:20 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade erlang_quic to version 1.4.4 or later, which restores proper TLS verification and defaults verify to true
  • Ensure that the client’s trust store is correctly configured by providing a valid cacerts option or utilizing the operating system’s store
  • Avoid disabling verify (e.g., verify => false) unless absolutely required for a trusted local test environment and verify that no production code relies on a disabled verification setting

Generated by OpenCVE AI on August 14, 2026 at 19:20 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Github GHSA Github GHSA GHSA-2r8v-p65x-3663 QUIC has Broken TLS verification
History

Fri, 14 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Fri, 14 Aug 2026 18:30:00 +0000

Type Values Removed Values Added
Description 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.
Title QUIC has Broken TLS verification
Weaknesses CWE-295
CWE-297
References
Metrics cvssV3_1

{'score': 9.1, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N'}


Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-08-14T19:30:02.687Z

Reserved: 2026-05-30T02:43:33.107Z

Link: CVE-2026-49457

cve-icon Vulnrichment

Updated: 2026-08-14T19:29:57.501Z

cve-icon NVD

Status : Received

Published: 2026-08-14T19:17:18.707

Modified: 2026-08-14T20:16:53.283

Link: CVE-2026-49457

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-14T19:30:04Z

Weaknesses
  • CWE-295

    Improper Certificate Validation

  • CWE-297

    Improper Validation of Certificate with Host Mismatch