CVE-2026-49457

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.

CVSS v3 9.1 CRITICAL

9.1^/10

CVSS v3 : CRITICAL

Vector :

Exploitability : 3.9 / Impact : 5.2

Attack Vector NETWORK

Attack Complexity LOW

Privileges Required NONE

User Interaction NONE

Confidentiality Impact HIGH

Integrity Impact HIGH

Availability Impact NONE

Scope UNCHANGED

References

Link	Resource
https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663

Configurations

No configuration.

History

No history.

Information

Published : 2026-08-14 19:17

Updated : 2026-08-14 20:16

NVD link : CVE-2026-49457

Mitre link : CVE-2026-49457

CVE.ORG link : CVE-2026-49457

JSON object : View

Products Affected

No product.

CWE

CWE-295

Improper Certificate Validation

CWE-297

Improper Validation of Certificate with Host Mismatch

{"id": "CVE-2026-49457", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-49457", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-14T19:29:49.865264Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 3.9}]}, "affected": [{"source": "security-advisories@github.com", "affectedData": [{"vendor": "benoitc", "product": "erlang_quic", "versions": [{"status": "affected", "version": "< 1.4.4"}]}]}], "published": "2026-08-14T19:17:18.707", "references": [{"url": "https://github.com/benoitc/erlang_quic/security/advisories/GHSA-2r8v-p65x-3663", "source": "security-advisories@github.com"}], "vulnStatus": "Received", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-295"}, {"lang": "en", "value": "CWE-297"}]}], "descriptions": [{"lang": "en", "value": "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."}], "lastModified": "2026-08-14T20:16:53.283", "sourceIdentifier": "security-advisories@github.com"}