CVE-2026-70111: How Corelight uncovered a 0-Day affecting Microsoft Distributed File System

In the process of fuzzing MS-RPC and Distributed File System (DFS) APIs, we discovered a one-packet mechanism set to crash an entire Windows server, which the Microsoft Security Response Center (MSRC) later assigned as CVE-2026-70111. Corelight customers using the Corelight Feed, a custom ruleset within our Open Network Detection and Response (NDR) Platform that’s designed to swiftly detect and help respond to emerging threats, are already automatically covered with the latest detection for exploitation attempts of this vulnerability.

Why we were looking

Windows exposes an enormous attack surface. MS-RPC alone has nearly one thousand distinct interfaces, which expose nearly ten thousand functions in total. When considered in totality, Windows has an attack surface that has never been systematically mapped from a defensive perspective. We set out to change that, building a setup to systematically probe the Windows API attack surface.

We focused first on MS-RPC, in particular the DFS referral channel, because it has a reputation for being “coercible”; attackers have in the past located ways to abuse DFS to cause victim servers to make outbound SMB connections, thereby exposing NTLM credentials to capture or relay by the attacker.

Our methodology

We weren't actually trying to crash the server; we were seeking novel coercion techniques in DFS, looking for clever new ways to trick Windows servers into handing over NTLM authentication. But halfway through probing the referral paths, the test machine unexpectedly blue-screened and vanished into thin air. For vulnerability researchers, the BSOD and subsequent IRQL messages are music to our ears: it means we’ve touched the OS kernel in a way we weren’t supposed to.

We started with a systematic approach to our research: enumerate the MS-RPC interfaces that touch DFS, map their opnum call paths into the kernel, then fuzz the input-handling paths to see what we could break. The NetDFS management interface (MS-DFSNM, UUID 4fc742e0-4a10-11cf-8273-00aa004ae673) has a call chain that causes mup.sys to issue FSCTL_DFS_GET_REFERRALS IOCTL requests toward a Domain Controller (DC). Since the attacker can choose what DC the referral request is sent to, they can also pretend to be a DC and issue an arbitrary response. We fuzzed those responses and discovered a path that causes a complete system crash for the victim server.

We then proceeded to test reproducibility, and we were able to reproduce the crash 11/11 times on Server 2022 and 3/3 times on Server 2019.

What an attacker can do with this

All an attacker needs to exploit this mechanism for denial of service (DoS) is network adjacency: they only need to be able to issue MS-RPC packets toward a victim Windows server.

The attack flow is fairly straightforward. The attacker sets up a server that responds to DFS referral requests with a malicious response. This malicious server could run anywhere, even on the attacker’s workstation. Once the attacker has the malicious server running, they coerce the target Windows server to initiate an SMB connection to that rogue server, a well-known technique for existing, well-known public tooling. The rogue server replies with a crafted DFS_REFERRAL_V3 payload. When the victim’s mup.sys receives the response and processes it, the result is a BSOD. The whole exchange takes seconds.

What does the target organization see? A server that reboots unexpectedly. Event ID 41 (kernel power) and Event ID 6008 (unexpected shutdown) will appear in the System log, but in our experience, there is not a minidump or a clear, obvious reason for the crash.

Windows servers will automatically reboot after such a kernel fault, limiting the duration of the denial of service. However, if an attacker is in a position to do this once, they’re likely also in a position to do this repeatedly, continuously taking a server offline and keeping it offline if they choose.

The total impact to an organization will depend on which servers an attacker chooses to target from their vantage point. If the attacker can simultaneously and continuously crash all of the Domain Controllers of an organization, for example, it would have a very large impact.

Microsoft has acknowledged in their advisory that they consider this a privilege escalation vulnerability, which indicates there may be a path to code execution via exploiting the flaw in mup.sys.

Perimeter monitoring isn’t enough

Yes, it is important to monitor the perimeter for signs of this attack, especially if you have Windows servers exposing services to the internet. However, if an attacker’s malicious SMB server is running locally on their machine and they are inside the network perimeter, the DFS referral exchange is internal traffic. It may even look exactly like the baseline operational traffic that's always running because it is just SMB traffic, except the response has been replaced with a malformed payload.

Logging connection metadata (which devices are communicating, rather than what they are saying) is not enough to detect this, since the details of what happens are part of the application transaction.

The mechanism: One missing length check

When a Windows Server resolves a DFS path, mup.sys sends a referral request to the associated DC over SMB2 and waits for a response. That response is implicitly trusted, since SMB and DFS are assumed to be used internally and controlled by trustworthy entities. The attack exploits this implicit trust by returning a response that is syntactically valid but semantically empty in a strategic location.

mup.sys receives the RESP_GET_DFS_REFERRAL, parses the DFS_REFERRAL_V3 entries, and calls PktExpandSpecialEntryFromReferral() for a NameList referral (flag ReferralEntryFlags & 0x0002, per MS-DFSC §2.2.5.3.2). That function dereferences ExpandedNameOffset to locate the first DC name string, then calls wcslen() on the pointer.

Earlier Windows builds contained a check that the length of wzExpandedName is greater than zero. That guard was removed from the Server builds. Without it, a referral response where ExpandedNameOffset points to an empty WCHAR string (\x00\x00) flows through unchecked. The kernel dereferences a pointer derived from empty input, faults, and dies.

It’s important to note here that the vulnerability is in mup.sys, and this DFS attack vector is just one approach. There could be other attack vectors to trigger this crash via mup.sys which we have not considered.

Windows Server 2019, 2022, and 2025 are affected. Microsoft acknowledges Windows 10 as being affected, as well.

Detecting this with Corelight

There are two different approaches to detecting this using Corelight’s Open NDR Platform. The first is the direct path: by using the Suricata® signatures from the Corelight Feed that’s available within Corelight Open NDR which fire on the malformed packet in real time. The second is to observe the aftermath in the Zeek® conn.log that’s also available in Corelight Open NDR: sessions that went silent, then came back with resets.

For those who are not aware, Suricata is a high performance, open-source network analysis and threat detection software. Zeek is a non-profit project that maintains an open-source software platform which generates compact, high-fidelity transaction logs, file content, and fully customizable outputs. Together, they give a complete timeline from the offending request through the crash and recovery. Suricata and Zeek are also a key part of the deep and broad forensic-grade network evidence that powers Corelight Open NDR.

To elaborate further, when mup.sys null-dereferences, the kernel dies immediately, and the TCP stack with it. All established network connections for the victim machine go silent. Zeek logs this as conn_state=S1: connection established, data exchanged in both directions, never closed. Once the server recovers, other network devices may still be trying to resume connections from before the crash, and the victim machine will then RST those connections since it has no state for them. If the reboot occurs within Zeek's inactivity timeout (default 5 minutes), tracked connections will show a conn_state of RSTR. If it occurs after the timeout, the post-reboot RST arrives as a new mid-stream connection with no SYN, and Zeek logs the connection with a conn_state of RSTRH. A sudden inrush of S1, RSTR, and/or RSTRH connections involving the same server could be a sign of an unintentional reboot, perhaps one from exploitation of this vulnerability.

Having this network logging is important, especially in this scenario, since the crashed server doesn’t get a chance to log anything meaningful about why it crashed.

Microsoft October 2026 Patch ships October 13

The patch for CVE-2026-70111 ships with Microsoft's October 2026 Patch on October 13. The patch addresses these affected systems: Windows Server 2019, 2022, and 2025. Corelight has not observed signs of any active exploitation of this vulnerability as of this writing.

Before patching:

• Prioritize DFS-active Windows Server machines that regularly issue DFS referral requests to domain controllers.
• Ensure east-west sensor coverage on the DC-to-server SMB2 segment.
• Monitor conn.log for conn_state=S1 clusters followed by RSTR from the same server.

As a reminder, Corelight customers using the Corelight Feed are already automatically covered with the latest detection for exploitation attempts of this vulnerability.

Our key takeaways

• CVE-2026-70111 is a one-packet kernel crash. A removed length guard in mup.sys lets a malformed DFS V3 NameList Referral response kill any affected Windows Server immediately.
• Only network-level access is necessary for exploitation. It does not need DC compromise. It does not need administrative privileges. Any user with network adjacency to a Windows server can exploit CVE-2026-70111 for denial of service.
• Microsoft has classified this as a vulnerability that allows for privilege escalation.
• True coverage requires east-west monitoring. Because a network-resident attacker can exploit this without leaving the network, you need to be monitoring east-west traffic to ensure full detection coverage .
• This is what proactive research looks like. This finding came from fuzzing APIs proactively, instead of from investigating an incident where an attacker used this technique in the wild. Our Corelight team developed signatures before the CVE was assigned by Microsoft, and we’re working on a pipeline of even more discoveries.

To keep up with future discoveries from our Corelight team, subscribe to our newsletter at the bottom of our blog feed. For more exploit findings like these, check out our other featured blog posts.

Have questions about east-west network coverage or Windows protocol attack surface detection? Talk with one of our experts.