Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
.NET NuGet
Not in CISA KEV

MsQuic: Improper Certificate Validation in Microsoft.Native.Quic.MsQuic.OpenSSLGHSA-w5f4-fx9m-m4q7

Fix: microsoft/msquic#6274

GHSA-w5f4-fx9m-m4q7 is a CWE-295 vulnerability in Microsoft.Native.Quic.MsQuic.OpenSSL. A fix is available for Microsoft.Native.Quic.MsQuic.OpenSSL — see the affected versions and patch details below.

Also known asCVE-2026-105794
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
1.0%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs62th percentile — riskier than 62% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

3 pkgs affected
.NETMicrosoft.Native.Quic.MsQuic.OpenSSL.NETMicrosoft.Native.Quic.MsQuic.OpenSSL.NETMicrosoft.Native.Quic.MsQuic.OpenSSL

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

MsQuic is a cross-platform C implementation of the IETF QUIC protocol exposed to C, C++, C#, and Rust. Prior to 2.4.20, 2.5.11, and 2.6.1, MsQuic clients using the OpenSSL or QuicTLS TLS backend do not properly verify that a server certificate matches the intended target server hostname. An on-path attacker can therefore present a certificate that does not match the intended target hostname and spoof the server in a man-in-the-middle attack. The Schannel backend is not affected. This issue is fixed in versions 2.4.20, 2.5.11, and 2.6.1.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetMicrosoft.Native.Quic.MsQuic.OpenSSLall versions2.4.20dotnet add package Microsoft.Native.Quic.MsQuic.OpenSSL --version 2.4.20
.NETNuGetMicrosoft.Native.Quic.MsQuic.OpenSSL≥ 2.5.0&&< 2.5.112.5.11dotnet add package Microsoft.Native.Quic.MsQuic.OpenSSL --version 2.5.11
.NETNuGetMicrosoft.Native.Quic.MsQuic.OpenSSL≥ 2.6.0&&< 2.6.12.6.1dotnet add package Microsoft.Native.Quic.MsQuic.OpenSSL --version 2.6.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Microsoft.Native.Quic.MsQuic.OpenSSL, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update Microsoft.Native.Quic.MsQuic.OpenSSL to 2.4.20 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w5f4-fx9m-m4q7 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

# Summary Improper TLS hostname verification allows a man-in-the-middle (MITM) attack on MsQuic. # Details Only MsQuic with the OpenSSL and QuicTLS TLS backends is affected (the Schannel backend is not affected). ## Patches 2.6.1, 2.5.11, and 2.4.20 # Impact An on-path attacker could spoof a server identity by using a certificate that doesn't match the intended target server hostname.
O3 Security · Impact-Aware SCA

Is GHSA-w5f4-fx9m-m4q7 in your dependencies?

Find it across NuGet, including transitive dependencies.

MsQuic: Improper Certificate Validation in Microsoft.Native…