LongLogon · CVE-2026-41089

LongLogon is an unauthenticated, non-destructive precondition checker for CVE-2026-41089, a pre-auth stack buffer overflow in the Windows Netlogon service. With no credentials, and without sending the overflow, it reports whether a domain controller's DNS domain name is long enough for the bug to crash it.

Does the public PoC for CVE-2026-41089 actually work?

On a normally-named domain controller, no. The public exploit PoCs for this CVE (the most-starred one, and the copies that followed it) claim to crash a domain controller by sending a long username. They do not crash an unpatched DC on an ordinary domain, for two reasons confirmed by diffing the pre- and post-patch netlogon.dll and reproducing the crash in a lab:

1. Wrong NtVer. They ping with the V5EX bit set (0x16), which routes to the bounds-safe BuildSamLogonResponseEx. The vulnerable legacy BuildSamLogonResponse is only reached with that bit clear. LongLogon uses 0x02.
2. A long username cannot overflow on its own. The attacker-controlled User field is capped at 130 wide chars by the binary, far short of the 528-byte buffer. The bytes that carry the write onto the stack cookie are the server's own long DNS names, which no payload length changes.

So the popular exploit fails on an ordinary domain, and a recv timeout (which a single dropped UDP packet causes on a healthy DC) gets misread as a crash. LongLogon is not one of those exploits: it is the corrected, binary-verified analysis, shipped as a non-destructive checker that never sends the overflow. The lab-confirmed crash threshold and full mechanism are below.

What CVE-2026-41089 is

A stack-based buffer overflow (CWE-121, CVSS 9.8) in the Netlogon DC-locator path NlGetLocalPingResponse → BuildSamLogonResponse → NetpLogonPutUnicodeString. Answering a CLDAP or MAILSLOT ping, the DC serializes its own forest, domain, and host names plus a small attacker-controlled string into a fixed 528-byte stack buffer (ushort local_258[264]), with the stack cookie immediately after it. When the server's own DNS names are long enough, the cumulative write reaches the buffer end, the trailing L'\0' terminator overruns the cookie, __report_gsfailure fires, and lsass.exe dies with STATUS_STACK_BUFFER_OVERRUN (0xc0000409). The domain controller reboots. Unauthenticated, one UDP packet.

Where Zerologon (CVE-2020-1472) abused an all-zero challenge, LongLogon abuses a pathologically long domain name.

What this tool checks, and what it does not

longlogon.py is non-destructive. It sends benign CLDAP pings with a minimal User field, measures the legacy-builder response, and reports whether the overflow precondition holds: whether this DC's domain is long enough that an unpatched DC would crash.

It does not:

• send the overflow or crash anything, and
• determine patch state. A patched DC takes the identical code path and refuses the over-long write, so you cannot tell patched from unpatched over the wire on a normally-named DC.

Knowing which of your DCs are actually patched needs a credentialed (admin) version check across the fleet. That is the kind of thing ADscan automates in an engagement (see below).

Why almost every real DC is safe

The only attacker-controlled bytes that reach the buffer come from the CLDAP User filter, bounded to 130 wide chars, far short of the 528-byte buffer on their own. The bytes that carry the cursor onto the cookie are the server's own names, which the attacker does not control. A default-named DC (corp.local) cannot be crashed. That is why Microsoft rates it "Exploitation Less Likely." In a lab, the minimum DNS domain length to crash Windows Server 2016 (with a 7-char host name) was 98 characters.

Usage

With uv, zero setup. Dependencies are declared inline (PEP 723), so this auto-installs rich in an ephemeral environment:

uv run longlogon.py <dc-ip> <dc-dns-domain>

Or with pip:

pip install rich
python3 longlogon.py <dc-ip> <dc-dns-domain>

The DNS domain must match what the DC serves. It is not secret: rootDSE, reverse DNS, and CLDAP itself all reveal it. The output is a precondition verdict plus the per-field buffer-fill math.

NtVer routing matters. The vulnerable legacy BuildSamLogonResponse is only reached when (NtVer & 0xc) == 0 and (NtVer & 0x2) != 0. Public exploit attempts that send NtVer=0x16 or 0x06 set bit 2 (0x4) and hit the bounded-safe BuildSamLogonResponseEx, so they never trigger the bug. LongLogon uses 0x02.

Affected builds

Unpatched Windows Server domain controllers, 2012 R2 through 2025. First patched builds:

Responsible use

For authorized security research and defensive validation only. This repository ships the non-destructive precondition checker, not a weaponized crasher, for an actively-exploited, wormable CVE. Patch your domain controllers.

Take it further

• Full research write-up: how the bug was located by patch-diffing, the exact buffer mechanics, and why the public PoCs do not fire. https://adscanpro.com/blog/patch-diffing-cve-2026-41089-netlogon
• ADscan LITE (free, open source): Active Directory pentesting from one terminal. Enumeration, BloodHound collection, Kerberoasting, ADCS, attack paths, evidence. https://github.com/ADScanPro/adscan
• ADscan PRO: the same kill-chain automation for teams running AD engagements. https://adscanpro.com/pro

_{Research by Yeray Martín Domínguez · ADscan · CVE-2026-41089 · Netlogon · Active Directory · domain controller · stack buffer overflow · CLDAP · unauthenticated · pre-auth · proof of concept}