本周 CISA 的已知被利用漏洞（KEV）目录新增了两条值得拆解的在野漏洞：一条是网络侧无需认证的固件栈溢出（Zyxel GS1900 系列交换机，CVE-2026-7273，CVSS 8.8），另一条是端点侧的本地提权逻辑缺陷（Veeam Agent for Microsoft Windows，CVE-2026-32996，CVSS 7.3）。两条漏洞的攻击面、触发机制、利用方式几乎没有任何重叠，恰好代表了设备类漏洞的两个典型切面：一个是嵌入式固件 CGI 里的内存破坏，一个是 Windows 服务进程里"会话句柄没做唯一绑定"的授权模型错误。本文把两边的具体技术细节拆开讲。

CVE-2026-7273：GS1900 交换机 CGI 的栈缓冲区溢出

先看 Zyxel。漏洞落在 GS1900 系列交换机固件的 CGI 程序里，属于栈缓冲区溢出（stack-based buffer overflow）。CVSS 3.1 向量是 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，逐项看：

  • AV:A（Adjacent）：攻击者只需处于局域网内，不需要能直接路由到公网；
  • PR:N：无需任何认证，甚至不需要有效账号；
  • UI:N：不需要受害者任何交互，纯主动攻击；
  • C:H/I:H/A:H：机密性、完整性、可用性三者全损。

也就是说，一个能向目标交换机发送 HTTP 请求的局域网节点，构造恶意请求命中 CGI 处理逻辑，就能触发栈溢出、覆盖返回地址，最终执行任意操作系统命令。8.8 分反映的是"影响满分 + 攻击前置条件略高（限定邻接网络）"的组合。

Zyxel 在 2026 年 6 月 16 日的安全公告里已确认此漏洞，并给出了全部受影响型号与修复版本，整理如下：

型号 受影响版本（≤） 修复版本
GS1900-8 2.90(AAHH.1)C0 2.90(AAHH.2)C0
GS1900-8HP 2.90(AAHI.1)C0 2.90(AAHI.2)C0
GS1900-10HP 2.90(AAZI.1)C0 2.90(AAZI.2)C0
GS1900-16 2.90(AAHJ.1)C0 2.90(AAHJ.2)C0
GS1900-24 2.90(AAHL.1)C0 2.90(AAHL.2)C0
GS1900-24E 2.90(AAHK.1)C0 2.90(AAHK.2)C0
GS1900-24EP 2.90(ABTO.1)C0 2.90(ABTO.2)C0
GS1900-24HPv2 2.90(ABTP.1)C0 2.90(ABTP.2)C0
GS1900-48 2.90(AAHN.1)C0 2.90(AAHN.2)C0
GS1900-48HPv2 2.90(ABTQ.1)C0 2.90(ABTQ.2)C0

发现者是中科院软件所（ISCAS）的 Lei Gu、Jun Cao、Zhiqing Rui、Jingzheng Wu、Tianyue Luo。值得注意的是，CISA 在把它收进 KEV 目录时，尚未披露攻击主体、起始时间、受影响组织数量等细节，但已明确"有证据显示在野利用"，并给美国联邦民事行政部门（FCEB）机构设了 2026 年 9 月 24 日的修复截止线。这类"低端管理型交换机被拿去当跳板"的场景，在攻防里其实很常见——内网一台常年不升固件的交换机，本身就是横向移动里最容易被忽略的一环。

CVE-2026-32996：Veeam Agent 命名管道的 UID 绑定缺陷

第二条是 Veeam Agent for Microsoft Windows 的本地提权，安全厂商 Arctic Wolf 发出警告称其正遭在野利用。CVSS 4.0 向量是 AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H，核心是"低权限本地用户 → 系统权限（SYSTEM）"。

这个漏洞的机制比栈溢出有意思得多，值得单独讲清楚。它出在 Veeam Endpoint Backup 服务处理高权限客户端会话的方式上。服务通过本地 gRPC 命名管道 \\.\pipe\Veeam\VAW\ServiceConnectionPipe 与客户端通信。问题在于：

  1. 服务端在收到请求时，会把一个"高权限管理员主体"的会话标识（session UID）缓存起来；
  2. 但这个 UID 是客户端可控的，它没有与真正发起请求的用户或连接做唯一绑定；
  3. 更糟的是，这个高权限会话 UID 会被写进日志文件 C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log；
  4. 而这个日志文件普通用户可读。

于是攻击路径非常干净：一个低权限本地用户先读日志文件拿到有效的高权限 session UID，再通过命名管道把这个 UID 当作自己的会话标识发过去，服务端就误以为请求来自那个高权限管理员主体，从而以 SYSTEM 身份执行攻击者指定的命令。GitHub 上已经有人放出公开 PoC，演示的正是执行 whoami 并把输出写文件，完整走通"读日志 → 伪造 UID → 拿 SYSTEM"这条链。

这套漏洞的本质是授权模型错误：服务的身份判断依赖一个客户端可伪造、且被意外泄露到可读日志里的标识符，而不是绑定到真正的进程身份或认证令牌。它和经典 Windows 提权里"命名管道模拟句柄"那一类问题是亲戚，但具体到 Veeam 是把会话 UID 泄漏这个细节做成了关键一跳。官方修复见 Veeam KB4852。

两条漏洞放一起看

把这两条并列，能看出当前在野利用的两种截然不同的技术底色：

  • Zyxel 是"老派"内存破坏。嵌入式 CGI 程序里的栈溢出，二十年前的写法，今天依然有效。它的防御几乎只有一条路：升级固件。无法靠边界设备、WAF 或配置规避——漏洞在被攻击面（HTTP + CGI）上是裸奔的。
  • Veeam 是"新派"逻辑漏洞。没有内存破坏，没有 shellcode，纯粹是身份/会话绑定的设计错误 + 一处日志信息泄漏的组合。这类漏洞的利用更稳定（不依赖 ASLR/栈保护绕过），但需要先有本地低权限立足点，所以它通常是攻击链里的中段——拿到一个普通账号后，用它跳到 SYSTEM，再配合勒索软件的凭据收割。

把两者串起来看也很自然：网络侧的 8.8 无认证 RCE 负责"进来"，端点侧的 7.3 提权负责"站稳"。这正是很多勒索事件的经典两步：入口 + 提权。

检测与防御

Zyxel 侧，第一件事是核对固件版本。GS1900 系列可以在 Web 管理页或 CLI 里查：

show version          # 查看当前固件版本
show running-config   # 确认管理网段与 ACL

如果版本落在上面表格的"受影响（≤）"列，立即升到对应修复版本。附带建议：把管理 VLAN 和业务 VLAN 隔离，管理面只允许跳板机/网管段访问，禁止任何设备把管理接口暴露到不可信网段。这类 CGI 栈溢出虽然无需认证，但 AV:A 意味着只要收窄了"谁能连到管理口"，攻击面就大幅缩小。

Veeam 侧，补丁之外可以做两件事：一是检查日志文件的权限，确认 Svc.VeeamEndpointBackup.log 没有被放宽到普通用户可读；二是关注命名管道的访问控制。可以先审计一下当前权限：

Get-Acl "C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log" | Format-List

正常预期是该文件只有 SYSTEM 和 Veeam 服务账号可读。如果看到 BUILTIN\Users 或 Everyone 有 Read 权限，那说明除了补丁之外，环境本身也在放大这个漏洞。备份软件是勒索攻击最看重的目标——攻击者拿到备份权限就等于拿到了"让你没得恢复"的筹码，所以 Veeam 类组件的补丁优先级应当拉高。

小结

一个 8.8 的网络邻接无认证 RCE，一个 7.3 的本地提权，同一天进 KEV，背后是两种完全不同的漏洞工程学。对防守方来说，结论其实很朴素：管理型设备升级固件要和服务器补丁一样纳入例行巡检，而备份/端点代理这类"平时没人管、出事要命"的组件，恰恰是最容易被勒索链路盯上的中段提权点。把这两条 CVE 放进你的资产台账和补丁窗口，比讨论"AI 会不会自动打穿内网"实际得多。

⚠️ 网络安全免责声明

本文内容仅供技术研究与安全学习之用。文中描述的漏洞分析与攻击链拆解均基于公开披露的安全研究，旨在帮助开发者理解攻击原理、提升安全意识和防御能力。

请勿将本文所述技术用于任何未经授权的安全测试、渗透攻击或非法用途。任何因滥用本文信息而造成的法律后果，由使用者自行承担，与本文作者无关。

如发现系统安全漏洞，请通过合法渠道向相关厂商或平台报告，共同维护网络安全生态。

参考来源：Zyxel 安全公告（GS1900 栈缓冲区溢出）、Veeam KB4852、CISA KEV 目录、NVD（CVE-2026-7273 / CVE-2026-32996）。