Arista says on-prem VeloCloud is being used, and the July patch is not enough

Arista said this morning that on-prem VeloCloud Orchestrator is being hit. The bug is CVE-2026-93952. They scored it 10.0. The sentence that matters is theirs: discovered outside the company, and already used. Hosted and Dedicated VCO are patched. On-prem boxes that still talk to Edges with certificates are the ones that are open. Tuesday's other clock is the Windows Update Stack. This one is the SD-WAN box that draws the map of every branch.

What the orchestrator actually is

VeloCloud Orchestrator is the server that manages the Edge appliances in a VeloCloud SD-WAN. Compromise the orchestrator and you are not in one closet. You are looking at the inventory, the configs, and a path toward the Edges it manages. Arista is clear that a successful attack can take the host and the data it holds. Tenant or operator passwords are not required. The attacker needs a network path to the VCO web interface and the public part of an Edge authentication certificate. Certificate-based Edge auth is the condition. PSK-only setups are outside that description.

A July VCO bug (CVE-2026-16812) was already exploited and did not depend on a setting. This one does. Shops that patched July and stopped there are still on the affected builds. The July fixes sat one notch below today's: 5.2.3.14, 6.1.3.4, 6.4.2.4. Today's hole is in 5.2.3.15 and earlier, 6.1.3.7 and earlier, 6.4.2.7 and earlier, and 7.0.0.2 and earlier.

What is patched, and what is not

Fixed trains as of this morning: 5.2.3.16 and later, 6.4.2.8 and later. No fix yet for 6.1 or 7.0. Arista says supported trains will get builds and the advisory will grow. Unsupported trains go to TAC. EOS switches are not this product.

Until you can upgrade: put the VCO web interface on a trusted admin network only. Watch outbound traffic that the host should not have. Watch for backdoors and webshells. Review recent admin changes. Arista published hunt items for defenders: files under /usr/local/sbin named .vcnode.js and vc-sysmond, a systemd unit vc-sysmon.service, an nginx header x-vc-opt, and two addresses they listed (142.93.149.77 and 104.248.126.159). Finding any of those is a preserve-and-call-TAC moment, not a reboot-and-hope moment. Save web, app, system, and database logs and file timestamps before you rebuild if you can.

Why a shop in Alberta should care

Plenty of multi-site contractors and mid-size shops bought VeloCloud when it was still a Broadcom conversation and kept the on-prem orchestrator because the hosted bill felt like a loss of control. That box is often on a VLAN that "only IT uses" and still reachable from a VPN pool. Certificate auth was the grown-up setting. It is also the setting that opens this hole. If you do not know whether the orchestrator is hosted or sitting in a rack in Edmonton, that is the first ticket.

What we would do today

• Name the orchestrator. Hosted or Dedicated: confirm Arista patched you. On-prem: write the train and build. 5.2 goes to 5.2.3.16 or later. 6.4 goes to 6.4.2.8 or later. 6.1 and 7.0: TAC, and lock the web UI to admin networks now.
• If the web UI answers from the internet, that is the finding even before the CVE. Pull it back.
• Hunt the vendor indicators. If you get a hit, preserve the host and call TAC. After an upgrade, rotate credentials, review admin activity, and check the Edges the box manages.
• Do not fetch a public test. Arista has not published one in the note we have. The reason to move is their "actively exploited" sentence.

Bottom line

The box that draws the WAN is a computer. Forensic Five will ask whether it is hosted, which build it is on, and who can reach the login. From St. Albert, Alberta. Patch the trains that have a build. Hide the ones that do not. Then finish today's Update Stack KB if you have not.