## https://sploitus.com/exploit?id=0694C53C-021D-56C2-BCEF-510AE3E65562
# LongLogon · CVE-2026-41089
[](https://nvd.nist.gov/vuln/detail/CVE-2026-41089)
[](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41089)
[](https://docs.astral.sh/uv/)
> **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
```cmd
longlogin
```
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:
| Windows Server | First patched build |
| :--- | :--- |
| 2016 | `10.0.14393.9140` |
| 2019 | `10.0.17763.8755` |
| 2022 | `10.0.20348.5074` |
| 2022 23H2 | `10.0.25398.2330` |
| 2025 | `10.0.26100.32772` |
## 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.