Vulnerabilities

Arista has confirmed active exploitation of CVE-2026-93952, a CVSS 10.0 flaw in VeloCloud Orchestrator (VCO), the on-premises console that configures and manages every branch-office Edge device in an Arista (formerly VMware) SD-WAN deployment. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on September 22, 2026, in a batch of four, alongside two Check Point flaws and an F5 BIG-IP APM bug we cover in separate posts. This one stands on its own: it hits the single system that can push configuration to every SD-WAN site an organization runs.

The flaw only matters if your VCO is set up to authenticate branch Edges by certificate, but where that mode is on, an attacker needs no VCO login at all, just network reach to the web console and one piece of information that is not supposed to be secret in the first place. Fixes exist for two of VCO's four release trains. Two others, as of this writing, do not.

How it works

VCO is the control plane for Arista's SD-WAN (software-defined wide area network) product, a way of connecting branch offices over ordinary internet links using centrally managed, encrypted overlay tunnels instead of dedicated private circuits. Every site runs an Edge appliance, and every Edge answers to one VCO, which pushes configuration, routing policy and firmware updates to the whole fleet from one place. That centralization is the point of the product, and it is also why a working bypass against VCO itself is worth far more to an attacker than one against a single Edge.

Before VCO will act on instructions tied to a given Edge, that Edge has to authenticate. Arista supports more than one way to do this, and one of them is certificate-based: each Edge holds a certificate, and VCO checks it as part of establishing trust. CVE-2026-93952 is an improper input validation flaw, tracked under weakness class CWE-20, in how VCO's web interface handles requests when this certificate mode is configured. A request crafted against the flawed handling reaches privileged internal VCO functionality without ever completing a real login, and without any tenant or operator credential.

Two things make this reachable: network access to the VCO web interface, the same console operators use, and "the public portion of a VeloCloud Edge authentication certificate," in Arista's own wording. That second requirement sounds like it should stop most attackers, and it does not, because a certificate is two mathematically linked halves that do very different jobs. The private half has to stay secret; it is what actually proves identity, and losing it is a real compromise. The public half exists to be shared. It goes out openly in every TLS handshake the Edge performs, it can be pulled from a device's own configuration export, and it can be picked up passively by anyone watching the SD-WAN traffic between a branch and its Orchestrator. None of that requires breaking cryptography or stealing a secret key. It requires seeing one legitimate Edge's traffic, or getting even low-level access to one branch device, and then pointing a request at VCO's web console. For anyone who has already compromised one branch router, or who has visibility into an organization's SD-WAN links, that is a realistic bar, not a theoretical one.

A successful hit compromises the confidentiality, integrity and availability of the Orchestrator itself, plus every Edge device and every piece of data it manages, because VCO is the one control point the whole fleet trusts.

What attackers are doing

Arista's advisory says the issue "was discovered externally and is known to be actively exploited," without naming the attacker or a first-seen date. CISA's September 22 KEV addition covered four unrelated flaws that day: two Check Point vulnerabilities (CVE-2026-85102, improper certificate validation, and CVE-2026-93616, a path traversal bug) and an F5 BIG-IP APM buffer overflow (CVE-2026-94127), each with its own root cause and its own post here. Federal civilian agencies were given until September 25, a three-day window, one of the tightest CISA sets and reserved for the flaws it treats as most urgent. Given that one successful request against an internet-facing VCO can reach every Edge behind it, that urgency tracks with what the bug actually puts at risk, even without a public account of a specific victim yet.

What to do

1. Patch, if your train has a fix. VCO 5.2.3.16 and later closes it on the 5.2.x train (vulnerable at 5.2.3.15 and earlier), and 6.4.2.8 and later closes it on the 6.4.x train (vulnerable at 6.4.2.7 and earlier). As of this writing, Arista's advisory lists fixes for the 6.1.x train (vulnerable at 6.1.3.7 and earlier) and the 7.0.x train (vulnerable at 7.0.0.2 and earlier) as still pending, an unusual gap for a CVSS 10.0 bug under active exploitation. Check the advisory directly before assuming your version is covered. Hosted and Dedicated VCO, the cloud-managed deployment options, were already patched by Arista and are not affected; this is an on-premises VCO issue.

2. If you are on 6.1.x or 7.0.x, or cannot patch today. Restrict access to the VCO web interface to a trusted management network, exactly as Arista's advisory recommends; it should never be reachable from the general internet. If certificate-based Edge-to-VCO authentication is not something you specifically need, switch Edge authentication to pre-shared key (PSK) mode until a fix ships. That removes the precondition the flaw depends on rather than just narrowing who can reach it.

3. Check whether you were already hit. Arista's own advisory is explicit that there is no single definitive indicator of compromise for this issue, so a clean scan for the following does not clear a system on its own: two files under /usr/local/sbin, .vcnode.js and vc-sysmond (MD5 dc78e206eaeadec59fc5801fe4556bd0), a systemd unit at /etc/systemd/system/vc-sysmon.service nobody on your team created, the HTTP header x-vc-opt showing up in nginx access logs, and outbound connections to 142.93.149.77 or 104.248.126.159. Beyond those specific artifacts, review VCO's own access logs for requests to privileged internal endpoints from source IPs you do not recognize, or that never went through a normal login flow first, and audit the configuration currently pushed to every Edge for changes your operations team did not make; because VCO configures the whole fleet from one place, a single successful exploitation can alter branch configuration far from wherever the request actually landed.

4. If you find something. Treat every Edge certificate used in certificate-based mode, and every operator or tenant credential VCO holds, as exposed, and rotate them once the Orchestrator itself is confirmed clean. A compromised control plane had the same visibility into your SD-WAN that your own operations team has.

A centralized management console with no way to scope who can reach it, sitting on an unpatched release train, is a platform and identity problem as much as a patching one. Our platform and cloud engineering work builds the account structure, network layout and access boundaries that keep a console like this off the open internet in the first place, and our attack surface management work is what puts an internet-facing VCO on a list to check the day a KEV entry like this lands. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Arista Security Advisory 0183, CISA: four KEV additions, September 22, 2026, CISA KEV catalog, CVE-2026-93952, IONIX threat center, Vijilan, Rescana.