CVE-2026-49457: CWE-295: Improper Certificate Validation in benoitc erlang_quic
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.
AI Analysis
Technical Summary
The erlang_quic library, a pure Erlang implementation of the QUIC protocol, had a critical security flaw before version 1.4.4 where the QUIC client did not perform proper server authentication during the TLS 1.3 handshake. Specifically, it did not check the CertificateVerify signature, validate the certificate chain against a trust store, or verify the hostname against the certificate. As a result, the client’s verify function was effectively disabled, allowing an attacker performing a man-in-the-middle attack to present any certificate and impersonate any server, breaking confidentiality and integrity of the connection. HTTP/3 clients using erlang_quic were similarly affected. Handshakes authenticated by pre-shared keys (PSK) were not vulnerable. The vulnerability is resolved in version 1.4.4, where certificate verification is enabled by default and properly implemented. No workarounds exist for versions prior to 1.4.4.
Potential Impact
An attacker positioned on the network path can impersonate any server by presenting an arbitrary certificate, bypassing TLS server authentication. This compromises the confidentiality and integrity of connections established using erlang_quic prior to version 1.4.4, including HTTP/3 connections. The vulnerability does not affect PSK-authenticated handshakes. There are no known exploits in the wild at this time.
Mitigation Recommendations
Upgrade to erlang_quic version 1.4.4 or later, where proper certificate verification is implemented and enabled by default. Versions prior to 1.4.4 have no effective workaround. Do not disable verification by setting verify => false unless for testing with self-signed certificates, as this disables security checks.
CVE-2026-49457: CWE-295: Improper Certificate Validation in benoitc erlang_quic
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.
CVSS v3.1
Score 9.1critical
Affected software
pkg:github/benoitc/erlang_quicRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The erlang_quic library, a pure Erlang implementation of the QUIC protocol, had a critical security flaw before version 1.4.4 where the QUIC client did not perform proper server authentication during the TLS 1.3 handshake. Specifically, it did not check the CertificateVerify signature, validate the certificate chain against a trust store, or verify the hostname against the certificate. As a result, the client’s verify function was effectively disabled, allowing an attacker performing a man-in-the-middle attack to present any certificate and impersonate any server, breaking confidentiality and integrity of the connection. HTTP/3 clients using erlang_quic were similarly affected. Handshakes authenticated by pre-shared keys (PSK) were not vulnerable. The vulnerability is resolved in version 1.4.4, where certificate verification is enabled by default and properly implemented. No workarounds exist for versions prior to 1.4.4.
Potential Impact
An attacker positioned on the network path can impersonate any server by presenting an arbitrary certificate, bypassing TLS server authentication. This compromises the confidentiality and integrity of connections established using erlang_quic prior to version 1.4.4, including HTTP/3 connections. The vulnerability does not affect PSK-authenticated handshakes. There are no known exploits in the wild at this time.
Mitigation Recommendations
Upgrade to erlang_quic version 1.4.4 or later, where proper certificate verification is implemented and enabled by default. Versions prior to 1.4.4 have no effective workaround. Do not disable verification by setting verify => false unless for testing with self-signed certificates, as this disables security checks.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-05-30T02:43:33.107Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a7f619cbf8831d53989dc42
Added to database: 08/14/2026, 18:42:36 UTC
Last enriched: 08/14/2026, 18:56:09 UTC
Last updated: 08/14/2026, 19:41:46 UTC
Views: 6
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.