🛡️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
S1 一张社交分享预览图，成了服务端的执行入口：Next.js 9.5 分缺陷已修复
核心内容
Vercel 在 9 月 22 日发布了一次带外的 Next.js 安全更新，修的是 next/og 里 ImageResponse 的一个服务端代码执行缺陷，编号 CVE-2026-94545，厂商公告给出的评级是 9.5 分。
ImageResponse 的作用是让服务端在请求到达时现生成一张图片，更常见的用途是社交平台分享时显示的那张预览卡。
它先把布局交给 Vercel 自家的 Satori 库渲染成 SVG，再转成成品图片。
缺陷的根因就在 Satori 这一层：某些值在进入 SVG 输出之前没有被正确转义，于是一个本该被当作纯文本处理的值，会被当作 SVG 标记来解释。
受影响的范围是 Next.js 16.2.0 到 16.3.5，且必须是跑在 Node.js 运行时上的 ImageResponse 实现，而 Node.js 运行时正是默认选项。
修复版本是 16.3.6，也是 16.x 线上目前仅有的修复版本，16.2 这条线没有回迁，还在 16.2.x 上的应用只能往前走。
Next.js 15.x 不受这条代码执行路径影响，15.5.26 那次发布属于同一批加固；
Edge 运行时的实现也不在范围内，但官方文档已把 Edge 运行时标记为弃用，不建议把它当成规避手段。
Satori 自己单独发布的公告把同一个编号评为 5.3 分，理由是实际影响取决于 SVG 输出被谁拿去用，直接用 Satori 的团队需要升到 0.33.5。
触发条件值得单独记一笔：应用必须在生成图片的过程中，把攻击者可以影响的值放进了 SVG 的内容、属性或样式里。
URL 参数、请求头、表单字段、接口返回值都是常见的通道，而按页面标题、作者、商品名、活动标识生成分享图的做法，几乎正好落在这个模式上。
有一组核对细节会让这次分诊变得麻烦：9 月 23 日有媒体实测，npm audit 并没有把 16.3.5 标为受影响版本，GitHub 安全公告库当时也还没有收录这条公告，公共漏洞库里同样查不到记录——也就是说，依赖自动化工具做版本核对的团队，会得到一个干净的结果。
另外 Satori 是打进 Next.js 包里的，锁文件里看不到它，版本号无法从依赖清单判断。
末了还有一个归属问题：这类对外站点通常由市场或数字团队拥有，更新节奏跟着内容日历走，而不是跟着补丁周期走。
Next.jsCVE-2026-94545CVSS 9.5服务端代码执行Satori
为什么重要
- 它把一个看起来只负责渲染的功能，变成了服务端的执行路径：分享图路由天然对公网开放且不需要认证，而标题、作者、商品名这类值又天然来自请求，两个条件在同一个功能上相遇，风险就不再取决于有没有做输入过滤，而取决于序列化那一层有没有做转义。
- 常用的自动化核对这次会给出错误的安全结论：有媒体在 9 月 23 日实测，审计工具没有把 16.3.5 标为受影响版本，公告库当时也未收录，公共漏洞库查不到记录。靠工具跑一遍就关单的团队，会认为自己不在范围内。
- 版本不可见让外部盘点和内部盘点同时失效：Next.js 应用很少在响应里暴露框架版本，ImageResponse 的用法与运行时属于应用代码而不是服务器配置，外部只能看到框架、看不到版本；而 Satori 被打进包里，锁文件里也不出现。
- 受影响的时间窗比想象中长：受影响的版本从 16.2 发布起就存在，到这次修复已经过去了半年多，而这半年里生成的每一张动态分享图都走了这条路径。
- 责任边界模糊会直接拖慢处置：这类站点通常归市场或数字团队，部署在托管平台上，更新跟着内容发布节奏走，安全团队的补丁要求常常到不了实际动手的人手里。这也是为什么一份只覆盖服务器与终端的资产清单，在这里完全派不上用场。
顾问金句
这次被打开的门，是一个从来没被登记成门的功能。
建议企业做四件事。
首先，用版本号而不是用工具结果来核对：直接检查每个 Next.js 应用实际安装的版本，落在 16.2.0 到 16.3.5 之间且用 Node.js 运行时的，一律按受影响处理并升到 16.3.6，不要以审计工具的结论作为判断依据。
其次，把排查做在代码里而不是做在清单上：在代码库中检索从 next/og 引入 ImageResponse 的位置，重点看路由处理与动态分享图文件，再逐个确认是否有来自请求参数、请求头或接口的值，被放进了 SVG 的内容、属性或样式——这份结果才是真正的受影响名单。
再者，在补丁排上之前先用约束换时间：临时做法是不让攻击者可控的值进入 Node.js 版 ImageResponse 渲染的 SVG，这是争取时间的过渡手段，不是处置的终点；
同时把动态分享图路由纳入外部暴露面的定期核对。
而后，把这一类资产正式纳入变更与补丁管理：对外站点、活动站、文档门户这类由业务团队拥有的属性，需要明确责任人、版本核对节奏与升级通道，否则每一个框架级公告都会变成一次找不到人的分诊。
S2 AI 网关默认不设防：一条未认证请求拿下 Bifrost，顺带取走二十多家供应商密钥
核心内容
JFrog 安全研究团队的 Yuval Moravchick 发现并推动了 Bifrost 一个危急缺陷的披露，编号 CVE-2026-90898，9.8 分，公开时间是 9 月 22 日。
Bifrost 是一个开源的 AI 网关，把来自内部应用的请求分发到二十多家大模型供应商，同时承担认证、路由、限流、用量计量这些职责。
缺陷的形态非常直白：攻击者向管理接口的 /api/mcp/client 端点发一条未认证的 POST，注册一个 stdio 类型的 MCP 客户端，Bifrost 会在任何 MCP 握手发生之前，立刻把注册时指定的命令跑起来，执行身份就是网关进程的用户，官方容器镜像里是 appuser。
修复版本是 transports/v2.1.0，未认证调用方尝试注册 stdio 客户端时会返回 403。
这里有几处容易判断错的地方。
影响条件是管理认证处于关闭状态，而这正是出厂默认配置；
官方二进制默认把管理接口绑在本机上，风险局限在这台机器，但官方容器镜像绑的是所有地址，只要端口被发布出去，管理接口就能从容器外部触达，而在生产部署里发布端口是常见做法。
版本线上，v2.0.0 仍然受影响，那次只修了插件相关的缺陷，没有阻断未认证注册；
1.6.x 到 1.6.11 则两个修复都不包含。
这条缺陷还是一个模式的第三次出现。
同一位研究团队的 Or Peles 在 9 月 6 日披露了 CVE-2026-86242，8.1 分：未认证地向 /api/plugins 注册一个路径为 HTTP 地址的自定义插件，网关会把文件下载下来写成临时共享对象并加载执行，动态链接构建上结果是未认证代码执行，静态链接构建包括官方镜像上降级为服务端请求伪造，修复在 v2.0.0。
再往前，8 月底还修过一个服务端请求伪造缺陷 CVE-2026-55245。
三条缺陷指向同一个根因：管理接口出厂不带认证。
把它放进更长的时间线看会更清楚：今年 4 月已有人指出 MCP 的 stdio 传输存在设计层面的问题并影响主流厂商的官方工具包；
另一个 AI 网关 LiteLLM 的命令注入缺陷则在 6 月因实际被利用而进入已利用漏洞目录。
这条链上真正值钱的不是网关这台机器，而是它保管的东西——所有已接入供应商的接口密钥都在上面，拿到执行能力就等于拿到这些凭据。
厂商给出的处置口径也很明确：凡是曾以认证关闭、管理接口可触达的方式运行过的实例，一律按已失陷处理，轮换虚拟密钥与供应商密钥。
BifrostCVE-2026-90898CVSS 9.8AI 网关MCP
为什么重要
- 它把 AI 网关从流量通道变成了凭据仓库：网关为每一家接入的供应商保存接口密钥，在这台机器上取得命令执行，得到的不只是一个容器的控制权，而是整条 AI 供应链上所有凭据的处置权，还包括可以改写返回给内部应用的应答内容。
- 风险由默认值决定，而不是由配置错误决定：管理认证出厂就是关闭的，官方容器镜像又把管理接口绑在所有地址上。组织并没有做错什么，只是用了默认设置和常见部署方式。
- 一个请求、无需凭据、无需交互，这让扫描的成本低到可以被批量执行：任何能触达管理接口的地址都可能被自动化工具在很短时间内走一遍，而不存在需要社工或需要内网立足点的前置条件。
- 版本线上的部分修复会造成虚假的安全感：升到 v2.0.0 的团队会认为自己已经处理过这个系列的问题，而 v2.0.0 对这条缺陷仍然开放；1.6.x 到 1.6.11 则两个修复都没有。
- 这是一个正在重复的产业级模式，不是一次偶发：这一个项目在一个月内出了三个问题且根因相同，而同类缺陷在另一个网关产品上已经走完了从披露到实际被利用到进入已利用目录的全过程。组织如果还在按单个编号处理，就会一直在追下一张公告。
顾问金句
它不是被配置错的，它是被默认打开的。
建议企业做四件事。
首先，先把资产找出来再谈补丁：盘点组织内部是否部署了 AI 网关、大模型路由层与 MCP 中继类组件，记录版本、部署形态与管理接口的可达范围——这类组件常由业务或平台团队自行引入，不在常规清单上，而它们恰好是凭据集中存放的位置。
其次，把认证默认值当作一项必须主动改掉的设置：为管理接口启用认证并使用强凭据，把管理监听地址从所有地址收回，只放在受控的管理区间内；
在升级到 v2.1.0 之前，这两条是能立刻降低暴露的动作。
再者，按已失陷而不是按待加固来处理历史窗口：凡是在认证关闭且管理接口可触达的状态下运行过的实例，按厂商口径轮换虚拟密钥与全部供应商接口密钥，并复核管理接口与网关日志里有没有非预期的客户端注册与插件注册记录；
升级动作本身不回答过去有没有被用过。
而后，把这一类新入口纳入架构评审的必经项：AI 网关、智能体中继、插件加载点都属于「一个新功能同时带来一个新管理面」的类型，上线前应明确认证方式、监听范围与凭据存放方式。
A3 一万两千个邮箱、没有一次密码泄露：EvilTokens 把授权流程本身做成了产品
核心内容
微软数字化犯罪部门在 9 月 22 日宣布，联合行业伙伴与执法机构取缔了一个名为 EvilTokens 的订阅式钓鱼平台，这是该部门近二十年来第四十次经法院授权的打击行动，也是它首次针对一个端到端由人工智能支撑的犯罪服务。
平台今年 2 月在一个即时通讯渠道上出现，入门费一千五百美元，之后每月五百美元，附带四十多个邮件模板、伪装站点与登录页生成能力、令牌与动态口令的截取能力，以及一个可以读收件箱的对话式助手。
规模是这次更值得记的数字：几个月内有一万两千多个邮箱被攻陷，涉及一万多家组织，集中在美国，其次是加拿大、英国、澳大利亚、印度与法国；
行业分布包括批发分销、建筑、金融服务、房地产、高等教育与医疗。
手法的关键在于受害者从来没有交出过密码。
攻击滥用的是设备码授权这条为电视与输入受限设备设计的合法流程：攻击者在自己的设备上发起登录、拿到一个码，诱导受害者在官方登录页上输入这个码，受害者的身份就被绑到了攻击者的设备上，多因素认证在这个过程中被完整绕过。
而且这种立足点很顽固——后续改密码不会让它失效，除非显式吊销会话与令牌；
部分案例中攻击者在拿到访问权限后十分钟内就注册了新设备。
真正让这次事件值得单独拿出来讲的是后半段。
平台的对话式助手一次可以读完五千封邮件，然后指出谁有权批准付款、这些人向谁汇报、哪些供应商关系可以被利用、什么理由更可能让一笔转账看起来合理，并据此拟写冒充熟人的邮件。
微软的表述是，过去需要人工花几天翻邮件才能拼出来的组织关系图，现在几分钟就能生成；
组织应当假定一旦邮箱被攻陷，犯罪分子理解其中内容的时间以分钟计。
平台本身也有大量由人工智能辅助编写的痕迹，并且调用了多个模型的能力。
处置方面，微软与共同原告医疗信息共享与分析中心在弗吉尼亚东区联邦地方法院获得授权，查封了五十个网站、停用了一百五十多个域名；
伦敦警方逮捕了两名分别为三十二岁与三十八岁的嫌疑人，已保释。
参与方还包括内容分发、数字资产、模型提供、托管、身份情报、漏洞扫描与链上分析等多家机构。
安全公司 Huntress 的观测显示，此类设备码钓鱼在 2026 年同比增长约一千三百八十个百分点，其中一半以上集中在两波关联事件中。
微软给出的两条建议都很具体：在条件访问策略里尽可能阻断设备码授权；
任何要求变更付款信息、改收款账户或审批异常交易的请求，必须通过另一个可信渠道独立核实。
EvilTokens设备码钓鱼多因素认证绕过商业邮件欺诈微软 DCU
为什么重要
- 被绕过的是多因素认证，而不是某一个人的判断力：设备码授权是一条被产品明确支持的合法流程，攻击者不需要偷密码、不需要伪造登录页、不需要诱导用户点的任何一步看起来可疑，用户做的是一件系统明确允许他做的事。
- 立足点比凭据更顽固：改密码不会让访问失效，除非显式吊销会话与令牌并清理已注册设备；部分案例里攻击者在十分钟内完成新设备注册。按重置口令作为标准处置动作的组织，会在处理完之后仍然暴露。
- 人工智能把从进入到变现之间的时间压缩了几个数量级：过去人工翻邮件拼组织关系图需要几天，平台一次读五千封并在几分钟内指出付款权限人、汇报关系与可信的转账理由，还直接拟写冒充邮件。这意味着邮箱被攻陷后的黄金处置时间从天变成了分钟。
- 犯罪能力正在以应用系统产品的形态交付：订阅定价、客户支持、管理面板、模板库、把身份利用与云环境侦察与社工与金融欺诈整合在一个界面里，入门门槛从需要多年经验降到需要一千五百美元。
- 打击一个平台不等于消除这种模式：五十个网站被查封、一百五十多个域名被停用，但工具与手法可以被其他提供者复制；真正持久的防线落在身份侧——令牌保护、异常邮箱行为检测、设备注册审计与对付款变更的第二渠道核实。
顾问金句
他没有偷到密码，他让用户自己把门打开，还请用户帮忙扶着。
建议企业做四件事。
首先，把设备码授权这条通道按使用情况明确处置：在统一身份平台的条件访问策略里评估是否可以整体阻断，确有业务需要的，限定到具体人群与具体网段位置，并对新设备注册建立告警；
这一条是这次事件里收益高的单点动作。
其次，把账号应急处置的动作从重置口令升级为吊销会话：明确处置清单必须包含吊销刷新令牌、撤销已授权应用、清理已注册设备与重新核验转发规则与委派设置，改密码只是这张清单上的其中一项，不能作为完成标志。
再者，把付款流程改成必须双通道确认的硬控制：凡是要求变更收款账户、改付款信息或审批异常金额的请求，一律要求通过另一个独立渠道向已知联系人核实，并且这项要求要写成财务制度而不是安全意识提示——这次事件里被利用的正是信任关系本身。
而后，为邮箱侧补上行为观测：重点关注异常位置的登录、批量读取邮件、新建转发或委派规则、短时间内大量下载，以及新设备注册后立即发生的敏感会话访问；
这些动作单看都不触发告警，连起来才是这次的攻击链。
A4 上游两个月前就修好了，发行版还没送到：Ubuntu 容器逃逸缺陷出现公开利用代码
核心内容
一条 Linux 内核缺陷正在因为补丁没有抵达而变得实际可利用：AF_UNIX 套接字子系统中的释放后使用，编号 CVE-2026-80521，评分 7.8 分。
影响是直接的——攻击者可以借此从容器里逃出来，在宿主机上拿到 root 权限。
时间线是这件事的重点。
缺陷在上游已于 8 月 6 日修复，但 Ubuntu 的 26.04、24.04 与 22.04 三个长期支持版本到 9 月 24 日仍未收到修复；
而这三个版本正是公有云上更常见的镜像基础，亚马逊、微软与谷歌三家云上的大量工作负载都跑在它们之上。
安全公司 DepthFirst 在这个背景下发布了针对 Ubuntu 26.04 的利用代码，并在建议里提到应当考虑用微型虚拟机做隔离。
目前没有公开的实际攻击报告，也没有任何临时变通方案。
把这几件事放在一起看，这属于一种很典型、也很容易被误判的风险形态：它既不是零日，也不是没有补丁，更不是厂商不作为，它只是卡在了从上游内核到发行版再到镜像再到实例的这条链路上。
而容器与宿主机共享内核这一事实，决定了这个位置上的任何一个缺陷都是跨租户级别的——隔离边界并不在容器那一层，而在内核那一层。
给企业的动作很明确：不要因为自己的镜像是基于一个受支持的长期支持版本就认为安全状态是达标的，需要单独核对内核包的实际版本与上游修复的对应关系；
在发行版修复到达之前，对运行不可信或多租户工作负载的节点，考虑改用微型虚拟机或其他形式的强隔离，并把容器的权限、可访问的设备与系统调用面收紧到业务所需的必要集合。
UbuntuCVE-2026-80521容器逃逸AF_UNIX内核补丁滞后
为什么重要
- 补丁存在不等于补丁抵达：上游在 8 月 6 日已经修复，而三个长期支持版本至今未收到。依赖「我们用的是受支持的长期支持版本」作为安全结论的组织，在这次会得到错误的达标判断。
- 共享内核决定了这是跨租户级别的问题：容器之间、容器与宿主机之间并不存在独立的内核边界，一个容器里的逃逸拿到的是宿主机 root，而宿主机上通常还跑着其他租户或其他业务的工作负载。
- 利用代码已经公开而修复尚未到达，这个组合本身就是高风险窗口：即便当前没有实际攻击报告，从公开利用到自动化扫描之间的间隔在近年来持续缩短，而这一次的缓解手段几乎只剩架构层面的隔离。
- 受影响的是三家主流公有云上的默认镜像基础：22.04、24.04 与 26.04 覆盖了绝大多数云上实例的操作系统底座，排查范围因此不是某几台机器，而是整个镜像体系。
- 没有变通方案意味着排期上只有两条路：要么等发行版并把风险敞口留在原地，要么在架构上换隔离方式。这是一个需要提前做决策而不是等公告的问题，因为等公告期间暴露面不会缩小。
顾问金句
补丁两个月前就写好了，只是还没走到这台机器上。
建议企业做四件事。
首先，把核对口径从发行版版本改成内核包版本：不要以长期支持版本的受支持状态作为结论，逐台或按镜像基线核对内核包的实际版本与上游修复提交的对应关系，把结果做成可复核的清单而不是一次性的口头确认。
其次，为多租户与不可信工作负载准备强隔离方案：在发行版修复到达之前，评估把这类负载迁到微型虚拟机或其他独立内核的隔离形态上，并把容器的权限、可挂载设备与系统调用面收紧到业务所需的必要集合；
这一条是当下少数真正有效的缓解手段。
再者，把镜像流水线纳入补丁追踪：基础镜像的构建应当能回答「内核包当前落后上游多少个安全修复」这个问题，并在发行版修复发布后能在可控周期内完成重建与灰度，而不是等下一次业务发布顺带更新。
而后，为容器逃逸建立行为侧观测：关注容器进程对宿主机路径的访问、异常的设备与内核接口调用、非预期的命名空间与能力变化，这类行为在单一控制台上不判为高危，但正是这条链的落地动作。
A5 一个几乎全由真实内容组成的假站点：三枚零日串成的链与它的共享工具包
核心内容
安全公司 Volexity 披露了一次由三枚零日串成的攻击活动，攻击者是它追踪编号为 UTA0565 的团伙，行动时间是 9 月 3 日与 4 日，当时三枚缺陷都还没有补丁。
投递方式值得单独记：攻击者搭建的是克隆站点，而这些站点的大部分内容是从被冒充的组织那里实时加载的，看起来真实是因为它确实是真实的，真正危险的部分被放进了一个隐藏帧——里面是两枚 Chrome 缺陷与一枚 Windows 提权缺陷。
链条的顺序是先用 CVE-2026-85046 与 CVE-2026-87491 突破浏览器沙箱，再用 Windows 高级本地过程调用中的 CVE-2026-85880 完成提权，其中 Windows 这一枚由微软在 9 月 8 日披露。
末段载荷名为 chrome_cleanup.exe，被去掉了来源标记后经系统外壳启动，安装在一个以输入法组件命名的路径下，并创建计划任务维持驻留。
Volexity 把这个此前没有记录的恶意程序家族命名为 CLEANGULP，它支持命令执行、进程列举、文件上传与下载，以及加载执行信标对象文件；
通信走明文 HTTP，但消息体用一套自定义字母表做了编码。
目标包括亚洲地区的公共部门、媒体机构与企业培训机构等。
这次披露里更值得带走的一条判断不在技术上：Volexity 此前已经报告过两个不同团伙使用同一套核心利用链，UTA0565 是第三个。
研究方的判断是，这套工具包在更广泛的社群内被共享、定制与再次武器化，但这并不等于这些团伙属于同一个组织。
换句话说，补丁关闭的是这几个编号，而投递方式与工具流转方式会完整保留下来。
排查清单也给得很具体：确认终端上的浏览器与操作系统两处补丁都到位，而不只是浏览器更新；
在邮件与转发层日志里检索已披露的仿冒域名与相关基础设施；
在终端上狩猎那个特定文件名的可执行文件、以输入法命名的计划任务，以及本地应用数据路径下的异常执行；
检查是否有页面从合法域名加载绝大部分内容、却附加了隐藏的本地帧或脚本；
把定向访问期间出现的浏览器崩溃或更新提示当作可能的利用信号来看待。
CLEANGULPCVE-2026-85880零日利用链克隆站点Volexity
为什么重要
- 被伪造的不是网页，而是「真实」这个判断本身：克隆站点的大部分内容来自被冒充的组织自己，用户看到的一切都是真的，危险的部分藏在看不见的帧里。以域名与页面观感为依据的判断方式在这里完全失效。
- 一次访问就足以完成从进入到驻留的全过程：两枚浏览器缺陷负责出沙箱，一枚操作系统缺陷负责提权，三段拼在一起把一次点击变成了终端上的一个持久立足点，中间没有任何需要用户确认的环节。
- 补丁只关闭编号，不关闭方法：研究方判断这套利用链已在至少三个团伙之间流转并被定制。组织需要按「这套方法还会再来」来准备检测能力，而不是按「这几个编号已经修好」来关闭工单。
- 修复必须同时覆盖浏览器与操作系统：只做浏览器更新的组织会留下提权那一环仍然可用，而这恰恰是决定攻击者拿到的是普通权限还是系统权限的一段。
- 攻击早于披露近三周，报告又晚于补丁一周多：行动发生在 9 月 3 日至 4 日，操作系统缺陷 9 月 8 日披露，完整报告到 9 月下旬才公开。这意味着在做追溯排查时，需要覆盖的时间窗远大于「看到公告之后」。
顾问金句
他没有伪造一个网站，他借了一个真的网站，然后把危险的那部分藏在你不会看的地方。
建议企业做四件事。
首先，把补丁核对做成双端一致性检查：确认每台的浏览器与操作系统两处对应缺陷都已修复，只更新浏览器的终端在这一次仍然留下提权路径；
核对结果按终端粒度落表，而不是按更新策略落表。
其次，按已知指标做一轮追溯式排查，并把时间窗向前覆盖到补丁之前：检索邮件与转发层日志里的仿冒域名与相关基础设施，狩猎那个特定文件名的可执行文件、以输入法命名的计划任务，以及本地应用数据路径下的异常执行；
不要只看公告发布之后。
再者，为高价值人群加固而不是面向所有终端平均投入：承担对外事务、政策研究与区域业务职能的岗位是这次的定向对象，浏览器加固、应用白名单、终端检测覆盖与抗钓鱼的多因素认证，应当优先投放在这些人身上，而不是平均分配。
而后，把异常体验纳入上报口径：定向访问期间出现的浏览器崩溃、异常更新提示与未知计划任务创建，都应当是可被一线人员一键上报的信号；
这类信号单看都很小，但它是这次链条上极少数在早期就能被人类感知到的部分。
趋势分析
本周期五条热点落在一个共同的位置：被攻破的不是加固过的那扇门，而是从未被当作门的地方。
Vercel 在 9 月 22 日带外修复了 Next.js 的 next/og ImageResponse 服务端代码执行缺陷，CVE-2026-94545，9.5 分——一个用来生成社交分享预览图的功能，因为上游 Satori 没有正确转义，把请求里的一个参数变成了服务端可以执行的东西；
同一天 JFrog 披露开源 AI 网关 Bifrost 的 CVE-2026-90898，9.8 分，一条未认证的 POST 到管理接口就能注册一个 stdio 类型的 MCP 客户端，而网关在握手之前就把命令跑了起来，同时它还保管着二十多家大模型供应商的接口密钥；
微软数字化犯罪部门也在同一天宣布取缔 EvilTokens，这个平台用设备码授权这条为电视设计的合法流程绕过多因素认证，几个月内拿下一万两千个邮箱、涉及一万多家组织，并用人工智能在几分钟内读完收件箱、找出谁有权付款、该冒充谁。
另外两条讲的是同一件事的另一半：Ubuntu 上 AF_UNIX 的一个释放后使用缺陷让容器可以逃逸到主机 root，上游 8 月 6 日就修了，三个长期支持版本至今没有收到；
Volexity 披露的 UTA0565 把两枚 Chrome 缺陷与一枚 Windows 提权缺陷串成一条链，投放在一个几乎完全由真实内容组成的克隆站点里，危险的那部分藏在一个没人会去看的隐藏帧中。
把这五件放在一起看，主线很清楚：暴露面越来越多地由默认值决定，而不是由策略决定——默认不做转义的图片渲染、默认不设认证的管理接口、默认开放的设备码授权、默认共享的内核、默认相信长得像真的页面。
第二个信号是修复与抵达之间的时间差正在独立造成伤害：补丁已经存在但发行版没有跟进，版本号已经修好但审计工具不报，攻击发生在九月初而报告要到九月下旬才公开，认证关掉跑过的实例需要按已失陷处理而不是按待加固处理。
