CVE-2026-70111: A single malformed DFS referral packet crashes Windows Server 2019, 2022, and 2025 with a kernel null-dereference in mup.sys. Patch shipped October 13, 2026; no active exploitation observed as of publication.
Key findings:
- The root cause sits in mup.sys. An earlier null-pointer guard (checking that wzExpandedName length is greater than zero before calling wcslen()) was removed from Server builds while Windows 10 retained it. A crafted DFS_REFERRAL_V3 NameList referral response, where ExpandedNameOffset points to an empty WCHAR string (\x00\x00), flows through PktExpandSpecialEntryFromReferral() unchecked, the kernel dereferences a bad pointer, and the machine BSODs. Corelight reproduced the crash 11/11 times on Server 2022 and 3/3 times on Server 2019.
- The attack chain requires only network adjacency and abuses the implicit trust Windows places in DFS referral responses. The attacker stands up a rogue SMB server, coerces the target to initiate an SMB connection toward it using existing public tooling, then replies with the malformed DFS_REFERRAL_V3 payload. mup.sys processes the response, faults, and the server reboots. The entire exchange takes seconds, and because an attacker in this position can repeat it continuously, they can keep Domain Controllers or other critical servers offline indefinitely.
- On the victim host, the crash leaves almost nothing useful. Event ID 41 (kernel power) and Event ID 6008 (unexpected shutdown) appear in the System log, but no minidump and no clear crash reason. The server does not get a chance to log anything about why it faulted. This makes network-side evidence the primary forensic source.
- Zeek's conn.log provides the post-crash signal. When mup.sys null-dereferences, the TCP stack dies instantly, leaving established sessions silent. Zeek records these as conn_state=S1. After the server recovers, other hosts attempting to resume connections receive RSTs from a machine with no session state. Depending on timing relative to Zeek's default 5-minute inactivity timeout, those appear as conn_state=RSTR (reboot within the timeout) or conn_state=RSTRH (RST arrives as a new mid-stream connection with no SYN, after the timeout). A sudden cluster of S1, RSTR, and RSTRH connections all involving the same server is a hunt-worthy pattern for unexpected reboots, including exploitation of this vulnerability.
Practitioner takeaway: network logging is the detection path here, not host logs. Hunt your Zeek conn.log for a burst of conn_state values of S1, RSTR, and RSTRH from the same server within a short window, especially if that server is a Domain Controller, then cross-reference with Event ID 41 and Event ID 6008 in the Windows System log to confirm an unexpected reboot. Because the malformed DFS response is application-layer content inside otherwise normal-looking SMB traffic, connection metadata alone will not catch it: you need full transaction logging to see the malformed DFS_REFERRAL_V3 payload. Patch priority is Windows Server 2019, 2022, and 2025 via the October 2026 cumulative update.
#DFIR_Radar
