CVE-2026-105794: MsQuic: Improper Certificate Validation in Microsoft.Native.Quic.MsQuic.OpenSSL

QUIC clients must confirm that the certificate presented by the server matches the name they meant to connect to. In MsQuic with OpenSSL or QuicTLS, the target hostname was not validated against the server certificate. A certificate for a different host passed, as long as it otherwise validated.

The attacker must sit on the network path between client and server, for example on shared Wi-Fi, a compromised router or a hostile network segment. They also need a certificate that chains to a CA the client trusts, for any domain they control. They then terminate the QUIC connection, present that certificate, and the client accepts the connection as if it were the real server. From there they can read and change the traffic. The CVSS 4.0 vector rates confidentiality and integrity impact high.

Any product that embeds the MsQuic OpenSSL build for outbound QUIC connections inherits the problem, including .NET and native applications that ship this package. The advisory page names no downstream products.

The NuGet package Microsoft.Native.Quic.MsQuic.OpenSSL in three ranges:

• below 2.4.20
• 2.5.0 up to but not including 2.5.11
• 2.6.0 up to but not including 2.6.1

Only the OpenSSL and QuicTLS TLS backends are affected. Schannel builds are not.

dotnet list package --include-transitive | grep MsQuic

For native builds, check which version and TLS backend you compiled against.

Upgrade to the patched release for your line: 2.6.1, 2.5.11 or 2.4.20.

dotnet add package Microsoft.Native.Quic.MsQuic.OpenSSL --version 2.6.1

The fix validates the server name passed to ConnectionStart against the certificate, using the OpenSSL calls X509_VERIFY_PARAM_set1_host and X509_VERIFY_PARAM_set1_ip_asc. If no server name is given, it validates against the target IP address. Rebuild and redeploy every application that bundles the library. The advisory page shows no workaround.

Inventory the applications and images that include MsQuic OpenSSL builds below the patched versions. The sources give no log line for an attack. A successful man-in-the-middle looks like a normal connection, so check for QUIC connections that reached an unexpected address or that used a certificate whose name differs from the target.

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.