What is the CVSS score of CVE-2026-49457?

CVE-2026-49457 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of erlang_quic are affected by CVE-2026-49457?

erlang_quic (versions before 1.4.4) contains a critical authentication bypass that allows on-path attackers to impersonate legitimate servers and intercept encrypted communications.. A patch is available.

How to fix or mitigate CVE-2026-49457?

Within 24 hours: identify all applications and services using erlang_quic and document their current versions; flag any versions below 1.4.4 as critical risk. Within 7 days: apply network segmentation to isolate systems running vulnerable versions; implement certificate pinning or supplemental authentication where application architecture permits. Within 30 days: monitor Benoît Chesneau's erlang_quic repository for release of version 1.4.4; upgrade immediately upon vendor release and validate fix in staging before production deployment.

erlang_quic CVE-2026-49457

EUVD-2026-58756 CRITICAL

Improper Certificate Validation (CWE-295)

2026-07-01 https://github.com/benoitc/erlang_quic

GHSA-2r8v-p65x-3663

Information Disclosure

9.1

CVSS 3.1 · Vendor: https://github.com/benoitc/erlang_quic

Severity by source

Vendor (https://github.com/benoitc/erlang_quic) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

7.4 HIGH

AV:N and PR:N/UI:N since any client TLS connection is exposed, but AC:H because a genuine man-in-the-middle position is required; C:H/I:H for full traffic exposure and tampering, A:N as availability is unaffected.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/benoitc/erlang_quic).

CVSS VectorVendor: https://github.com/benoitc/erlang_quic

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Aug 14, 2026 - 20:01 EUVD

Analysis Generated

Jul 01, 2026 - 21:15 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Server impersonation in erlang_quic (Benoît Chesneau's Erlang QUIC/HTTP/3 library) before 1.4.4 arises because the QUIC client performed no server authentication during the TLS 1.3 handshake - the CertificateVerify signature, certificate chain, and hostname were all left unchecked, making the verify option a no-op. An on-path attacker can present any certificate to impersonate any server and transparently read or modify traffic, breaking both confidentiality and integrity (CVSS 9.1). No public exploit has been identified at time of analysis, and PSK-based session resumption handshakes are unaffected because the peer is authenticated by the PSK binder.

Technical ContextAI

The affected component is a QUIC transport implementation for Erlang (pkg:erlang/quic, repo benoitc/erlang_quic) that also backs HTTP/3 via the same client code path. QUIC mandates TLS 1.3 for its cryptographic handshake, in which the server proves possession of its private key through the CertificateVerify message and presents a certificate chain that the client must validate against a trust store and match to the requested hostname. This flaw is a textbook CWE-295 (Improper Certificate Validation): the client skipped the CertificateVerify signature check, skipped chain validation against the trust store, and skipped hostname comparison, so the cryptographic binding that normally proves the peer owns the presented certificate was never established. Because HTTP/3 reuses the same client, every higher-level protocol built on this QUIC stack inherited the missing authentication.

RemediationAI

Vendor-released patch: upgrade to erlang_quic 1.4.4, which makes the client verify the CertificateVerify signature, validate the certificate chain against the trust store (the cacerts option, defaulting to the OS store), and check the hostname, with client verify now defaulting to on. There is no effective workaround before 1.4.4 - the advisory explicitly states that verify => true had no effect and that inspecting the certificate post-connection does not help, since without the signature check the peer is never proven to own its certificate; therefore upgrading is the only real fix. After upgrading, keep verify at its new default of on and only set verify => false for deliberate cases such as connecting to a self-signed test server, understanding that doing so re-disables authentication. Consult the advisory at https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663 for details.