CVE-2026-105794: 
C# vulnerability analysis and mitigation

CVE-2026-105794 is an improper certificate validation vulnerability in Microsoft's MsQuic library that enables man-in-the-middle (MITM) attacks against clients using the OpenSSL or QuicTLS TLS backends. MsQuic is a cross-platform C implementation of the IETF QUIC protocol with bindings for C, C++, C#, and Rust. Affected versions include all releases prior to 2.4.20, versions 2.5.0–2.5.10, and versions 2.6.0. The Schannel TLS backend is not affected. The vulnerability was disclosed on October 6, 2026, with patches available in versions 2.4.20, 2.5.11, and 2.6.1. It carries a CVSS v4.0 base score of 9.1 (Critical) (GitHub Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation): MsQuic clients using the OpenSSL or QuicTLS backends failed to call X509_VERIFY_PARAM_set1_host and X509_VERIFY_PARAM_set1_ip_asc during TLS handshake processing, meaning the server certificate's Subject/SAN fields were never checked against the intended target hostname or IP address (GitHub PR #6274). An on-path attacker positioned to intercept QUIC traffic can present any valid certificate — regardless of hostname — and the client will accept it without error. Exploitation requires the attacker to be on-path (network-adjacent or capable of routing manipulation), but no authentication or user interaction is needed. The fix ensures that the server name provided to ConnectionStart (or the target IP address if no name is provided) is properly used for certificate hostname validation (GitHub PR #6274, GitHub Advisory).

A successful exploit allows an on-path attacker to impersonate any target server by presenting a mismatched but otherwise valid certificate, effectively breaking the authentication guarantee of TLS over QUIC. All client-to-server communications transmitted over the spoofed connection — including credentials, session tokens, and sensitive application data — are exposed to interception and potential modification, resulting in high confidentiality and integrity impact. Availability is not directly affected. Any application or service using MsQuic with the OpenSSL or QuicTLS backend (e.g., HTTP/3 clients, custom QUIC-based protocols) is at risk (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is reported as 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires an on-path network position (the CVSS v4.0 Attack Requirements field is set to PRESENT), which limits opportunistic exploitation but does not preclude targeted attacks. No threat actor attribution has been reported.

1. Gain on-path position: Position between a vulnerable MsQuic client and its intended server using techniques such as ARP spoofing, BGP hijacking, rogue Wi-Fi access points, or DNS poisoning to intercept QUIC (UDP) traffic.
2. Identify target traffic: Confirm the client is using MsQuic with the OpenSSL or QuicTLS backend (e.g., via QUIC Initial packet fingerprinting or application-layer indicators) and is running a version prior to 2.4.20, 2.5.11, or 2.6.1.
3. Obtain or generate a certificate: Acquire any valid TLS certificate (e.g., for an attacker-controlled domain, or a self-signed certificate if the client does not enforce CA trust) — the hostname does not need to match the target server.
4. Intercept and respond to QUIC handshake: Intercept the client's QUIC Initial packet and respond with a TLS ServerHello presenting the mismatched certificate; the vulnerable client will accept it without hostname validation.
5. Relay or terminate the session: Either relay traffic to the real server (transparent MITM) to avoid detection, or terminate the session to harvest credentials and session data transmitted by the client (GitHub Advisory, GitHub PR #6274).

• Network: Unexpected QUIC (UDP) traffic flows through intermediate hosts not normally in the communication path; TLS certificates presented during QUIC handshakes with Subject/SAN fields that do not match the intended server hostname.
• Logs: TLS handshake completions in application logs where the peer certificate CN or SAN does not correspond to the configured server name; anomalous QUIC connection establishments from unexpected source IPs.
• Process/Application: After patching, applications may begin logging QUIC_STATUS_TLS_ERROR for connections that previously succeeded — this can indicate that prior connections were accepted with mismatched certificates (see regression issue #6288 post-patch) (GitHub PR #6274).

Upgrade MsQuic to one of the patched versions: 2.4.20, 2.5.11, or 2.6.1, which properly implement hostname validation via X509_VERIFY_PARAM_set1_host and X509_VERIFY_PARAM_set1_ip_asc (GitHub Advisory). As an interim workaround, switch to the Schannel TLS backend (Windows only), which is not affected by this vulnerability. Organizations should audit all deployments using the Microsoft.Native.Quic.MsQuic.OpenSSL NuGet package or equivalent OpenSSL/QuicTLS-linked MsQuic builds and prioritize upgrading those environments.