Arista 的 SD-WAN 管理控制台两个月内第二次出现被利用的 10.0 漏洞，两条发布分支至今无补丁

Arista Networks 于 9 月 22 日修复了 VeloCloud Orchestrator 中的一个漏洞。该公司表示，漏洞由外部发现，且已被用于实际攻击。CVE-2026-93952 的 CVSS 3.1 评分为 10.0，即评分上限。出问题的是本地部署版本的管理控制台——组织运行的每一台 VeloCloud SD-WAN 边缘设备，都由它来开通、配置和监控。CISA 已将其列入"已知被利用漏洞"（KEV）目录，要求联邦民事机构在 9 月 25 日前完成处置。

真正值得注意的不是评分，而是四条受支持的发布分支中，有两条在公告发出时根本没有可用的修复版本。

受影响范围

漏洞成因是 VeloCloud Orchestrator On-Prem 中的输入校验不当。Arista 公告列出的受影响版本与修复版本如下。

由 Arista 自行运营的 Hosted 与 Dedicated 版 Orchestrator 已于 9 月 22 日完成修复。自建自管的客户则要按照各自的节奏推进，而对于 6.1 和 7.0 分支的用户来说，这个节奏目前还没有日期。

一个专挑"谨慎配置"的前提条件

利用并非没有条件。Arista 称，攻击需要该部署在 VeloCloud Edge 与 Orchestrator 之间启用基于证书的认证，同时攻击者要能通过网络访问 Orchestrator 的 Web 界面，并掌握某台 Edge 认证证书的公开部分。使用预共享密钥（PSK）认证边缘设备的部署不受影响。攻击不需要 Orchestrator 的任何凭据。

这个条件的形状值得再看一遍。证书的公开部分本就不是秘密，它恰恰是设计出来用于分发的那一半。而基于证书的边缘认证之所以存在，正是因为向每台分支设备下发同一把共享密钥是更弱的做法。于是落入影响范围的，反而更多是那些选择了更稳妥路径的部署。这一点不该以"运气不好"一笔带过：当前提条件与加固配置重合时，它颠覆了"运维越规范就越安全"这一通常假设。

为什么失守 Orchestrator 格外严重

SD-WAN 的 Orchestrator 不是网络里又一台服务器。它是广域网的控制平面，掌握着路由策略、隧道配置、固件、凭据，以及整个机群中每一台边缘设备的遥测数据——其中很多设备位于没有本地 IT 人员的分支机构。围绕此次公告的报道指出，攻击一旦成功即可触及 Orchestrator 主机上的特权内部功能，那么它所管理的下游边缘设备同样需要打上问号。被攻陷的不是一台机器，而是那台负责向其他机器下达指令的机器。

Arista 公告写明该问题"已知正在被积极利用"（known to be actively exploited），但没有说明攻击始于何时、多少客户受影响、幕后是谁。这种沉默本身就有运维层面的后果：没有起始时间，防守方就无法用"某日之前的活动可以排除"来划定排查范围。

本周该做的事

如果在对应分支上，升级到 5.2.3.16 或 6.4.2.8。如果在 6.1 或 7.0 分支上，能用的控制只有公告给出的那一条：把 Orchestrator Web 界面的访问限制在可信网络内，并在修复版本出现之前，把这项限制当作补丁本身来对待。随后核查管理员操作记录，确认没有无人认领的变更。

在检测方面，Arista 公布了指标：被攻陷主机上出现的两个文件路径 /usr/local/sbin/.vcnode.js 与 /usr/local/sbin/vc-sysmond；nginx 日志中出现的 x-vc-opt HTTP 头；以及攻击中观察到的两个地址 142.93.149.77 和 104.248.126.159。没有发现这些并不等于安全，但一旦发现，结论就很清楚了。

两个月内的第二次

这并不是 VeloCloud Orchestrator 本季度第一个被在野利用的最高危漏洞。7 月下旬的 CVE-2026-16812 同样是 CVSS 10.0，同样被实际利用，同样被 CISA 按 BOD 26-04 的三日处置档收录，而那一个甚至不需要任何特定配置。

同一个管理平面在两个月内出现两个被利用的 10.0，不是连续的坏运气，而是在说明该界面暴露了多少攻击面，以及其中有多少比其所有者以为的更容易从互联网触达。打补丁是眼下的急事，真正长期的工作，是让这台控制广域网的控制台根本不是一个未经认证的陌生人能够访问到的东西。

信息来源： Arista Security Advisory 0183 · BleepingComputer · The Hacker News · SecurityWeek（CVE-2026-16812） · CISA 已知被利用漏洞目录