Zyxel GS1900 认证前远程代码执行已在野利用（CVE-2026-107441）

TL;DR

• GS1900 交换机 dispatcher.cgi 中的越界写入让未经认证的攻击者以 root 身份执行操作系统命令。Binarly 在攻击者的工具包中发现了该利用程序，并在真实硬件上进行了测试。
• 运行 2.90(xxx.2)C0 或更早固件的十款 GS1900 型号受影响。Zyxel 于 2026 年 10 月 22 日发布了修复版本 2.90(xxx.3)C0，并于 11 月 3 日发布了公告。
• Zyxel 在 CVSS v3.1 上评为 8.8 High，Binarly 评为 9.8 Critical。GreyNoise 观察到 996 台交换机遭到利用。截至 2026 年 11 月 4 日，CVE-2026-107441 不在 CISA KEV 中；CVE-2026-7273 自 2026 年 9 月 21 日起已列入。
• 立即将列出的每个型号更新到对应的 2.90(xxx.3)C0。任何配置变通方法都无法关闭该漏洞；在安排变更窗口期间如何降低暴露面，请参见“如何修复？”。

我受影响吗？

交换机暴露需要同时满足以下所有条件：

• 设备是 Zyxel 列出的十款 GS1900 型号之一，固件为 2.90(xxx.2)C0 或更早。
• 交换机的 Web 管理界面可从攻击者能够使用的网络访问。Zyxel 将攻击者描述为位于本地网络并且相邻。Binarly 表示，该利用程序只需要通过 HTTP 访问管理服务，不需要协议层面的相邻性。
• 该型号的 2.90(xxx.3)C0 固件尚未安装。2026 年 6 月的 2.90(xxx.2)C0 更新不能修复该漏洞。

Zyxel 表示，公告中未列出的在售产品不受影响。公告列出了每个型号与版本的组合。

检查交换机运行的版本：

1. 登录交换机的 Web 配置界面。Getting Started 页面显示 Model Name 和 Firmware Version，格式类似 2.90(AAHL.2)C0。
2. 将型号和版本与公告清单比较。对于列出的型号，.3)C0 之前的所有版本都受影响，包括 .2)C0、.1)C0 和 .0)C0。只有以 .3)C0 结尾的版本包含 11 月的修复。
3. 交换机没有包管理器。请在资产清单中记录版本，因为同一型号可能运行不同固件。

如何修复？

1. 从 Zyxel 下载库下载对应型号的 2.90(xxx.3)C0 固件。型号专属后缀很重要：GS1900-8 使用 AAHH，GS1900-24 使用 AAHL，依此类推。11 月 3 日的公告链接了型号表和版本发布说明。
2. 在 Web 配置界面中打开 Maintenance > Firmware Upgrade，选择 HTTP，选择该型号的 .bix 文件并应用。保留升级前所做的配置备份。
3. 重启后返回 Getting Started，确认 Firmware Version 显示 .3)C0 版本。
4. 修复所有列出的型号，而不只是面向互联网的那一台。利用程序需要访问管理界面，而扁平的管理 VLAN 会在任何一次入侵后提供这种访问。

供应商没有提供能够关闭该漏洞的变通方法。如果暂时没有变更窗口，可以这样降低暴露面：

• 将管理界面移到专用管理 VLAN。
• 用防火墙规则限制访问，只允许已知管理主机。
• 在设备提供相关选项时，禁用 WAN 管理和远程管理。
• 监控交换机的配置变更和意外重启。

这些措施只能减少能够访问易受攻击服务的人。它们不能修复缺失的边界检查，Zyxel 也没有发布能让解析器安全的配置。仍然可访问的交换机仍然可被利用。

根本原因是什么？

dispatcher.cgi 是交换机 Web 配置页面背后的 CGI 程序。它在 Boa Web 服务器下运行，并将 HTTP POST 正文解析到名为 reqParameters 的全局缓冲区。该缓冲区为 0x23000 字节，分为 140 个 1024 字节的槽位。另一个全局变量 count 记录已解析的参数个数。

Binarly 反编译了固件 2.90(AAHH.1)C0 并公布了存在漏洞的循环。复制操作没有长度检查，计数器也没有上限：

for ( pos = strchr(src, '&'); pos != nullptr; pos = strchr(pos + 1, '&') )
{
  dest = &reqParameters[1024 * count];
  memcpy(dest, src, pos - src);
  dest[pos - src] = 0;
  v10 = strchr(dest, '=');
  if ( v10 != nullptr )
  {
    if ( v10[1] == '&' )
      dest[512] = 0;
    else
      urlDecode(dest + 512, v10 + 1);
    *v10 = 0;
  }
  src = pos + 1;
  ++count;
}

src 是请求正文，pos 标记下一个 &。对于每个字段，循环计算 &reqParameters[1024 * count]，复制到分隔符之前的内容，并递增 count。超过 1024 字节的字段会溢出其槽位。没有任何检查确保 count 保持在 140 以下。

这两个全局变量在 .bss 段中相邻。Binarly 的 IDA 列表显示了布局：

.bss:10003BC0 reqParameters:  .space 0x23000
.bss:10026BC0 count:          .space 4

第 140 个字段是触发点。当 count 为 139 时，复制从最后一个槽位 reqParameters[1024 * 139] 开始，一个 1028 字节的字段会写到缓冲区末尾之后四个字节。这四个字节就是 count。攻击者在该位置提供一个 32 位值，就能把参数计数器替换为任意数字。

循环之后，第二个代码块处理没有末尾 & 的最后一个字段。它复用被破坏的 count：

if ( -src < strlen(src) )
{
  dest = &reqParameters[1024 * count];
  len = strlen(src);
  memcpy(dest, src, len);
  dest[strlen(src)] = 0;
  ...
  ++count;
}

count 在有符号 32 位表达式中乘以 1024。像 0x013bffff 这样的值会使乘积溢出为负偏移，导致 dest 指向 reqParameters 之前而不是内部。写入落在进程的全局偏移表，即已解析函数地址的表中。利用程序选择 strcmp 的条目。

随后程序调用 web_util_paramVal_ret，用 strcmp(reqParameters, param) 遍历参数列表。攻击者控制的第一个参数就是要执行的命令。当 strcmp 条目被替换为 system 的地址后，比较就变成 system("id")，并以 CGI 进程的权限执行，Binarly 验证该运行环境为 root。

第二种利用模式破坏保存的寄存器和返回地址，而不是 GOT。它通过设备 uClibc 中的 gadget 返回并调用 system。两种模式都通过同一个未检查的复制破坏同一个计数器。捕获的利用程序包含 2.10 到 2.90 固件的硬编码地址，并首先针对 GS1900-24。

如何被利用？

1. 攻击者向 /cgi-bin/dispatcher.cgi 发送 HTTP POST。捕获的正文包含：保存命令的第一个字段、139 个 & 分隔符、一个 1024 字节字段及其后紧跟的 32 位计数器值、一个分隔符，以及攻击者想写入 GOT 的地址。
2. web_util_initParaPairs 在没有长度检查的情况下将每个字段复制到 reqParameters。第 140 个字段溢出最后一个槽位，并用 32 位值覆盖 count。
3. 循环外的代码块用被破坏的计数器计算 &reqParameters[1024 * count]。有符号乘法溢出，目标指向全局缓冲区之前，即攻击者选择的 GOT 条目。
4. 同一代码块将最后一个字段复制到该地址，把 strcmp 条目替换为 system 的地址。
5. web_util_paramVal_ret 对第一个参数调用 strcmp。该调用现在到达 system，第一个参数以 root 身份执行。

该请求不需要会话、凭据或用户交互。Binarly 在真实硬件和模拟固件上测试了该利用程序，并公布了请求布局和两种模式。捕获的样本是一个用 PyArmor 混淆的 Python 脚本；GreyNoise 对同一脚本进行去混淆，并发现了相同的参数计数器破坏。

攻击如何展开？

一个未经认证的 HTTP 请求破坏参数计数器，重定向 GOT 中的函数指针，并把下一次比较变成 root 命令。

攻击者能做什么？

能够访问 Web 界面的攻击者可以以 root 身份在交换机上执行操作系统命令。Binarly 在 CGI 进程中用 system("id") 演示了命令执行，并验证工作环境为 root。Zyxel 的公告称，该漏洞可通过特制 HTTP 请求执行操作系统命令。

影响包括读取和修改交换机配置。GreyNoise 观察到一名攻击者从 48 个国家的 996 台交换机中获取配置数据、root 密码哈希和网络信息。这些记录让攻击者获得管理拓扑和可离线攻击的密码哈希。

Zyxel 的 CVE 记录给出 CVSS v3.1 8.8，CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，因为它将攻击视为相邻网络。Binarly 评估为 9.8 Critical，CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，因为管理服务是 HTTP，任何到达它的路径都足够。

条件与“我受影响吗？”相同：网络能够访问管理界面、无需认证、无需用户交互。Zyxel 将攻击者描述为位于本地网络并且相邻。Binarly 将攻击向量评估为网络，因为服务是 HTTP，路由器或 NAT 规则可以把它暴露到本地网段之外。

本文把两项利用结论分开。GreyNoise 将 8 月的活动归因于 CVE-2026-7273，即 Zyxel 在 6 月修复的漏洞。Binarly 发现捕获的利用程序针对的是后来分配为 CVE-2026-107441 的解析器漏洞。

Binarly 还发现，6 月修复的十个版本仍然全部存在漏洞。攻击者的访问和数据窃取由 GreyNoise 证实。攻击者意图对应的 CVE 标签并不重要，重要的是 6 月的补丁没有关闭该路径。

为什么修复有效？

11 月的补丁在计算目标之前检查计数器，并用有界辅助函数替换无界复制。Binarly 公布了新的循环：

for ( pos = strchr(queries, '&'); pos != nullptr; pos = strchr(pos + 1, '&') )
{
  dest = &reqParameters[1024 * counter];
  if ( counter >= 140 ) // the global counter is checked before the copy
    return 0;
  web_util_paramCopy(&reqParameters[1024 * counter], 512, src, pos - src);
  ...
  ++counter;
}

counter >= 140 测试在复制之前运行，因此第 140 个字段无法再到达保存 count 的槽位。web_util_paramCopy 将每个字段限制为 511 字节，因此字段也不能溢出其 1024 字节槽位。两项修改关闭了漏洞的两半：计数器破坏和无界字段复制。

6 月的补丁没有这样做。它增加了以下检查：

if ( ++counter == 140 )
  return 0;
...
if ( counter >= 141 )
  counter = 140;

第一个检查在破坏 counter 的复制之后运行。值被覆盖后，相等测试失败，循环外的代码块仍会执行。第二个检查只是重置一个已经用于计算目标的计数器。Binarly 于 2026 年 9 月 28 日测试了 6 月修复的十个版本，发现全部仍可利用。

Binarly 的公告还建议启用 Full RELRO，使 GOT 变为只读。Zyxel 的公告没有说明新版本是否启用它。补丁关闭了已演示的写入原语，但并没有让 GOT 不可变，因此请把 Full RELRO 视为纵深防御，而不是升级的替代品。

如何检查是否已遭入侵？

交换机可能不会记录触发漏洞的 POST 正文。请先检查恶意软件和命令控制基础设施，再检查交换机保存的信息。

Binarly 公布了 JITTERLY 后门及其投放的 SIXZUT rootkit 的哈希。其公告和文章中的 SHA-256 值如下：

• JITTERLY：0f6e757e82c4d91df5bd249f775b9970b59dee42cc0dfe40f879d77fc16821c6、663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c、82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb。
• SIXZUT：295133156b6a7d95b9c92f832f49e35235f1fbd3906e75c9202ef4cd65d1018c、64677002011bc2e4bc642a4154a20fdb95620ebd0144b98fc60f917901ec8b92、728810b07e911b235f6450e784391e39f68819a0a5d209662162916ffea25146。

攻击者使用 981666[.]xyz 域名的以下主机：

• p1.981666[.]xyz、p2.981666[.]xyz、p3.981666[.]xyz。
• s0.981666[.]xyz 到 s9.981666[.]xyz。

Binarly 的分析列出了以下 IP 地址：104.223.65[.]148、203.88.123[.]148、104.225.153[.]141 和 166.88.227[.]181。恶意软件使用 TCP 443、6443、8080、8082、5432 和 6379。Binarly 在文章中公布了 JITTERLY 和 SIXZUT 的 YARA 规则。

如果交换机可访问且未修复，请假设配置和 root 密码哈希已被获取。更换本地管理员密码、SNMP 团体字符串，以及配置中保存的任何 RADIUS、TACACS+ 或 VPN 密钥。

检查交换机日志中的配置变更、新的本地用户和意外重启。失败的尝试可能在设备上不留痕迹，因此没有日志条目并不能证明交换机未被触碰。

时间线

第一个补丁比取代它的公告早 140 天发布，Binarly 在第一个补丁之后 104 天发现十个修复版本仍然存在漏洞。

• 2026-06-16：Zyxel 发布 CVE-2026-7273 公告和修复版本 2.90(xxx.2)C0。
• 2026-08-17：约在此日，GreyNoise 观察到一名攻击者从 48 个国家的 996 台 GS1900 交换机中获取数据。
• 2026-09-21：CISA 将 CVE-2026-7273 加入 Known Exploited Vulnerabilities 目录。
• 2026-09-28：Binarly 确认作为 CVE-2026-7273 修复发布的十个版本仍然全部存在漏洞。
• 2026-09-29：Binarly 通知 Zyxel 产品安全团队。
• 2026-10-11：Zyxel 确认新漏洞并预留 CVE-2026-107441。
• 2026-10-22：Zyxel 为十款型号发布固件 2.90(xxx.3)C0。
• 2026-11-03：Zyxel 发布公告，Binarly 发布 BRLY-2026-057，CVE 记录发布。

常见问题

CVE-2026-7273 的更新能保护 GS1900 交换机吗？

不能。2026 年 6 月 16 日的 2.90(xxx.2)C0 更新在存在漏洞的复制之后增加了检查，Binarly 于 2026 年 9 月 28 日发现十个修复版本仍然全部可利用。交换机需要 2.90(xxx.3)C0。

CVE-2026-107441 在 CISA KEV 中吗？

不在。截至 2026 年 11 月 4 日，新 CVE 不在 Known Exploited Vulnerabilities 目录中。较旧的 CVE-2026-7273 自 2026 年 9 月 21 日起在目录中，联邦机构截止日期为 2026 年 9 月 24 日。

哪些 GS1900 型号受影响？

Zyxel 列出的十款型号在 2.90(xxx.2)C0 及更早版本中受影响。Zyxel 表示公告未列出的在售产品不受影响，因此请检查具体型号与固件组合，而不是产品系列名称。

在野攻击使用的是 CVE-2026-107441 吗？

GreyNoise 将 8 月的活动归因于 CVE-2026-7273。Binarly 发现捕获的利用程序针对的是后来分配为 CVE-2026-107441 的参数计数器漏洞，并且 6 月的补丁没有阻止它。两个标签描述的是同一个解析器，11 月固件是第一个关闭 Binarly 演示路径的版本。

限制管理界面能阻止攻击吗？

限制界面可以减少能够访问易受攻击服务的人，但不能修复缺失的边界检查。Zyxel 没有发布能让解析器安全的变通方法。任何接口上仍然可访问的交换机仍然可被利用，因此请安排固件更新。

修复完整吗？

11 月的补丁在复制之前检查计数器，并将每个字段限制为 511 字节，关闭了 Binarly 演示的两个写入原语。Binarly 还建议启用 Full RELRO，防止 GOT 被覆盖。Zyxel 的公告没有说明新版本是否启用它，因此请应用固件，并将 RELRO 视为额外控制。

用 Ostorlab 发现暴露的 Zyxel GS1900 交换机

Ostorlab 的攻击面发现会清点暴露在互联网上的管理界面，包括网络设备，让你知道应先修复哪些交换机。在攻击者之前，用它找出贵组织暴露的 GS1900 管理页面。

参考文献

• Zyxel，“Zyxel security advisory for out-of-bounds write vulnerability in GS1900 series switches”（2026 年 11 月 3 日）。https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-out-of-bounds-write-vulnerability-in-gs1900-series-switches-11-03-2026 （2026 年 11 月 4 日核实）
• Zyxel，“Zyxel security advisory for stack-based buffer overflow vulnerability in GS1900 series switches”（2026 年 6 月 16 日）。https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026 （2026 年 11 月 4 日核实）
• Binarly，“Pre-Auth RCE in Zyxel GS1900 Exploited in the Wild as a Zero-Day”（2026 年 11 月 3 日）。https://www.binarly.io/blog/zyxel-gs1900-rce-cve-2026-107441 （2026 年 11 月 4 日核实）
• Binarly，“BRLY-2026-057: Out-of-bounds write vulnerability in Zyxel GS1900 switches”（2026 年 11 月 3 日）。https://www.binarly.io/advisories/brly-2026-057 （2026 年 11 月 4 日核实）
• GreyNoise，“Open Season on Kapibala: Attacker Steals Over 18,000 Government Records Through WordPress Exploitation”（2026 年 9 月 28 日），关于 ZyXEL GS1900 攻击活动的章节：48 个国家的 996 台交换机，归因于 CVE-2026-7273。https://www.greynoise.io/blog/open-season-on-kapibala-attacker-steals-government-records-wordpress-exploitation （2026 年 11 月 4 日核实）
• CVE Program，“CVE-2026-107441”（2026 年 11 月 3 日发布）。https://www.cve.org/CVERecord?id=CVE-2026-107441 （2026 年 11 月 4 日核实）
• CVE Program，“CVE-2026-7273”（2026 年 6 月 16 日发布）。https://www.cve.org/CVERecord?id=CVE-2026-7273 （2026 年 11 月 4 日核实）
• Zyxel，“GS1900 Series User's Guide, V2.90 edition 2”（第 61 和 242 页）。https://download.zyxel.com/GS1900-8/user_guide/GS1900-8_V2.90_Ed2.pdf （2026 年 11 月 4 日核实）
• CISA，“Known Exploited Vulnerabilities Catalog”（2026 年 11 月 4 日核实订阅源）。https://www.cisa.gov/known-exploited-vulnerabilities-catalog （2026 年 11 月 4 日核实）