Zyxel GS1900补丁没堵住真正的零日漏洞

Zyxel打错了补丁。简单来说，GS1900交换机系列出了这样的问题：攻击者从8月17日前后开始，入侵了48个国家的996台交换机。而Zyxel在6月发布的固件修复（CISA曾要求美国联邦机构在9月24日前安装）并没有阻止实际正在被利用的攻击。据CSO Online报道，真正的漏洞现被编号为CVE-2026-107441，是交换机网页管理界面中的越界写入缺陷，可让未经认证的攻击者执行操作系统命令。Binarly的研究人员表示，这些命令以root权限运行。

被窃取的东西不起眼，却很有价值：设备配置、root凭据哈希值和网络信息。这不是勒索软件，也不是网页篡改，而是一张你的网络地图，外加破解网络密钥的先发优势。如果你在运营GS1900，并且安装了6月的修复补丁还为此感到安心，那你守住的是一扇攻击者根本没有走的门。下面是我们确切掌握的情况、各方的说法，以及目前仍无人回应的问题。绕过补丁的风险，正藏在这三者之间的差距里。

已确认的事实

先说确凿的底线。专门监测攻击流量的GreyNoise在9月21日报告称，攻击者在8月17日前后从996台GS1900交换机中窃取了数据。他们使用脚本收集配置、root凭据哈希值和网络信息，并把窃取的数据留在设备上等待取回。GreyNoise将此次行动与CVE-2026-7273关联，这是Zyxel在6月修复的一个缓冲区溢出漏洞。CISA当天便根据这一判断，将CVE-2026-7273加入已知被利用漏洞目录（KEV），并要求联邦机构在三天内完成修复。

同样已确认的是：9月29日，Binarly向Zyxel报告了一个此前未知的漏洞，并表示攻击者已经掌握了可用的利用代码。Zyxel于10月22日至23日发布了新固件2.90 Patch 3（构建号以.3C0结尾），并于11月3日发布了安全公告。受影响的有十款型号，从小型的GS1900-8到GS1900-48及其PoE系列均在其中。运行Patch 2（构建号以.2C0结尾）或更早版本固件的设备都需要升级到新版本。Binarly的技术分析在模拟固件和实际硬件上进行了验证，结果显示该利用代码无需任何修改即可在Patch 2上生效。其自带的支持固件列表中甚至写明了GS1900-24的Patch 2构建版本。

各方的说法

接下来是有争议的部分，而且争议不少。首先是严重程度：Zyxel的CVE条目将CVE-2026-107441评为8.8分，Binarly则评为9.8分。这个差距并非吹毛求疵，而是关于利用前提的争论。Zyxel的公告将攻击者描述为基于局域网且未经认证。Binarly的公告则写道：

“攻击者只需要能够访问管理服务所在的网络即可” ——Binarly漏洞公告，经The Hacker News报道

只要你在真实网络环境里待过一段时间，就会知道“局域网”这个标签有多少是一厢情愿：扁平化的访客网络、分段不彻底的管理VLAN、形同虚设的跳板机，比比皆是。纸面上的可达性和实际中的可达性，往往是两回事。据The Hacker News报道，Zyxel告诉Binarly，6月那个CVE针对的是缺失的参数数量检查，而缺失的大小检查被其视为另一个漏洞，即现在编号为CVE-2026-107441的那个。换句话说，厂商的立场是：它修复了本来打算修的那个漏洞。而攻击者的立场则通过996次入侵得到了证明：这一点并不重要。

还有一个说法值得标注：Binarly称这是一个零日漏洞，并表示GreyNoise在9月描述的利用代码与其发现的一致。这个推论本身合乎情理，但要注意它的依据：GreyNoise和Binarly都没有确认被攻击的交换机当时确实运行着6月的Patch 2固件。该利用代码在Patch 2上确实能够生效，但8月的受害设备是否已经打过补丁，尚无证据。

无人回应的问题

Zyxel的公告没有说明CVE-2026-107441是否已被利用，而研究人员表示，有效的利用代码早在他们9月29日报告之前就已存在，这种沉默十分引人注目。对于无法立即升级的用户，公告也没有提供任何临时缓解方案。更重要的是，它没有回答与那996台设备最相关的两个问题：安装Patch 3能否清除已经潜入的攻击者？对于可能已经失陷的交换机，设备主人应该检查什么？公告对这两点都只字未提。这正是很多厂商在事件响应中一贯视为别人问题的部分，也正因如此，“打补丁就行”只是一句建议，而不是一份方案。

第140个参数：为什么Patch 2只是减速带

这套机制值得花点时间拆解，因为它是补丁如何失效的教科书案例。据Binarly的分析，交换机处理网页请求的程序会把每个请求参数存入一块固定区域，该区域只容纳140个参数。程序从不检查任何参数的大小，而在Patch 2之前，它也从不检查已存储的参数数量。攻击者发送的第140个参数过大，溢出了该区域，并覆盖了程序自身的参数计数器。下一个参数因此会写到区域之外，攻击者借此把程序即将调用的函数替换为执行自己命令的函数。

Patch 2增加了对计数器的检查，思路没错，位置却不对：检查发生在超大参数已经复制完成之后。此时计数器里已经是攻击者写入的值，检查形同虚设，直接放行了写入操作。这就像保安在人群都已经进场之后才查票。Patch 3则把计数器检查挪到了复制之前，同时对复制操作本身进行了大小限制。Binarly认为这确实堵住了漏洞，这一点没问题。但也要认清6月的补丁周期究竟给运维人员带来了什么：三个月的虚假安全感，以及一条指向错误CVE的KEV条目。

账单，以及谁来买单

这一点让我有些不耐烦。舆论的本能反应是喊“打补丁要更快”，但打补丁最快的那些人，比如在CISA的9月24日期限前完成修复的联邦机构，以及在6月就安装了Patch 2的谨慎团队，恰恰一点保护都没得到。在这件事上，打补丁是代价高昂的控制手段（需要维护窗口、变更委员会，还要对十款型号逐一进行上线测试），而隔离则是成本低廉的手段。GS1900的网页管理界面根本没有理由对管理VLAN或跳板机以外的任何来源开放。这个控制只需要一个下午的ACL配置，就能让整场攻击——无论是CVE-2026-7273还是CVE-2026-107441——都变得无关痛痒。我们在边缘设备上已经看过太多类似的剧情，从Arista的VeloCloud Orchestrator到其他产品都是如此：补丁跑步机转个不停，而可被访问的管理平面依然暴露在外。

那么董事会应该问什么？不是“我们打补丁了吗”，而是下面这些问题：

1. 我们拥有多少台GS1900，它们分布在哪里，今天谁能访问它们的管理界面？
2. 从8月至今，其中是否有设备可被互联网或广泛的局域网访问？如果有，设备上存储的哈希值由谁掌握，我们是否已经轮换了这些凭据？
3. 厂商对入侵后的验证有什么说法？如果厂商保持沉默，我们自己的排查计划是什么？
4. 更换边缘托管交换机的更新成本，与一次攻击者已经掌握我们网络拓扑图的事件所造成的损失相比，哪个更高？

我的判断是：本周就安装Patch 3，但不要把这件事归档为“已修复，完成”。在完成凭据轮换和配置审查之前，任何在攻击期间可被访问的GS1900都应视为可疑设备。另外，管理平面隔离是你多年前就应该投入的控制措施。给这类交换机打补丁只是入场门槛，验证和网络分段才是真正的正餐。厂商先修了计数器，又修了复制操作。你的架构也该修一修了，别等到有人写出第三个CVE才动手。