️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
基于过去48小时企业决策相关动态提炼
S1 只读账号就能当管理员用——SD-WAN 编排器上被打穿的是权限表本身
核心内容
Arista 在十月二十二日发布安全公告 0199，修掉 VeloCloud Orchestrator（VCO）本地部署上的一颗 SQL 注入缺陷 CVE-2026-114625，CVSS v3.1 9.9、v4.0 9.4，官方同时说明这颗是它自己发现的，且已知正被在野利用。
公告原文写得直白：在受影响的系统上，任何已登录用户都能取得 operator 权限，并伪装成本机的 superuser operator 账号，从而触达一批仅供内部使用、本不该被远程访问的功能；
成功利用会同时危及编排器本身的保密性、完整性与可用性，以及它所管理的那批数据。
门槛是这颗真正要紧的地方——攻击需要两样东西：能连到 VCO 的 Web 界面，以及一个有效的登录会话；
所需角色是 Enterprise Read Only，也就是内置租户角色里只读的那一档。
VCO 默认就把 Web 界面暴露在外，公告写明没有任何一项配置能阻止这种暴露。
受影响的是 5.2.x 早于 5.2.3.18、6.1.x 早于 6.1.3.10、6.4.x 早于 6.4.2.12 的本地部署；
托管版与 Dedicated 同样受影响但厂方已代为修补；
VeloCloud Gateway 与 Edge 不在范围内；
已停止支持的版本厂方没做评估。
这是自七月以来第三颗被在野利用的编排器缺陷，前两颗 CVE-2026-16812 与 CVE-2026-93952 都不需要登录，这一颗正好反过来——它要的是一个账号，任何一个账号。
而打过七月与九月那两颗补丁的版本并不覆盖这一颗，因为那些发布版本都早于本次的修完版本；
6.1 分支上九月那颗至今没有对应的修复版本。
Arista 给出两个在攻击中观察到的来源地址 74.82.197.86 与 38.54.50.151，建议无法立刻升级的组织先把 Web 界面收敛到运维管理区、封堵这两个地址、注视 VCO 主机上非预期的出方向流量，并复查访问日志里异常的路径形态、编码字符、指向内部服务的引用与异常高的请求速率。
AristaVeloCloudCVE-2026-114625SQL注入只读提权
为什么重要
被打穿的是权限表的底端，不是顶端。过去分级的假设是把管理员看住就行，而这一颗只要租户表里只读的那一档就能走到 operator。
编排器是 SD-WAN 的倍增器。它管的是边缘设备的开通、隧道策略、路由与租户划分，一台编排器背后常常是几百个分支站点，拿到它就等于拿到下发权。
前两颗的补丁不覆盖这一颗。七月与九月的修完版本都早于本次的修复版本，因此按公告打过补丁的组织今天仍在射程内；6.1 分支上九月那颗至今没有修复版，等于两颗同时在。
暴露是默认状态，而且没有开关。公告写明不存在能阻止暴露的配置项，这意味着收敛只能放在界面之外——专用接入、跳板机，或者带双向证书校验的前置转发服务。
只读账号在真实环境里数量庞大。托管服务商、审计方、已经撤场的历史集成商手里都可能还留着一份，它们从来没有被当成需要看护的凭据，而现在每一份都是一条到 operator 的路。
顾问金句
这一起要纠的不是 SQL 注入这个类型，而是权限分级这套设计默认服务的是谁。
分级是给内部误操作准备的：它假定拿到只读账号的人只会看、不会改。
而攻击者不需要改这个假定，他只需要借一份只读账号，然后让系统自己把权限交出来。
建议企业做五件事。
首先，把编排器当成域控那一类对象来对待：本地部署的 VCO 只要 Web 界面能从比运维管理区更宽的范围连到，就按已经暴露在外处理——公告写明没有任何配置项能关掉这层暴露，收敛只能放在界面之外。
其次，把版本号逐条比对而不是看上一次维护日期：5.2.3.18、6.1.3.10、6.4.2.12 是三条分支各自的修完版本，七月与九月打过的要重新比一次；
6.1 分支上九月那颗至今没有修复版，这一条要单独向厂方确认。
再者，把只读账号清点一遍并给出停用规则：托管服务商、审计方、已经撤场的历史集成商手里那些只看不改的账号，过去不需要看护，现在每一份都是一条到 operator 的路，休眠的先停掉。
而后，把排查放在修完之后而不是之前：先在 VCO 的访问日志里找异常的路径形态、编码字符、指向内部服务的引用与异常高的请求速率，再查近期有没有非常规的角色变更、新建 operator、配置导出与 API 令牌签发；
怀疑失陷时先把 Web 访问日志、后端应用日志、系统日志、数据库日志与相关文件时间保留下来再动。
另外，把「一台编排器等于一批分支站点」写进自己的风险口径：评估这一颗严重程度时用的单位不是一台设备，而是它下面挂着的站点数与客户数。
S2 官方发布页上那一行版本号没变，变的只是它指向的那份产物
核心内容
LiteLLM 在十月二十一日发布并持续更新的事故说明里确认，其发布流水线当天被接管，官方渠道推出了带恶意代码的 1.107.0：十一点三十九分到五十一分之间，七个预编译安装包被推上 PyPI；
十一点四十六分起，容器镜像（v1.107.0、latest、main-latest、main-stable）也开始提供带毒版本；
十三点二十三分 PyPI 下架，十四点二十分 Docker Hub 上的受影响标签被移除或改指回已验证的干净产物。
官方与研究方给出的当前安全版本是 1.106.2。
恶意代码不在 LiteLLM 的模块里，而是写进了 Python 的启动文件——site-packages 下的 cook.pth、cook.py 与 sitecustomize.py。
这意味着只要在这个环境里启动一次 Python 就会触发，哪怕应用从头到尾没有 import 过 litellm。
它取的东西包括 AWS、Azure、GCP、Kubernetes 与 Docker 的凭据，Git、SSH 与 GPG 密钥，浏览器保存的登录与 cookie、浏览与 shell 历史，以及 Codex、Claude、Gemini、Cursor 这几类工具的认证文件，并尝试从 LiteLLM proxy 部署的数据库里取存起来的模型密钥与配置；
取到的数据加密后发往一个仿冒厂方域名的地址。
入口这一环值得单独看：厂方在自己那个暴露在公网上的内部 LiteLLM 部署里发现了一个名字不起眼的账号，怀疑攻击者先进入这个部署，从它的日志里取到 GitHub CLI 的 OAuth 令牌，再用这些令牌动发布流水线。
而 LiteLLM 自己观察到一个现象——Claude Code 有时会把用户的 GitHub CLI 令牌写进响应体，只要响应体被记进日志，令牌就会出现在日志里。
三名研发者的凭据随后被分别用于改流水线并触发发布、批准生产发布、以及删除工作流记录，这一步直接削掉了可供调查的日志。
构建记录里显示的源仓库是 Berri-AI/litellm，与正式的 BerriAI/litellm 只差一个连字符。
Wiz 的研究人员在数据离开受害者系统约四个半小时后，就看到攻击者开始验证从持续集成运行器与 Kubernetes 节点上取到的 AWS 凭据，并试探能否触达 Amazon Bedrock 上的模型。
Socket 给出的口径是这个包周下载量约两千三百万。
今年三月该项目已经出过一次同类事件。
LiteLLM供应链投毒PyPIAI网关凭据轮换
为什么重要
触发条件不是「用这个库」，而是「在这台机器上跑 Python」。启动文件被执行这一条把影响面从用了 LiteLLM 的服务扩到同一环境里的任何 Python 进程，包括运维脚本与构建任务。
要撤销的不是包，是凭据。PyPI 与 Docker Hub 下架只挡住新的安装；已经装过的环境里那些云密钥、仓库令牌与 SSH 密钥仍然有效，换包不换凭据等于只修了开头。
拿到管理员身份不是前提。入口是一个暴露在公网上的内部部署日志里的一条令牌，而这个令牌之所以会在日志里，是因为 AI 编码工具把它写进了响应体——日志成了凭据的存放处。
流水线上的三道关被三份正常凭据分别满足。改流水线、批准发布、删除记录，每一步用的都是研发者自己的账号，因此在各自的系统里都只是一次正常操作。
从投放到验证只隔了四个半小时。留给企业的窗口不是「看到公告再处理」那几天，而是从安装那一刻起算的几小时。
顾问金句
这一起要纠的不是该不该用开源组件，而是「官方渠道等于已验证」这个默认判断。
版本号没变、发布者没变、流程看起来也没变，变的只有它指向的那份产物。
建议企业做五件事。
首先，把依赖的验收凭据从版本号换成内容：固定版本并同时记录哈希或镜像摘要，升级时比的是产物而不是标签——这一次 latest、main-stable 这类浮动标签都指向了带毒镜像，重新拉一次熟悉的名字并不等于回到干净状态。
其次，把凭据轮换的预案提前写好并按环境分好级：任何装过 1.107.0 的环境都要按凭据已失陷处理，云密钥、仓库令牌、SSH 密钥、浏览器会话与模型服务商密钥分头在干净设备上轮换，顺序按能触达的范围排，而不是按重要性排。
再者，把构建机与持续集成运行器手里的密钥数量当成一项要收敛的指标：这一次的横向扩散正是从运行器与节点上的云凭据开始的，而它们常常为了方便而持有远超需要的权限。
而后，把「日志里会出现什么」单独审一遍：AI 编码工具会把令牌写进响应体，只要响应体被记录，令牌就落进了日志，因此要确认响应体是否入日志、保留多久、谁能读，并且任何自建的内部服务都不应直接暴露在公网上。
另外，把这一类事件的处置从「卸载重装」改成「先隔离取证再重建」：保留包日志、容器元数据与出口流量记录，再从可信来源重建——删除记录这一步已经提醒我们，对方会先动你用来复盘的那份材料。
A3 缺陷在你没有写过的那段代码里，而它跑在你的进程里
核心内容
Node.js 项目在十月二十一日发布安全更新，覆盖 26.x、24.x、22.x 三条在维护的分支，一共十个问题，其中四个为高危。
受关注的一颗是 CVE-2026-111497：随运行时一起分发的 Brotli 解码器存在越界写，处理特制的压缩数据时可导致远程代码执行，修完版本是 26.12.1、24.22.1 与 22.23.4。
这一颗的位置决定了它的性质——它不在应用代码里，也不在应用依赖里，而在运行时自带的第三方库里；
只要应用调用 node:zlib 展开 Brotli 数据，或者 fetch 收到一份 Brotli 压缩的响应，这段代码就会被执行。
因此受影响的条件不是「有没有用某个包」，而是「会不会解压缩对方给的字节」。
另外三颗高危同样落在基础环节上：CVE-2026-105482 是 dns.resolve 处理含空字符的域名时发生截断；
CVE-2026-105483 与 CVE-2026-106069 是两类 TLS 证书主机名校验绕过，前者是全角数字写法的 IP，后者是主机名被松散解析成 IP 地址的情形，两颗都会让本该失败的校验通过。
中危里有一颗值得单独记：CVE-2026-106074，randomUUID() 与 randomInt() 的熵缓存被写进了用户态启动快照与单文件可执行包，于是每一个由同一份快照启动的进程都会重复同一组数值。
上游 Brotli 项目同日发布了 1.2.1、1.1.1 与 1.0.10，因此把这份解码库静态打进自己产物的其他项目同样需要跟上。
另一侧是覆盖范围的口子：Node 20 及更早的分支已经结束支持，不会有修复版，官方的建议是迁移到在维护的分支，而不是等待下载。
Node.jsCVE-2026-111497BrotliTLS校验绕过运行时基线
为什么重要
修复对象是运行时，不是应用。这一类更新不会出现在应用依赖清单里，也不会被依赖扫描提示——它只在你核对运行时版本时出现。
触发条件是「解压了对方给的字节」。请求体、第三方接口返回的响应都算，因此判断在不在范围内要看数据流向，而不是看有没有调用某个函数。
两颗 TLS 主机名绕过削弱的是传输层的身份判断。全角数字与松散解析这两类写法都落在规范允许与实现判断的缝隙里，而校验失败本该是中止连接的那一刻。
结束支持的分支没有修复版。Node 20 及更早需要的是迁移而不是下载，这一条会直接落到容器基础镜像与长期没人动的构建链上。
熵缓存进快照这件事会静默削弱随机性。用同一份快照启动的多个进程会拿到同一组值，而这在会话标识、令牌与随机文件名上都可能出现。
顾问金句
这一起要纠的是把运行时当成底座、把治理范围圈在应用依赖里的那种分法。
应用清单扫得再干净，也扫不到运行时自带的那个解码库，而它以与你相同的权限运行。
建议企业做五件事。
首先，把运行时版本单列一条基线并按分支核对：26.12.1、24.22.1、22.23.4 是这一次的修完版本，逐台主机与逐个容器镜像都要比到具体版本号，不能只回答「我们在用 Node 22」。
其次，把容器镜像的重建当成升级的一部分：把运行时打进镜像的部署，换基础镜像之后必须重新构建并重启服务，只改运行主机上的版本不会改变镜像里那一份。
再者，把已结束支持的分支做成一份迁移清单，而不是一份风险提示：Node 20 及更早不会有修复版，这类分支常常藏在长期没人动的构建链与旁支服务里，要给出明确的迁移时间与责任人。
而后，把数据流向这一条加进排查口径：会不会解压缩来自外部请求的字节、会不会展开第三方接口返回的压缩响应，比有没有调用 zlib 更能回答在不在范围内。
另外，把上游同步纳入观察：上游 Brotli 同日发布了修复版本，把这份库静态链进自己产物的项目同样要动，因此资产表里要能回答你用的这一份是谁构建的。
A4 客户只是把密钥存进了平台，被读走的是平台那一层
核心内容
云应用部署平台 Railway 在十月二十一日发布安全公告，称检测到存放客户环境变量的系统出现异常活动。
初步调查的结论是：未授权的第三方可能访问到了加密形态的环境变量，其中一部分还取到了解密后的内容。
环境变量通常承载的是接口密钥、数据库连接串与私有镜像仓库凭据。
Railway 判断这一起可能与近期针对平台公司的一批攻击有关，攻击方疑似以 AI 推理服务商为目标，平台已通知相关上游服务商主动撤销密钥。
处置动作包括暂停全部部署、按 Enterprise、Pro、Hobby、Free、Trial 的顺序分批恢复构建，并重置全部存储桶的访问密钥、作废其 GitHub 连接令牌；
截至十月二十二日 08:44 UTC，Pro 与 Enterprise 工作区的构建已恢复但部署仍有积压，Hobby 及以下尚未恢复。
平台没有说明攻击者如何进入、暴露从何时开始、涉及多少客户，只说初步分析指向一部分用户，同时建议全部用户立即轮换平台上的环境变量、接口密钥与私有镜像仓库凭据，并复查相关服务日志。
这里有一个容易被忽略的机制：容器只在启动时读取变量，因此在面板上改成新值并不会让正在运行的服务用上，必须重新部署才生效；
而 Railway 自己的那批重置——存储桶密钥与 GitHub 令牌——同样要等重新部署或重新连接才落到服务里。
GitHub 令牌被平台从镜像仓库设置里摘掉之后，在 GitHub 那一侧仍然有效，需要客户自己去撤销。
平台的规模口径是约四百八十万用户、托管超过一千六百万个服务。
Railway环境变量密钥轮换PaaSAI推理服务
为什么重要
失陷的位置在平台侧，客户在自己环境里做过的加固都不改变结果。判定风险时要问的是「我的密钥放在哪一层」，而不是「我的应用有没有缺陷」。
声明里出现了「解密后的内容」这个说法。这说明攻击者可能接触到了密钥在运行过程中以明文存在的那一段，而不只是拿到了加密存储。
目标是 AI 推理服务商。平台自己给出的判断把这起放进了一批针对 AI 服务供应链的行动里，与同期 LiteLLM 那一起指向同一个方向。
轮换要换到上游服务商，而且分两步。改平台上的值只完成一半，另一半是在密钥所属的服务商那里撤销——GitHub 令牌就是典型：平台摘掉后它仍然有效。
平台暂停部署会连带影响客户的发布节奏。恢复是分批的，顺序由平台决定，业务连续性方案里要能容下「对方暂停服务」这一档，而不是只考虑自己这一侧的故障。
顾问金句
这一起要纠的是把密钥托管等同于密钥安全的那种记账方式。
客户做的事情只是把值存进去，而被读走的位置在平台那一层。
建议企业做五件事。
首先，做一份密钥存放位置台账：每一个密钥存在哪一层、属于哪个上游服务商、由谁有权撤销——这一份清单决定了出事时能不能在一天内换完，而这一次平台给的建议正是立即轮换。
其次，把轮换定义成两步并写进流程：先在密钥所属的服务商那里撤销并重新签发，再回到平台上改值并重新部署；
只做后一半的情况下，旧值在服务里仍然有效。
再者，把长生命周期的静态密钥换成短时效凭据或工作负载身份：环境变量里放着永不失效的服务账号密钥，是所有这类事件里损失被放大的共同原因。
而后，把「平台暂停服务」这一档加进业务连续性方案：这一次的恢复是分批次进行的，顺序由平台决定，因此自己这一侧要有可降级路径与可接受的等待时长。
另外，把对平台的问询改成可索取的内容：能不能拿到自己那部分的访问日志、暴露从何时开始、涉及哪些账户；
这一次平台没有说明入口与起始时间，这意味着客户只能回查自己留存的日志，保留时长就成了关键。
A5 补丁五个月前就有了，而那条会话是五月建立的
核心内容
Palo Alto Networks 旗下的 Unit 42 在十月十九日更新了对 CVE-2026-0257 的威胁简报，点名 Qilin 与 INC 两个勒索运营方正在利用这颗 GlobalProtect 认证绕过缺陷进入企业。
成因是防火墙在没有做充分校验与完整性检查的情况下信任了 cookie，使得远程的未认证攻击者可以绕过限制、建立一条未经授权的 VPN 连接，进而绕过一次多因素认证。
受影响的是物理与虚拟防火墙上的 GlobalProtect 门户与网关，以及 Prisma Access；
厂方给出的 CVSS 是 7.8，国家漏洞库后来给了 9.1 的评级。
时间线值得单独看：五月十三日披露，五月二十九日把公告更新为已发现针对未打补丁也未做缓解设备的有限利用尝试，同一天进入已知被利用缺陷目录；
而 Rapid7 报告其客户设备上的本地管理员账号在五月十七日就已被针对，五月二十一日还有第二波进入内网的动作——头一次利用发生在补丁发布后四天。
Unit 42 的事件响应团队自六月起持续调查与该缺陷相关的入侵，涉及医疗、教育、公共部门与能源等行业。
进入之后的动作有一个共性：攻击者用合法的 IT 管理工具做摸底与横向移动，然后直取虚拟化层。
Unit 42 记录的一个案例里，攻击者从被攻陷的 VPN 网关跳到 vCenter 管理设备，关掉 ESXi 宿主机上的安全控制，再用自研工具直接挂载域控制器的虚拟磁盘离线导出凭据——这一步绕开了客户机内部的端点检测与响应。
ReliaQuest 亦观察到 Cobalt Strike、BloodHound 与 SharpHound，并提醒因为流量来自企业自己的 VPN，这类活动看起来与正常远程办公没有区别。
它同时给出一条容易被忽略的建议：打完补丁之后要终止全部活动的 GlobalProtect 会话，因为补丁本身不会移除在此之前已经建立的访问。
GlobalProtectCVE-2026-0257Qilin认证绕过虚拟化层
为什么重要
入口是免认证的。攻击者不需要任何凭据，因此「只读账号」这个层级的讨论在这条路径上完全不适用——它连入口都绕过了。
五个月的利用窗口对未修补者一直开着。补丁五月就有了、同一月进了已知被利用目录，而利用在披露后四天就开始，到十月仍在继续。
打补丁不等于切断已建立的访问。ReliaQuest 明确要求补丁之后终止全部活动会话，因为会话是在补丁之前建立的，不会随升级消失。
攻击直取虚拟化层。跳到 vCenter、关掉宿主机上的安全控制、挂载域控虚拟磁盘离线取凭据，这三步都在操作系统之下完成，客户机内的端点检测看不到。
流量来自自己的 VPN，因此看起来像正常远程办公。这决定了检测锚点不能只放在入口，而要放在进入之后的虚拟化层与凭据使用上。
顾问金句
这一起要纠的是把「已修补」与「已切断」当成同一个动作。
补丁关的是那扇门，而门在五月已经被推开过一次，推开门之后建立的那条会话不会因为升级而消失。
建议企业做五件事。
首先，把修复拆成升级与清理两步并写进同一张工单：升级到修完版本之后，必须终止全部活动的 GlobalProtect 会话并要求重新登录，只做前一步等于把已经建立的访问留在里面。
其次，把认证覆盖 cookie 这项配置单独核一遍：在不需要的场景下直接关掉，确需使用时为它单独签发一张只用于此处的证书，不与其他面向公网的服务共用。
再者，把虚拟化管理层当成一级资产来看：vCenter 与 ESXi 宿主机的访问范围、配置变更与登录记录要和域控同一等级对待，因为这一批攻击者进去之后头一件事就是往这一层走。
而后，把检测锚点从入口挪到进入之后：域名级别的凭据导出、宿主机安全控制被关闭、异常的 VPN 会话，这些信号比边界告警更早出现。
另外，把备份侧的已知缺陷一起排进去：这一批会串接 Veeam 的 CVE-2023-27532，因此备份基础设施的修补优先级不能低于边界设备。
趋势分析
本周期五条热点讲的是同一件事：按需授权正在从一项控制措施，变成一条默认通路。
Arista 那颗编排器缺陷 CVSS v3.1 9.9，所需角色是内置租户角色里只读的那一档——Enterprise Read Only——拿到它就能走到 operator 并伪装成本机 superuser；
VCO 默认就暴露在外，公告写明没有任何配置项能关掉这层暴露。
LiteLLM 那条链路上没有人拿到管理员：入口是一个暴露在公网上的内部部署日志里的 GitHub CLI 令牌，而它之所以会在日志里，是因为 AI 编码工具把令牌写进了响应体。
Node.js 那颗越界写不在应用代码里，也不在应用依赖里，而在运行时自带的解码库里，却以与你相同的权限运行。
Railway 的密钥是客户自己存进去的，被读到的是平台那一层。
GlobalProtect 更彻底——它连账号都不需要。
热门跟贴