{"items":[{"id":"NVI-00017464","kind":"vulnerability","title":"QUIC has Broken TLS verification","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-2r8v-p65x-3663","CVE-2026-49457"],"plain_summary":"GitHub lists this reviewed advisory for quic. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-0257c8b4cfc73195c2e46bb44dda8ecb"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-07-01T20:32:36.000Z","value":"9.1 critical","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-0257c8b4cfc73195c2e46bb44dda8ecb"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-0257c8b4cfc73195c2e46bb44dda8ecb","url":"https://github.com/advisories/GHSA-2r8v-p65x-3663","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-2r8v-p65x-3663","publisher":"GitHub Advisory Database","observed_at":"2026-11-05T03:49:14.191Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-0257c8b4cfc73195c2e46bb44dda8ecb"],"technology":"quic","known_exclusions":[],"conditions_summary":"### Impact\n\nThe 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.\n\n### Patches\n\nFixed 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).\n\n### Workarounds\n\nNone 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 prove","public_affected_ranges":["<= 1.4.3"]}],"null_published_at":"2026-11-05T19:10:21.391Z","source_updated_at":"2026-07-01T20:32:36.000Z","source_disclosed_at":"2026-07-01T20:32:34.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-05T03:49:14.191Z"}],"next_cursor":null,"snapshot_revision":"44495"}