CVE-2026-41089-LongLogon - CVE-2026-41089 checker: unauthenticated, non-destr

项目说明

LongLogon · C

![C · NVD]()
![MSRC ad]()
!CVSS 3.1 9.8
!CWE-121 stack buffer o
<br>
!checker · non-destructive
!unauthenticated · pre-auth
![run with uv]()
!MIT license

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

!LongLogon checking a domain controller

Does the public PoC for C 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 legacy BuildSamLogonResponse
is only reached with that bit clear. LongLogon uses 0x02.
2. A long username cannot o 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- analysis, shipped as a
non-destructi that ne the o. The lab-confirmed crash
threshold and full mechanism are below.

What C is

A stack-based buffer o (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 cumulati reaches the
buffer end, the trailing L'\0' terminator o the cookie, __report_gsfailure
fires, and lsass.exe dies with STATUS_STACK_BUFFER_O (0xc0000409). The
domain controller reboots. Unauthenticated, one UDP packet.

Where Zerologon (C) 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
o precondition holds: whether this DC's domain is long enough that an
*unpatched* DC would crash.

It does not:

send the o or crash anything, and

determine patch state. A patched DC takes the *identical* code path and refuses

the o 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)
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 en:

Or with pip:

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 plus the
per-field buffer-fill math.

Nt matters. The 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 ne the bug. LongLogon uses 0x02.

Affected builds

Unpatched Windows Ser 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 defensi only. This repository
ships the non-destructi checker, not a weaponized crasher, for an
acti, wormable C 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.

ADscan LITE (free, open source): Acti pentesting from one terminal.

Enumeration, BloodHound collection, Kerberoasting, ADCS, attack paths, e.

ADscan PRO: the same kill-chain automation for teams running AD engagements.

---

_{Research by Yeray Martín Domínguez · ADscan · C · Netlogon ·
Acti · domain controller · stack buffer o · CLDAP ·
unauthenticated · pre-auth · proof of concept}

项目信息

开发语言：Python

Star 数：14

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕CVE-2026-41089 checker: unauthenticated, non-destructive detection for the Netlogon CLDAP stack buffer overflow (CVSS 9.8). Reports whether a domain controller's domain is long enough to crash, without sending the overflow. The binary-verified analysis the public PoCs got wrong.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。