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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-14T19:17:18.707Z",
  "pubdate": "2026-08-14T19:17:18.707Z",
  "executiveSummary": "An unauthenticated server vulnerability exists in the erlang_quic QUIC and HTTP/3 client implementation prior to version 1.4.4, where the TLS 1.3 handshake fails to validate server certificates.\nThe vulnerability type is classified as a missing cryptographic signature check and lack of certificate validation, leading to complete bypass of client-side trust establishment.\nImpact includes a total compromise of confidentiality and integrity for QUIC and HTTP/3 connections, exposing data in transit to interception.\nAffected systems comprise the erlang_quic library for all client implementations prior to version 1.4.4, while handshakes authenticated via Pre-Shared Keys (PSKs) via session resumption remain unaffected.\nRisk implications are severe, as an attacker positioned as a man-in-the-middle on the network path can effortlessly impersonate any legitimate server, present arbitrary or self-signed certificates, and decrypt or tamper with application layer traffic.\nAttacker capabilities require network-level positioning to intercept traffic, with no special privileges or prior authentication required.\nExploitation requirements are minimal, as the vulnerable client unconditionally accepts any presented certificate regardless of trust store validation or hostname mismatch, rendering client-side verification settings entirely ineffective prior to patching.",
  "technicalDetails": "The root cause of the vulnerability resides in the QUIC client implementation of the TLS 1.3 handshake within erlang_quic prior to version 1.4.4, where core cryptographic verification mechanisms were omitted or treated as a no-op.\nSpecifically, the CertificateVerify cryptographic signature is not checked, the certificate chain is not validated against a trust store, and the target hostname is never compared against the identifiers present in the presented certificate.\nThe vulnerable components are the QUIC client handshake logic and the HTTP/3 client which relies upon the underlying QUIC transport layer implementation.\nAffected versions include all releases of erlang_quic prior to version 1.4.4.\nAuthentication requirements for exploitation are none on the network layer; the client expects no server authentication validation due to the disabled check.\nPrivilege requirements are non-existent, and network exposure is broad, affecting any client establishing un-resumed connections over public or untrusted networks.\nThe step-by-step attack flow involves a man-in-the-middle positioned on the network path between the erlang_quic client and the intended server.\nWhen the client initiates a new QUIC or HTTP/3 connection (excluding PSK-based session resumption handshakes where a PSK binder authenticates the peer), the server presents a TLS certificate chain and a CertificateVerify signature.\nBecause the client fails to evaluate the CertificateVerify signature, validate the certificate against trusted certificate authorities (`cacerts`), or perform hostname verification, the malicious proxy successfully intercepts the handshake.\nThe client incorrectly assumes a secure session has been established, allowing the attacker to impersonate the target server, intercept sensitive payloads, inject malicious data, and completely compromise connection confidentiality and integrity.\nPost-exploitation impact includes persistent data interception, plaintext exposure of encrypted protocol payloads, and unauthorized command or data injection into the session stream."
}