CVE-2026-41089：Windows Netlogon CLDAP 远程代码执行漏洞深度技术分析

摘要

CVE-2026-41089 是 Microsoft 在 2026 年 5 月安全更新中修复的 Windows Netlogon 远程代码执行漏洞。该漏洞被评为 Critical，CVSS 3.1 评分为 9.8，属于典型的栈缓冲区溢出问题。

从公开信息来看，攻击者可向作为域控制器的 Windows Server 发送特制网络请求，使 Netlogon 服务在处理请求时错误操作内存，最终可能导致远程代码执行。由于 Netlogon 是 Active Directory 域环境中非常核心的认证与域控发现组件，一旦域控制器被攻陷，攻击者可能进一步获取域环境控制权。

本文围绕 CVE-2026-41089 的漏洞背景、协议入口、调用链、内存破坏原理、代码缺陷模式、检测思路和防护建议进行系统分析。文章不提供漏洞利用代码、攻击报文或可直接复现的 PoC，仅从安全研究和防护加固角度进行技术分析。

---

一、漏洞基本信息

CVE-2026-41089 的核心信息如下：

项目	内容
CVE	CVE-2026-41089
组件	Windows Netlogon
漏洞类型	栈缓冲区溢出
CWE	CWE-121
影响	远程代码执行
CVSS	9.8
攻击向量	网络
攻击复杂度	低
是否需要认证	不需要
是否需要用户交互	不需要
主要影响对象	Windows Server 域控制器
修复方式	安装 Microsoft 2026 年 5 月及后续安全更新

CVSS 向量如下：

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

可以拆解为：

指标	含义	风险解释
AV	Network	可通过网络触发
AC	Low	攻击复杂度低
PR	None	不需要认证
UI	None	不需要用户点击或交互
S	Unchanged	不跨越安全边界
C	High	机密性影响高
I	High	完整性影响高
A	High	可用性影响高

这个评分说明：只要攻击者能够从网络访问受影响域控制器，就可能触发漏洞。对于普通服务器来说，RCE 已经属于高危；对于域控制器来说，RCE 往往意味着整个 Windows 域的身份控制面存在失陷风险。

---

二、为什么 Netlogon 漏洞特别危险

Netlogon 是 Windows 域环境中的核心服务之一。它承担的不是普通网络服务功能，而是与 Active Directory 身份认证、域信任和域控制器定位密切相关。

Netlogon 常见作用包括：

1. 维护域成员与域控制器之间的安全通道
2. 支持域用户和计算机认证
3. 支持域控制器之间的信任关系
4. 支持域控制器发现过程
5. 参与部分登录和认证辅助流程

在企业环境中，域控制器是 Windows 域的身份根节点。大量业务系统、终端登录、服务器认证、组策略应用、Kerberos 认证、NTLM 认证都依赖域控制器。如果域控出现问题，影响通常不是单点服务不可用，而是整个域环境认证体系异常。

因此，影响 Netlogon 的漏洞具有天然的高危属性。历史上 Zerologon 也是因为影响 Netlogon 而被广泛关注。CVE-2026-41089 与 Zerologon 不同，它不是认证逻辑绕过，而是内存安全问题，但二者都指向同一个关键对象：域控制器。

---

三、CLDAP 与 DC Locator 背景

理解 CVE-2026-41089，需要先理解域控制器发现过程。

在 Active Directory 环境中，客户端需要找到合适的域控制器。这个过程通常称为 DC Locator。

简化流程如下：

客户端启动或需要认证
        ↓
查询 DNS SRV 记录
        ↓
获取候选域控制器列表
        ↓
通过 LDAP/CLDAP 探测域控可用性
        ↓
选择合适域控制器
        ↓
缓存结果用于后续认证

CLDAP 是 Connectionless LDAP，通常运行在 UDP 389 上。它是无连接的，适合用于快速查询和域控探测。

在 LDAP Ping 过程中，客户端会向域控制器发起查询，域控制器返回包含 Netlogon 信息的数据结构。该响应中可能包含：

域 DNS 名称
林 DNS 名称
域控制器 DNS 主机名
NetBIOS 域名
NetBIOS 主机名
站点信息
用户相关字段
服务能力标志

这些字段中有多个字符串字段，并且部分字符串来自请求或与请求内容有关。漏洞的关键点就在于：Netlogon 在构造响应时，需要把多个 Unicode 字符串写入同一个响应缓冲区。

只要协议响应中存在“多个长度可变字段连续写入缓冲区”的场景，安全风险就会明显增加。

---

四、漏洞触发路径分析

根据公开逆向分析资料，CVE-2026-41089 大致涉及以下调用链：

NlGetLocalPingResponse
    ↓
LogonRequestHandler
    ↓
BuildSamLogonResponse
    ↓
NetpLogonPutUnicodeString

可以从语义上理解这几个函数的作用：

1. NlGetLocalPingResponse

该函数可理解为构造本地域控制器 Ping 响应的入口之一。客户端通过 LDAP/CLDAP 查询域控制器可用性时，域控需要返回本机的域信息、站点信息、主机名、域名等内容。

2. LogonRequestHandler

该函数负责处理 Netlogon 相关请求，根据请求参数、域状态、用户字段和域控制器状态决定返回哪类响应。

3. BuildSamLogonResponse

该函数负责构造 SAM Logon Response 结构。这个结构不是一个简单固定长度结构，而是包含多个可变长度字符串字段。

4. NetpLogonPutUnicodeString

该函数负责把 Unicode 字符串写入响应缓冲区。漏洞的关键就在于该函数对长度单位和边界检查的处理存在缺陷。

整个过程可以简化为：

收到 CLDAP/LDAP Ping 请求
        ↓
解析请求字段
        ↓
准备 Netlogon 响应结构
        ↓
连续写入多个 Unicode 字符串
        ↓
长度单位处理错误
        ↓
超过栈缓冲区边界
        ↓
触发栈缓冲区溢出

---

五、漏洞根因：字节长度与 WCHAR 数量混淆

Windows 中 Unicode 字符串通常使用 WCHAR 表示。一个 WCHAR 通常占用 2 个字节。

也就是说：

1 WCHAR = 2 Bytes

很多 C/C++ 内存漏洞都出现在“字符数”和“字节数”混淆上。

例如：

WCHAR name[128];

开发者看到 128，可能下意识认为缓冲区大小是 128。但实际上：

128 个 WCHAR = 256 字节

如果一个函数要求传入的是“字节数”，而调用者传入的是“字符数”，或者相反，就会产生严重的边界判断错误。

CVE-2026-41089 的核心问题可以抽象为：

调用者认为：maxLen 表示最大字节数
被调用者认为：maxLen 表示最大 WCHAR 数量
结果：实际写入量可能扩大 2 倍

举例说明：

调用者传入 maxLen = 260
调用者本意：最多写入 260 字节
被调用者理解：最多写入 260 个 WCHAR
实际可能写入：260 × 2 = 520 字节

如果目标缓冲区只有 260 字节，就会发生越界写。

这类问题在 Windows 开发中并不少见，尤其容易出现在以下场景：

1. Unicode 字符串处理
2. WCHAR 与 CHAR 混用
3. 字节长度与字符长度混用
4. 自定义字符串复制函数
5. 可变长度协议字段序列化
6. 结构体尾部变长字段构造

---

六、漏洞代码逻辑模型分析

微软没有公开 netlogon.dll 源代码，因此下面使用简化伪代码说明漏洞类型，不代表真实源码。

假设响应构造函数中存在一个固定大小的栈缓冲区：

#define RESPONSE_BUF_SIZE 528

void BuildSamLogonResponse(WCHAR *userName)
{
    BYTE responseBuffer[RESPONSE_BUF_SIZE];
    BYTE *cursor = responseBuffer;

    PutUnicodeString(&cursor, userName, 260);
}

开发者可能认为：

responseBuffer = 528 字节
传入 260 表示最多写入 260 字节

但是字符串写入函数内部可能这样处理：

void PutUnicodeString(BYTE **cursor, WCHAR *src, size_t maxLen)
{
    WCHAR *dst = (WCHAR *)(*cursor);

    while (*src && maxLen--)
    {
        *dst++ = *src++;
    }

    *dst++ = L'\0';

    *cursor = (BYTE *)dst;
}

这里的问题是：

maxLen 被当成 WCHAR 数量使用
而不是字节数量

如果 maxLen = 260，实际最多写入：

260 个 WCHAR + 结尾 NULL
≈ 522 字节

如果响应中不是只写一个字符串，而是连续写入多个字符串：

PutUnicodeString(&cursor, domainName, max1);
PutUnicodeString(&cursor, hostName, max2);
PutUnicodeString(&cursor, userName, max3);

那么每一次写入都会推进 cursor。如果每次写入都没有校验剩余缓冲区大小，风险就会叠加。

典型危险点有三个：

1. cursor 持续向后移动
2. 每次写入只看单个字符串长度
3. 不检查 cursor 是否已经超过 responseBuffer 边界

最终就会形成：

固定栈缓冲区
    ↓
连续写入多个变长 Unicode 字符串
    ↓
长度单位混淆
    ↓
累计写入超过 528 字节
    ↓
栈溢出

---

七、内存破坏过程分析

假设栈上的局部变量布局如下：

高地址
+---------------------------+
| 返回地址                  |
+---------------------------+
| 保存的寄存器              |
+---------------------------+
| 其他局部变量              |
+---------------------------+
| responseBuffer[528]       |
+---------------------------+
低地址

正常情况下，写入数据不应超过 responseBuffer 的 528 字节边界。

如果字符串写入函数没有进行完整边界检查，可能出现：

写入 100 字节：正常
写入 300 字节：正常
写入 528 字节：刚好达到边界
写入 600 字节：覆盖其他局部变量
写入更长数据：可能影响保存寄存器或控制流

栈溢出之后可能造成：

1. 进程异常崩溃
2. LSASS 或 Netlogon 异常
3. 域控制器认证服务不可用
4. 在特定条件下造成控制流劫持
5. 进一步实现远程代码执行

现代 Windows 系统存在多种缓解机制：

Stack Cookie / GS
DEP / NX
ASLR
CFG
SEHOP
进程保护机制

这些机制会提高利用难度，但并不等于漏洞没有风险。微软将该漏洞定级为 Critical RCE，说明其影响已被评估为远程代码执行级别。

从防守角度看，不应因为存在缓解机制就降低修复优先级。

---

八、为什么域控场景风险更高

普通服务器发生 RCE，攻击者可能获得该服务器权限；域控制器发生 RCE，攻击者可能进一步控制整个域。

域控被攻陷后的风险包括：

1. 创建新的域管理员账号
2. 修改 Domain Admins / Enterprise Admins 成员
3. 导出域凭据材料
4. 发起 DCSync
5. 修改组策略 GPO
6. 下发恶意登录脚本
7. 横向移动到成员服务器
8. 部署勒索软件
9. 关闭安全代理或篡改日志
10. 建立长期持久化后门

因此，CVE-2026-41089 的处置重点不只是：

有没有打补丁

还应该包括：

是否已经被利用
域控是否出现异常
域管理员组是否变化
是否存在异常认证行为
是否存在可疑进程和计划任务
是否存在 GPO 篡改

对于域控漏洞，应按照“身份安全事件”而不是普通“系统漏洞”来处置。

---

九、影响范围分析

根据公开漏洞库信息，受影响范围主要涉及 Windows Server 域控制器场景，重点关注以下版本：

Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows Server 2022 23H2
Windows Server 2025

需要注意：

1. 不是所有安装 Windows Server 的机器都是域控制器
2. 风险重点在配置为 Active Directory Domain Controller 的服务器
3. 只安装了 Netlogon 组件但不是域控的服务器，风险面不同
4. 测试域、灾备域、历史遗留域控同样需要排查

建议排查优先级：

第一优先级：生产域控
第二优先级：只读域控 RODC
第三优先级：灾备域控
第四优先级：分支机构域控
第五优先级：测试域控
第六优先级：长期未维护的历史域控

---

十、补丁核查方法

可以通过 PowerShell 检查系统版本和补丁情况。

1. 查看系统版本

Get-ComputerInfo |
Select-Object OsName, OsVersion, OsBuildNumber

2. 查看最近安装补丁

Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 20

3. 查看域控角色

Get-ADDomainController -Filter * |
Select-Object HostName, Site, IPv4Address, OperatingSystem

4. 检查域控复制状态

repadmin /replsummary

5. 检查域控基础状态

dcdiag /v

补丁核查不能只看补丁平台“已下发”，还要确认：

1. 是否安装成功
2. 是否重启生效
3. 构建号是否达到修复版本
4. 域控复制是否正常
5. Kerberos、LDAP、DNS、Netlogon 是否正常

---

十一、攻击特征与检测思路

1. 网络侧检测

由于漏洞入口与域控处理特制网络请求有关，应重点关注访问域控的异常 LDAP/CLDAP 流量。

可关注：

1. 非正常网段访问域控 UDP/389
2. 普通办公终端大量访问域控 UDP/389
3. 异常长度 LDAP/CLDAP 请求
4. 高频域控探测行为
5. 同一源地址短时间访问多个域控
6. 非域成员主机访问域控目录服务端口
7. 来自 VPN、无线、访客网段的异常访问

需要注意，UDP/389 在域环境中并不一定都是恶意流量，很多正常 DC Locator 过程也会使用。因此检测不能简单写成“访问 UDP/389 即告警”，而应结合：

源地址
访问频率
访问时间
请求长度
请求结构
是否为域成员
是否属于正常认证路径
是否命中历史基线

更合理的检测思路是建立域控访问基线。

---

2. 主机侧检测

主机侧重点关注 Netlogon 和 LSASS 异常。

可关注以下日志或现象：

1. Netlogon 服务异常停止
2. LSASS 进程异常崩溃
3. 域控异常重启
4. 认证请求大量失败
5. Kerberos/NTLM 登录异常
6. System 日志中服务控制管理器报错
7. Application 日志中出现 netlogon.dll 或 lsass.exe 异常
8. EDR 记录到异常内存破坏、崩溃或可疑进程行为

建议检查的日志包括：

System
Application
Security
Directory Service
DNS Server
DFS Replication
Netlogon Debug Log
EDR / NDR / SIEM 告警

如果域控出现非计划重启、LSASS 崩溃、Netlogon 异常，应优先排查是否与该漏洞有关。

---

3. 身份侧检测

域控漏洞最危险的地方在于漏洞触发后的身份控制风险。因此还应重点排查身份侧异常。

关注内容包括：

1. Domain Admins 成员变化
2. Enterprise Admins 成员变化
3. Schema Admins 成员变化
4. 新增异常高权限账号
5. 账号密码被异常重置
6. GPO 被异常修改
7. 出现异常 DCSync 行为
8. 域控上出现未知服务
9. 域控上出现未知计划任务
10. 管理员账号出现异常登录来源

可以重点关注 Windows 安全日志事件：

4720：创建用户账号
4728：添加成员到全局安全组
4732：添加成员到本地安全组
4756：添加成员到通用安全组
4738：用户账号被修改
4724：尝试重置账号密码
4624：成功登录
4625：登录失败
4672：分配特殊权限
4688：进程创建
1102：审计日志被清除

如果企业部署了 AD 安全审计、EDR、SIEM、NDR，应将该漏洞相关风险加入临时高优先级监测规则。

---

十二、防护与修复建议

1. 立即安装官方补丁

最有效的修复方式是安装 Microsoft 官方安全更新。

建议流程：

1. 盘点所有域控制器
2. 确认系统版本和构建号
3. 确认业务影响和维护窗口
4. 优先修复互联网边界、办公网可达或重要业务依赖域控
5. 安装 2026 年 5 月及后续累积安全更新
6. 重启域控
7. 验证补丁是否生效
8. 检查 AD 复制、DNS、Kerberos、LDAP、Netlogon 状态
9. 保留补丁前后日志

域控补丁不建议长期拖延。对于多域控环境，可以分批滚动修复，但不应出现长期“部分域控未修复”的状态。

---

2. 收敛域控网络访问面

补丁是根本措施，但网络收敛可以降低暴露面。

建议：

1. 限制非必要网段访问域控 UDP/389
2. 限制普通终端跨区域访问所有域控
3. 限制访客网、无线网、VPN 网段访问域控敏感端口
4. 对域控 LDAP/CLDAP/RPC/SMB 访问建立白名单
5. 禁止互联网直接访问域控
6. 加强东西向流量检测

需要注意：不能简单关闭 UDP/389，否则可能影响正常域控发现。应根据企业实际认证路径进行访问控制设计。

---

3. 启用日志和监控

建议临时提升域控监控等级：

1. 开启或增强 Netlogon 相关日志
2. 加强 LSASS 进程异常监控
3. 对域控服务崩溃建立实时告警
4. 对高权限组成员变化建立实时告警
5. 对 GPO 修改建立审批和告警机制
6. 对异常 DCSync 行为建立检测规则
7. 对域控新增进程、服务、计划任务建立监控

漏洞修复前后都需要监控。补丁能阻止后续利用，但不能证明历史上没有被利用过。

---

4. 不要在生产环境运行未知 PoC

由于该漏洞影响域控，不建议直接在生产域控上运行网络 PoC 或攻击脚本。

推荐验证方式：

1. 补丁状态核查
2. 构建号核查
3. 认证式漏洞扫描
4. 日志回溯
5. 网络访问面分析
6. 隔离实验环境验证

生产环境验证应以“确认是否已修复”为目标，而不是“尝试打崩服务”。

---

十三、代码层面的安全启示

CVE-2026-41089 对开发人员也有很强的启示意义。

1. 字符数和字节数必须明确

错误示例：

void CopyString(WCHAR *dst, WCHAR *src, size_t maxLen)
{
    while (*src && maxLen--)
    {
        *dst++ = *src++;
    }
}

问题在于：

maxLen 到底表示字节数，还是 WCHAR 数量？

安全写法应该明确参数语义：

void CopyStringSafe(
    WCHAR *dst,
    size_t dstCharCount,
    const WCHAR *src
)
{
    size_t i = 0;

    if (!dst || !src || dstCharCount == 0)
        return;

    while (src[i] && i < dstCharCount - 1)
    {
        dst[i] = src[i];
        i++;
    }

    dst[i] = L'\0';
}

参数命名也应清晰：

dstSizeBytes      表示字节数
dstCharCount      表示字符数
maxBytes          表示字节数
maxCharacters     表示字符数

不要使用含糊的 len、size、maxLen。

---

2. 可变长度字段写入必须检查剩余空间

危险示例：

void PutField(BYTE **cursor, WCHAR *value, size_t len)
{
    memcpy(*cursor, value, len);
    *cursor += len;
}

问题：

不知道总缓冲区大小
不知道剩余空间
不知道 cursor 是否已经越界

安全写法：

int PutFieldSafe(
    BYTE **cursor,
    BYTE *bufferStart,
    size_t bufferSize,
    const void *data,
    size_t dataSize
)
{
    size_t used;
    size_t remain;

    if (!cursor || !*cursor || !bufferStart || !data)
        return -1;

    if (*cursor < bufferStart)
        return -1;

    used = (size_t)(*cursor - bufferStart);

    if (used > bufferSize)
        return -1;

    remain = bufferSize - used;

    if (dataSize > remain)
        return -1;

    memcpy(*cursor, data, dataSize);
    *cursor += dataSize;

    return 0;
}

核心原则：

每次写入前，都要知道：
1. 缓冲区起始位置
2. 缓冲区总大小
3. 当前 cursor 位置
4. 剩余可写空间
5. 本次写入长度

---

3. 不要把“单字段安全”误认为“整体安全”

很多漏洞不是单个字段超长造成的，而是多个字段累积写入导致的。

例如：

字段 A：100 字节，合法
字段 B：150 字节，合法
字段 C：200 字节，合法
字段 D：120 字节，合法

单独看都不超过限制，但累积为：

100 + 150 + 200 + 120 = 570 字节

如果总缓冲区只有 528 字节，就会溢出。

因此，协议序列化代码必须校验：

单字段长度
总响应长度
剩余缓冲区长度
对齐填充长度
字符串终止符长度

---

十四、与 Zerologon 的区别

很多人看到 Netlogon 漏洞，会联想到 CVE-2020-1472，也就是 Zerologon。但二者本质不同。

对比项	Zerologon	CVE-2026-41089
CVE	CVE-2020-1472	CVE-2026-41089
组件	Netlogon Remote Protocol	Windows Netlogon
漏洞类型	认证/加密逻辑缺陷	栈缓冲区溢出
问题本质	安全通道认证可被绕过	内存写入越界
主要影响	权限提升、域控接管	RCE、域控接管风险
技术方向	协议逻辑漏洞	内存破坏漏洞
防护重点	强制安全 RPC、补丁	补丁、收敛网络面、监控异常

共同点是：

1. 都影响 Netlogon
2. 都和域控制器高度相关
3. 都具有域环境级风险
4. 都需要高优先级修复

区别在于：

Zerologon 是认证逻辑失效；
CVE-2026-41089 是内存安全失效。

---

十五、应急处置清单

企业可以按照以下清单处置：

【资产确认】
□ 梳理所有域控
□ 梳理 RODC
□ 梳理灾备域控
□ 梳理测试域控
□ 梳理遗留 Windows Server

【补丁确认】
□ 确认系统版本
□ 确认补丁安装状态
□ 确认是否重启
□ 确认构建号
□ 确认 AD 复制正常

【网络收敛】
□ 检查 UDP/389 暴露面
□ 检查 LDAP/CLDAP 访问来源
□ 限制非必要网段访问域控
□ 检查 VPN、无线、访客网访问策略

【日志排查】
□ 检查 Netlogon 异常
□ 检查 LSASS 崩溃
□ 检查域控重启
□ 检查异常登录
□ 检查高权限组变化
□ 检查 GPO 修改
□ 检查新增服务和计划任务

【持续监控】
□ 加强 SIEM 规则
□ 加强 EDR 策略
□ 加强 NDR 检测
□ 建立域控异常实时告警

---

十六、总结

CVE-2026-41089 是一个典型但非常危险的 Windows Netlogon 远程代码执行漏洞。

它的危险性来自多个因素叠加：

1. 影响对象是域控制器
2. 攻击无需认证
3. 不需要用户交互
4. 通过网络触发
5. 漏洞类型为栈缓冲区溢出
6. 成功利用可能获得 SYSTEM 权限
7. 域控失陷可能进一步影响整个域环境

从技术角度看，该漏洞最值得关注的是：

字节数与 WCHAR 数量混淆
可变长度 Unicode 字符串连续写入
固定栈缓冲区边界检查不足
协议响应序列化过程中缺少整体长度校验

从防守角度看，处置重点不是复现漏洞，而是快速回答几个问题：

我的域控有哪些？
哪些域控未安装补丁？
哪些网段可以访问域控 UDP/389？
域控近期是否出现 Netlogon/LSASS 异常？
高权限组、GPO、认证行为是否存在异常？

对于企业安全团队来说，CVE-2026-41089 应按域控级高危漏洞处理，而不是普通 Windows 补丁问题处理。

最后再次强调：域控制器是企业 Windows 网络的身份根基。任何影响 Netlogon 的 Critical 级漏洞，都应优先修复、重点监控、闭环验证。

---

参考资料

• Microsoft Security Response Center：CVE-2026-41089
• NVD：CVE-2026-41089 Detail
• Microsoft Learn：Domain Controller Locator Process
• Microsoft Learn：LDAP Ping / MS-ADTS
• Centre for Cybersecurity Belgium：Microsoft Patch Tuesday May 2026 Advisory
• SecurityWeek：Critical Windows Netlogon Vulnerability in Attackers’ Crosshairs
• 公开逆向分析资料：Windows Netlogon BuildSamLogonResponse / NetpLogonPutUnicodeString 相关分析

---

免责声明

本文仅用于网络安全研究、漏洞分析和防护加固参考。文中代码均为漏洞模式抽象示例，不代表真实源码，不包含漏洞利用代码、攻击报文、绕过细节或可直接复现的攻击流程。任何安全测试均应在合法授权环境中进行，严禁用于未授权攻击活动。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/hnytgl/article/details/161773041