Arista Patched VeloCloud in July. That Build Is Vulnerable to the September Zero Day.

Arista shipped a fix for an actively exploited VeloCloud Orchestrator flaw in July. If you installed it, you are running a build that the September flaw breaks. That is not a hypothetical. It is the version matrix.

The July bug was CVE-2026-16812, an unauthenticated OS command injection on the orchestrator, also rated 10.0. Arista fixed it in VCO 5.2.3.14 for the 5.2 train. The September flaw, CVE-2026-93952, affects everything from 5.2.0 through 5.2.3.15. So the two builds that carry the July fix, 5.2.3.14 and 5.2.3.15, are patched against July and wide open to September. The 6.4 train repeats the pattern, where July was fixed at 6.4.2.4 and September only at 6.4.2.8.

The Build You Were Told to Install Is the Vulnerable One

This is the trap for teams that do the right thing. Patching on the vendor’s schedule, inside the window the vendor set, left them exposed twice in three months on the same appliance. A process that tracked Arista advisories and closed them out correctly produced a system that is now actively exploited.

The Advisory Assumes You Know Why a Public Key Opens a Door

Arista’s advisory says exposure requires certificate based authentication from the edge to the orchestrator, and that access to the public portion of the edge authentication certificate is required. Every write-up repeats that line. None explains the puzzle inside it.

A public key is not a secret. That is the point of public key cryptography. It ships in certificates and travels over the wire where anyone can read it. So a condition that turns on possessing public data cannot be a cryptographic failure. It means the orchestrator accepts something it should have validated, and public certificate data is the cheapest way to satisfy a check that should never have been satisfiable that way.

The CVE record agrees, and this is the part worth quoting. It classifies the weakness as CAPEC-115, authentication bypass, alongside the CWE-20 input validation label. Authentication bypass is the accurate description. An attacker with a network path to the web interface and a copy of something public gets into privileged internal functionality with no tenant or operator credentials.

Which changes the mitigation worth trusting. Arista’s own guidance says restricting web interface access to trusted administrative networks reduces exposure, and that control holds because it removes the network path. Certificate handling is not the lever here.

The Patch Closes the Door, Not the Intruder

Arista says there is no single definitive indicator of compromise and asks operators to correlate logs instead. The artifacts it names are specific. A file at /usr/local/sbin/.vcnode.js. A daemon at /usr/local/sbin/vc-sysmond carrying MD5 dc78e206eaeadec59fc5801fe4556bd0. A systemd unit at /etc/systemd/system/vc-sysmon.service. An x-vc-opt header to search for in nginx logs, and outbound traffic to two named addresses.

Read that as an attacker’s shopping list rather than a signature set. A hidden script, a process named to look like a system monitor, and a unit that restarts it at boot is textbook persistence. Upgrading the orchestrator closes the hole and does not remove whoever got in first, so incident response starts after the upgrade, not before it.

Arista’s remediation note says the same, telling operators to preserve logs and file system timestamps before remediation where feasible. That only makes sense if patching is expected to leave the adversary in place.

There is a compliance dimension too. The CISA entry sits under BOD 26-04, which pairs its deadline with forensic triage requirements. Federal agencies owe documented evidence of intrusion detection, not a change ticket showing the hotfix applied. The 6.1 and 7.0 trains still have no fix at all, so those operators can only restrict access and hunt.

Patching a package does not always patch the problem, and a vCenter flaw made the same point last year. An SD-WAN orchestrator is the trust root for an entire network fabric. Compromising it is not compromising one appliance, it is holding the map.

Three questions worth asking about any on-prem VeloCloud Orchestrator this week. Which build are you on, and does it sit below 5.2.3.16 or 6.4.2.8. Have you looked for a script called vcnode.js and a service called vc-sysmon. And if you find either, do you have a plan that removes an intruder rather than one that closes a door behind them.