Fnet 云网安 260918

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

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

今日热点 Top 5

基于过去48小时企业决策相关动态提炼

S1 Cisco ISE 零日 CVE-2026-76460：满分认证绕过已在野利用，三天期限到 9 月 19 日

核心内容

Cisco 于 9 月 16 日发布紧急公告，修复 Identity Services Engine（ISE）与 ISE Passive Identity Connector（ISE-PIC）的认证绕过漏洞 CVE-2026-76460，CVSS 10.0，成因被归为 CWE-648 特权 API 使用不当。

问题出在一个 ISE API 端点缺少足够的认证控制，未认证的远程攻击者只需发送一个构造请求，就能绕过基于 Web 的管理界面认证进入设备。

Cisco 在公告中同时说明，成功利用可进一步取得 root 权限的命令执行能力，这意味着攻击者可以改动本机配置、操纵日志、取得设备上的敏感数据并建立持久化。

该漏洞与设备配置无关，无法通过关闭某个可选功能来消除暴露，厂商明确表示没有任何变通方案，仅有的缓解手段是用基础设施访问控制列表把管理面与控制面流量限定在可信范围，真正的修复只有升级。

同日 CISA 将其收入 KEV 目录，要求联邦民用机构在 9 月 19 日前完成修复或停止使用。

Cisco 是在处理一个 TAC 支持案例时发现该漏洞的，公开公告与在野利用几乎同步，属于零日场景。

ISE 是企业里做接入控制与身份策略的平台，决定谁和什么设备可以进入接入域、进去之后能访问什么，它同时持有接入判据与被管理设备的管理凭据。

Cisco 已发布 IOC，建议在每一个节点的 access.log 中检索可疑用户名，一旦确认失陷，建议重新制作镜像并从备份恢复。

修复版本为 3.1 Patch 12、3.2 Patch 11、3.3 Patch 12、3.4 Patch 7 与 3.5 Patch 4；
3.0 分支已进入停止应用系统维护状态，仍在运行的客户需要迁移到受支持的分支。

同一批公告共发布 77 个 CVE，其中 41 个影响 ISE、28 个影响 Secure Firewall 系列（ASA、FTD 与 FMC），另有若干评分在 9.0 以上，尚未确认被利用。

Cisco ISECVE-2026-76460认证绕过在野利用CISA KEV

为什么重要

• 被绕过的是判据而不是设备：ISE 的职责是决定谁能接入。攻击者拿到它的管理面，等于让整个接入域的判断逻辑开始为伪造的主体服务，后续所有基于身份的授权与审计看上去都在正常工作，实际输入已经是假的。

• 它同时是身份系统与凭据仓库：作为接入控制平台，ISE 持有被管理设备的管理凭据与身份数据。这类平台失陷的损失范围不由单台设备决定，而由它能触达的下游资产决定。

• 没有配置层面的逃生通道：与配置相关的漏洞可以通过关闭功能临时规避，而本次与配置无关，也没有变通方案。留给企业的选项只剩升级与时间赛跑，这对变更窗口受严格管控的行业尤其沉重。

• 三天期限反映的是共识而不是行政节奏：9 月 16 日入册、9 月 19 日到期。KEV 的期限回答的是在已知被利用的前提下，合理修复速度是多少，企业可以把它当作内部应急变更的节奏参照。

• 修复颗粒度是补丁号而不是主版本：要核对的是 3.3 Patch 12 这一层，而不少资产台账只记到主版本号。同时 3.0 分支已停止维护，停在旧分支上的客户需要先规划迁移再谈补丁。

顾问金句

这里真正的教训不是又出了一颗满分漏洞，而是我们把接入控制当成了边界上的一个点，它其实是一条判断链。

建议企业做四件事。

首先，今晚就把 ISE 与 ISE-PIC 的管理接口从公网可达性上摘下来，用基础设施访问控制列表把 443 与 8443 限定在运维跳板与管理子网，这不是合规动作，而是在没有变通方案时可执行的止血动作。

其次，把补丁核对写到补丁号这一层——3.1 Patch 12、3.2 Patch 11、3.3 Patch 12、3.4 Patch 7、3.5 Patch 4，仍在 3.0 分支上的客户要立即启动迁移评估，因为停止维护的分支不会等到你准备好。

再者，按凭据可能已外流来规划后续：在每一个节点的 access.log 里检索可疑用户名，重点核对是否出现过新的管理员账号，并同步轮换 ISE 所管理的下游设备凭据；
厂商的建议很直接，确认失陷就重新制作镜像并从备份恢复，而不是清理后继续观察。

而后，把身份与接入控制类组件单独开一条应急变更通道，它同时持有判据与凭据，不应和普通中间件共用同一个变更排队。

S2 Plugin4Shell：四大 AI 编码智能体的零点击远程代码执行，锁定机制被绕过

核心内容

安全厂商 Air Security 披露 Plugin4Shell，一个影响四款主流 AI 编码智能体的零点击远程代码执行问题，涉及 Claude Code、OpenAI Codex、GitHub Copilot 与 Gemini CLI。

行业的通行做法是审查某个提交后把它用 SHA 锁定，信任被锁定的那一版会永久运行；
Plugin4Shell 击穿的正是这个边界。

缺陷在于智能体会检出被锁定的提交，却从不校验它是否真的落在工作区里，于是控制了上游仓库的攻击者可以让检出解析到恶意代码，而锁定看上去依然被遵守。

具体有两条路径：在 Claude Code、Codex 与 Copilot 上，攻击者创建一个名字恰好等于 40 位十六进制锁定值的分支并设为默认分支，git checkout 在名称既是有效引用又是对象 ID 时优先选择引用，只打印一句 refname is ambiguous 的警告；
在 Gemini CLI 上，安装流程用 git fetch 取回正确提交并用 git checkout FETCH_HEAD 检出，而只要仓库默认分支本身命名为 FETCH_HEAD，检出就会解析到分支，取回的提交被静默丢弃。

前者需要允许以哈希形式命名分支的托管服务，GitHub 会直接拒绝 40 位十六进制分支名，而 Bitbucket 与自托管 git 服务允许，Anthropic 自己的文档也把 Bitbucket 与自托管列为合法的 marketplace 后端。

零点击的成因是插件后台自动更新，在 Claude Code 与 Codex 中这是默认行为，因此当上游把锁定的提交换掉时，用户已经信任并已安装的插件会在没有任何提示的情况下被替换。

影响面在于插件默认继承运行智能体的员工的全部权限，恶意插件无需提权即可在该员工机器上取得完整代码执行能力，并触及员工能触达的敏感数据、内部系统与生产环境。

修复进度并不一致：Anthropic 在 2.1.179 中修复，OpenAI 在 0.146.0 中修复，微软尚未为 Copilot 发布补丁，谷歌已弃用 Gemini CLI 并表示不会修复，现有安装将持续暴露。

研究人员给出的收口方式只有一条断言——检出之后解析工作区中真实的 HEAD，与被锁定值不符即中止。

Plugin4ShellAI 编码智能体零点击 RCE代码供应链SHA 锁定绕过

为什么重要

• 这是智能体生态里首次被命名的代码供应链攻击：此前的智能体安全研究针对模型或智能体本身，这次打的是插件与技能到达数百万台机器所经过的分发层。选一个更强的模型并不能消除一个全行业共用的分发约定上的弱点。

• 做对了每一步依然会中招：受害者只要装了一个来自可信 marketplace、按安全模型要求审查过并锁定到具体提交的插件即可。所有建立在锁定之上的下游审批流程，都会继承这次失效。

• 补丁覆盖是不完整的，这决定了处置方式：两款已修、一款无补丁、一款永久不修。企业无法用统一的升级指令收口，只能按产品分别给出结论，其中使用 Gemini CLI 的组织需要规划迁移而不是等待。

• 插件继承的是人的权限而不是自己的权限：它不需要提权，因为它本来就运行在员工的权限上下文里，拿到的是员工能触达的全部资产。这让研发终端事实上成为通往生产环境与凭据的通道。

• 托管服务的选择成为安全变量：同一个缺陷在 GitHub 上不成立，在 Bitbucket 与自托管 git 上成立，而后者是被官方文档支持的合法配置。安全结论首次依赖于一个多数企业从未审阅过的后端选项。

顾问金句

智能体安全的问题从来不是模型会不会做坏事，而是我们允许它在什么权限下、以什么方式改变系统本身。

建议企业做四件事。

首先，先做一次产品级的清点再谈补丁：确认内部在用的 Claude Code 是否达到 2.1.179、Codex 是否达到 0.146.0，对 Copilot 要承认目前没有厂商补丁可用，只能靠禁用社区 marketplace 与插件自动更新来降低暴露，对 Gemini CLI 要按永久不修来规划迁移。

其次，把插件与技能的安装源收敛到企业自有仓库，并要求加密学来源证明；
锁定必须配合检出后的 HEAD 校验，只写锁定值而不校验落地，等于把保险箱的密码贴在门上却从不确认门有没有被换过。

再者，关闭后台自动更新或改为人工确认——零点击之所以成立，正是因为无需任何交互就能替换一个已被信任的组件。

而后，重新划定研发终端的权限边界：插件继承的是员工权限，那么持有生产凭据、云控制台与部署权限的账号就不应在同一台机器上运行带自动更新的智能体。

S3 解析层同日双警：Unbound CVE-2026-81642 与 BIND 9 十四个漏洞

核心内容

互联网域名解析层在过去两天内收到两份独立公告。

NLnet Labs 于 9 月 17 日发布 Unbound 1.26.1，修复 DNSSEC 验证器中的堆溢出漏洞 CVE-2026-81642，CVSS 9.1。

触发条件十分具体：当验证器处理一条 DNSKEY 记录，而其属主名是一个指向该记录自身数据的压缩指针时，会产生一次无效的自引用读取并溢出堆内存。

攻击者只要控制一个恶意 DNS 区域，并让存在缺陷的解析器去查询它，就有可能取得远程代码执行能力；
这一过程无需认证、无需用户交互，只需要能触达该解析器。

影响范围覆盖 Unbound 1.26.0 及之前的全部版本，值得注意的是 7 月的安全版本 1.25.2 与 8 月的功能版本 1.26.0 同样在列，升到 1.26.1 才是完整修复。

本次发布还一并处理了同一审计周期内发现的另外八个 CVE，其中包括由 Anthropic 一名研究员报告的高危堆损坏 CVE-2026-82717，涉及 CNAME 合成，在部分平台上同样可导致代码执行。

NLnet Labs 表示尚未发现在野利用，CISA 的初始条目标记利用状态为无，厂商仍建议尽快升级；
若无法立即升级，官方为 CVE-2026-81642 与 CVE-2026-82717 提供了可应用于 1.26.0 的独立源码补丁。

前一天，即 9 月 16 日，ISC 发布 BIND 9.20.29 与 9.21.26，修复十四个安全缺陷，其中一个影响任何应答 DNS-over-HTTPS 的 BIND 服务器：无凭据的发送方发出一个携带无效 SIG(0) 签名的请求，只要在 named 完成签名校验之前断开连接，单个请求即可让 named 进程崩溃。

ISC 称尚未发现这十四个问题中的任何一个被利用。

UnboundBIND 9CVE-2026-81642DNSSEC解析层安全

为什么重要

• 两天、两家实现、同一层：Unbound 与 BIND 是互联网上更广泛部署的两套解析实现，在相邻两天各自发布高危公告。这提示的不是巧合，而是这一层正在被系统性地重新审视，审计密度本身就说明问题。

• 解析器是被主动询问的组件：与等待用户访问的服务不同，解析器会被动响应外部查询。攻击者只需要让一次查询发生，无需知道目标是谁、也无需任何凭据，暴露条件低到几乎只看端口是否可达。

• 安全版本并不安全：Unbound 7 月的安全发布 1.25.2 与 8 月的功能发布 1.26.0 都在受影响之列。把近期已更新当作已完成核验的依据，在这里会直接得出错误结论。

• 可用性与完整性是两件事：BIND 的 DoH 缺陷只造成崩溃，不涉及代码执行，但在解析层上，一次拒绝服务就是一次业务中断。对依赖自建解析的组织而言，可用性风险与入侵风险同样需要进台账。

• 这一层常年不在补丁看板上：解析器通常作为基础设施的一部分由平台或运维团队维护，既不进应用侧的漏洞管理，也不进终端侧的补丁节奏，更新往往跟随操作系统大版本而不是安全公告。

顾问金句

解析层的麻烦在于，它太基础了，基础到没有人把它当作一个需要看护的应用。

建议企业做三件事。

首先，全量清点自建解析器并按实现分类：运行 Unbound 的主机用 unbound -V 或包管理器核对自己落在哪个版本，只要低于 1.26.1 就进本轮处置，不能立即升级的先应用官方针对 CVE-2026-81642 与 CVE-2026-82717 的独立源码补丁；
运行 BIND 的主机核对是否已到 9.20.29 或 9.21.26。

其次，把启用了 DNSSEC 校验、且可从不可信来源触达的实例排到高优先级，这类实例同时满足触发条件与暴露条件，其余实例按可达性排序，不要按版本号的新旧排序。

再者，给解析层单独建一条资产与公告的对应关系——它既不在应用台账里，也不在终端台账里，而两天内两家实现同时发公告的节奏说明，靠操作系统大版本带动更新会稳定地慢一拍。

A4 vm2 两颗满分沙箱逃逸：隔离假设在库级失效，CVE-2026-92953 与 CVE-2026-92948

核心内容

美国国家漏洞库于 9 月 17 日收录 vm2 的两颗高危缺陷。

CVE-2026-92953 评分 10.0，影响 3.11.0 至 3.11.8 之前的版本：这些版本未能保护宿主的 TypedArray 与 ArrayBuffer 原型免受沙箱内的篡改，攻击者可以借助原型遍历原语触达并修改宿主的 Uint8Array.prototype、%TypedArray%.prototype 与 ArrayBuffer.prototype，结果是当 VM.run() 返回之后，宿主创建的定型数组会观察到攻击者控制的属性。

CVE-2026-92948 评分 9.9，影响 3.9.6 及以上的版本区间。

vm2 是 Node.js 生态中常用的进程内沙箱，长期被用于需要执行不可信代码的场景，包括在线代码运行、插件运行时，以及相当一部分 AI 智能体框架中用于隔离模型生成代码的执行环境。

此次缺陷的性质值得单独强调：它没有破坏任何加密算法或校验机制，而是让沙箱内部的修改在沙箱结束之后继续对宿主生效，也就是说隔离并没有在边界上失效，而是从来没有真正闭合。

研究人员的建议并不只停留在升级版本，还包括把 require.root 限制到较小可行的目录集合、使用 context 沙箱模式，以及更根本的一条——不要因为一段代码被 vm2 包裹过，就把它当作可以安全地在进程内运行的不可信代码。

这一类库级沙箱的收口方向是迁移到进程级或容器级隔离，因为宿主与沙箱共享同一个 V8 实例时，原型链本身就是一条共享路径。

vm2CVE-2026-92953沙箱逃逸运行时隔离AI 智能体

为什么重要

• 隔离失效发生在时间维度而不只是空间维度：缺陷的可怕之处不是沙箱内被攻破，而是沙箱结束之后，宿主的定型数组依然带着攻击者植入的属性继续运行。清理动作因此不能只在执行时刻做。

• 它所在的层级决定了影响范围：vm2 运行在进程内，与宿主共享同一个 V8 实例。原型链是两者之间的共享路径，只要存在一条可达路径，库级的封装就无法提供进程级的保证。

• AI 智能体放大了它的实际使用面：相当一部分智能体框架用它隔离模型生成的代码。当代码来源从人变成模型，执行频率与不可预测性同时上升，一个被当作权宜之计的隔离层就变成了生产依赖。

• 与 Plugin4Shell 指向同一件事：一个说插件继承人的权限，一个说沙箱挡不住原型遍历。两者共同说明，智能体的权限边界与隔离边界目前都画在了偏低的层级上。

• 清点比升级更难：vm2 多数时候不是直接依赖，而是作为传递依赖出现在锁文件、monorepo 与研发工具链里。只检查直接依赖会漏掉实际运行它的那条路径。

顾问金句

真正需要回答的问题不是要不要升级 vm2，而是我们凭什么认为一段不可信代码被关住了。

建议企业做四件事。

首先，用依赖树而不是依赖清单来排查：运行 npm ls vm2 并同时检查锁文件、monorepo 与研发工具链，因为 vm2 通常以传递依赖的形式进入环境，只看直接依赖会漏掉真正运行它的那条路径。

其次，把版本要求锁定在不低于 3.11.8，并同时收紧运行时配置——将 require.root 限制到较小可行目录集合、启用 context 沙箱模式，让即使发生同类问题也不至于直接触及宿主全局对象。

再者，也是更根本的一条：为这一段执行规划迁移路径，把隔离边界从库级抬到进程级或容器级，并且从今天起停止在进程内运行来源不可信的代码。

共享同一个 V8 实例时，原型链本身就是一条共享路径，封装得再严也改变不了这个前提。

而后，给 AI 智能体的代码执行单独定一条规则——模型生成的代码应按不可信输入处理，而不是按研发同事提交的代码处理。

A5 自主智能体 25 分钟取得 Baseten 管理员令牌：构建历史里的秘密与一份攻防基准

核心内容

自主渗透智能体 Strix 在 9 月 17 日公开的测试中被指向 Baseten 的域名，初始条件是没有任何凭据、也没有源码，因为该团队在采购前会先扫描供应商。

二十五分钟后，智能体持有一个仍然有效的 GitHub 个人访问令牌，该令牌对 Baseten 的主产品仓库、驱动其集群的 GitOps 仓库与 Homebrew tap 拥有管理员与推送权限，并可读写按客户隔离的私有仓库。

路径值得逐段复盘：侦察阶段发现一个 Harbor 镜像仓库的公共项目允许匿名拉取；
镜像内的一对 AWS 密钥已经失效；
智能体没有只检查文件系统层，而是去检查镜像配置，在构建历史中找到了一个曾作为构建参数传入、用于让 git 拉取私有依赖的令牌，Docker 记录了这个值被展开后的形态。

该构建发生在 2023 年，而这枚令牌在 2026 年 7 月仍然有效。

Baseten 确认该问题为关键级别，已将项目设为私有并在次日下午完成令牌轮换。

同一日公开的还有 Ghost Security 的 OMCC 基准：八个模型在三个故意留有缺陷的应用上完成六项挑战，分别在黑盒、单提示与灰盒三种条件下运行，合计 432 次，只有标识出现在真实服务器响应中才计为捕获。

结果显示所有模型都能可靠地滥用不安全的直接对象引用，而 SQL 注入、JWT 算法混淆与转账逻辑滥用多数要在被告知架构之后才能达成；
更具参考价值的对照组是，剥离了拒绝机制的 Qwen3.8-27B 取得 33 分（满分 54），与同一硬件上未做处理的模型完全相同，上下文窗口长度也与能力不相关。

AI 智能体凭据泄露Docker 构建历史云身份攻防基准

为什么重要

• 删除文件不等于删除秘密：凭据早已从源码里被清掉，却在 Docker 构建历史中完整地保留到三年之后。构建历史是每一个曾触及构建参数的秘密的第二份拷贝，而这一份几乎从不进入任何清理流程。

• 一个依赖拉取令牌不该拥有部署仓库的管理员权限：用于让 git 取私有依赖的凭据，却能对主产品仓库与 GitOps 仓库执行推送。权限范围与用途不匹配，是这一次损失范围被放大的直接原因。

• 智能体的贡献是持续性而不是技巧：它的每一步都不复杂，价值在于逐个以只读方式测试每一份凭据、直到证明影响为止才停止。这种不疲倦的穷举恰好击中了人工审计容易跳过的角落。

• 基准给出了一个反直觉的结论：剥离安全训练没有解锁任何新能力。这意味着围绕模型对齐的管控讨论，与实际攻防能力之间未必存在想象中的强关联，真正的杠杆在外部的权限与架构。

• 采购前的供应商扫描正在成为常态：这次扫描的动机是采购尽调。当买方用自主智能体检查卖方，第三方风险的举证方式会从问卷转向实测，而实测发现的问题会直接回到被扫描方自己身上。

顾问金句

这次事件里没有任何一步算得上高深，真正的问题是那些凭据本该在三年前就失效却一直活着。

建议企业做三件事。

首先，把构建参数与构建历史纳入秘密治理范围：检查镜像配置与构建历史中是否残留曾作为构建参数传入的令牌，规范做法是使用秘密挂载与短时效凭据，而不是把长期令牌写进构建参数——请记住，清理凭据文件对构建历史里的那份拷贝毫无作用。

其次，按用途而不是按项目来签发凭据：用于拉取依赖的令牌不应持有部署仓库的管理员与推送权限，权限范围应当严格匹配用途，并设定可核验的失效时间。

再者，把镜像仓库与制品库的匿名拉取作为一次专项排查项，公共项目允许匿名拉取等于把镜像及其元数据整体交给了互联网。

关于智能体能力的部分，OMCC 的对照组给出了更有用的结论：剥离安全训练没有带来任何能力提升，因此把预算押在模型对齐管控上，收益可能远低于把权限收紧、把凭据缩短、把构建历史清干净。

趋势分析

本周期的五条热点分散在身份、研发、解析、运行时与云凭据五个领域，但它们指向同一个动作：被绕过的不是资产，而是用来判断资产可信的那些机制。

Cisco ISE 决定谁能进入企业接入域，一个未认证请求就直接跨过了它的判据；
四大 AI 编码智能体用 SHA 锁定来保证插件是审查过的那一版，而锁定只在客户端解析、从不校验是否真的落地；
Unbound 与 BIND 在同一天各出一份公告，被污染的正是域名到地址这一层映射；
vm2 承担的是把不可信代码关起来的职责，两颗满分漏洞让这道门形同虚设；
Baseten 的凭据早在文件里被删掉了，却在 Docker 构建历史里完整地活到 2026 年 7 月。

领先条线是判断链的前移：攻击者不再逐台攻破主机，而是先让某个被广泛依赖的判断机制给出错误答案，后面的授权、限流与审计都会对一个伪造的主体做正确判断。

第二条线是隔离边界的层级不够：插件继承使用者权限、库级沙箱挡不住原型遍历、构建参数留下的痕迹不会因为删了源文件而消失，这些都不是补丁能一次性收口的问题，而是边界画错了层级。

对企业而言，本周期要补的三门课是：把已验证从一次性动作改成持续状态，把隔离边界从库级抬到进程与容器级，把秘密清理的定义从删掉文件改成完成轮换。