MsQuic and HTTP/3 in .NET 6

MsQuic and HTTP/3 in .NET 6

.NET 6 bundles a native QUIC library, msquic.dll, on Windows. Several MsQuic advisories match the version that .NET 6 shipped, so vulnerability scanners may report them against a .NET 6 installation.

NES for .NET does not patch this component, and no patch is possible. This page explains what ships, why the affected code is not reachable in a default .NET 6 application, why it cannot be updated in place, and what we recommend.

What ships

The file is byte-identical to the copy Microsoft shipped in .NET 6. Linux and macOS builds contain no native msquic at all — on those platforms QUIC requires you to install libmsquic yourself through your package manager, and keeping that package current is handled by your distribution rather than by .NET.

Why the affected code is not reachable by default

Two independent gates have to be opened before any of this code runs.

1. The QUIC API is not in the .NET 6 targeting pack. System.Net.Quic ships in the runtime, but its reference assembly is deliberately excluded from the framework you compile against — the library is marked IsNETCoreAppRef=false in the .NET 6 sources. A project targeting net6.0 therefore cannot reference QuicConnection or any other QUIC type at build time. QUIC did not become a supported public API until .NET 7.

2. HTTP/3 is off by default. The only in-box consumer of QUIC in .NET 6 is HTTP/3 in SocketsHttpHandler, and it is disabled unless you turn it on. From the .NET 6 sources:

// Default to disable HTTP/3 (and by an extent QUIC), but enable that to be overridden
// by an AppContext switch, or by an environment variable being set to true/1.
public static bool AllowHttp3 { get; } = RuntimeSettingParser.QueryRuntimeSettingSwitch(
    "System.Net.SocketsHttpHandler.Http3Support",
    "DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT",
    false);

Enabling it takes a deliberate opt-in — the System.Net.SocketsHttpHandler.Http3Support AppContext switch, or the DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT environment variable set to true or 1. HTTP/3 was a preview feature in .NET 6 and was documented as such.

If neither gate is opened, msquic.dll sits on disk unused.

Why it cannot be patched

Updating the bundled library is not an available option, for reasons that are structural rather than a matter of priority.

MsQuic 2.x refuses to load against .NET 6. The 2.x line requires API version 2 and rejects version 1 outright, while .NET 6 requests version 1. Moving .NET 6 to a 2.x msquic does not patch QUIC, it breaks QUIC.

The 1.9 line is abandoned upstream. MsQuic 1.9 has had no servicing branch since 2022, so there is no 1.9 release carrying these fixes to move to. Every one of the advisories below was fixed only on the 2.x line.

The library is consumed prebuilt. .NET 6 does not compile msquic; it takes a prebuilt Windows/Schannel binary as a dependency. Patching it ourselves would mean maintaining a fork of a native C codebase that upstream retired years ago, across multiple architectures, for a feature that is disabled by default and whose API is not reachable from a net6.0 project.

Advisories that match this component

The MsQuic advisories below have version ranges that include the 1.9 line. All were fixed on MsQuic 2.x, and none was ever fixed on 1.x.

A separate advisory, CVE-2026-62898, is sometimes raised alongside these. It does not apply to .NET 6: its affected ranges cover the .NET 8, 9 and 10 runtime packages and start above the .NET 6 line entirely.

What we recommend

Do not enable HTTP/3 on .NET 6. It was a preview feature, it is off by default, and on .NET 6 it is backed by an unmaintained QUIC library. Leaving it disabled is both the default and the supported configuration.

If you need HTTP/3 in production, use a .NET version where QUIC is a supported feature. QUIC became a public, serviced API in .NET 7, and later versions receive MsQuic updates through normal servicing.

On Linux and macOS, keep libmsquic current through your package manager. Nothing in a NES for .NET build supplies that library, so it is outside the scope of these advisories and of our patching.

If you have enabled HTTP/3 on .NET 6 and need help assessing your exposure, contact your HeroDevs support representative.

Scanner findings and VEX

Because the affected code ships but is not reachable in a default configuration, scanner findings for these advisories against a .NET 6 installation are possible, depending on how your scanner identifies native components.

These advisories are deliberately not represented in the HeroDevs VEX feed. A VEX statement carries a status and a fixed justification code, with no field for a qualifier. The accurate position here — the code ships, it is unreachable unless you explicitly enable HTTP/3, and no patch exists — cannot be expressed in that form without asserting something broader than we can stand behind for every configuration. Rather than publish a machine-readable claim that would be wrong for anyone who has enabled HTTP/3, we state the position here, in full, instead.

The VEX feed does carry determinations for the rest of NES for .NET, and remains the right way to filter findings that genuinely do not apply to your version. See VEX (Vulnerability Exploitability eXchange) for how to consume it.