Certificate Required, Credentials Not: CVE-2026-93952 and the Second VeloCloud Orchestrator 10.0 of the Summer

On 22 September 2026 Arista published Security Advisory 0183 for CVE-2026-93952, a flaw in on-premises VeloCloud Orchestrator (VCO) that it describes as discovered externally and actively exploited. It’s the second CVSS 10.0 against the on-prem VCO in two months, following July’s CVE-2026-16812, and there are three details in the advisory that matter more than the score: it only affects Orchestrators using certificate-based Edge authentication, fixes aren’t out yet for two of the four supported release trains, and the builds that fixed July’s bug are on the affected list.

If you run an on-prem VCO, the short version is at the bottom. If you want to understand why this one is a bit more awkward than it looks, read on.

Why a VCO compromise is the worst place to lose

I covered where the Orchestrator sits in Part 1 of the Arista/VMware SD-WAN Deep Dive: it’s the management plane for the whole estate. Edge configuration, device inventory, certificates, credentials and policy all live there, and every Edge takes instructions from it. Arista’s own post-remediation guidance says it plainly: a compromised VCO may give an attacker access to the Edges it manages.

That lines up uncomfortably with Part 2 of the Edge HA series from earlier this month, where CVE-2026-86108 (OS command injection on the Edge) was scoped down to a high-severity-but-privileged bug precisely because it needed “control of a compromised Orchestrator” as a starting position. CVE-2026-93952 is a way to get that starting position without any credentials at all. Any Edge still on a build vulnerable to the September Edge batch is effectively one hop further away than the CVSS scores on those advisories suggested.

What the advisory actually says

Arista’s description is deliberately thin: a remote attacker may be able to access privileged internal functionality and impact the VCO host, compromising the confidentiality, integrity and availability of the Orchestrator and the data it manages. It’s classified as CWE-20, improper input validation. The Hosted and Dedicated (SaaS) versions of VCO were also affected and Arista has already patched those, so this is an on-prem problem now.

The scoring is worth a second look:

Metric	Score	Vector
CVSS 3.1	10.0	AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS 4.0	9.5	AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

The v3.1 and v4.0 vectors disagree on attack complexity, AC:L versus AC:H, and that difference is the whole story of the precondition below. No privileges, no user interaction, and scope change in both, which is what you’d expect for “unauthenticated to the host of the thing that manages your WAN”.

The precondition: the more secure setup is the exposed one

This is the part I find genuinely interesting. The VCO is only exposed if certificate-based authentication from Edge to Orchestrator is configured, meaning the Certificate Acquire or Certificate Required modes. An attacker also needs network access to the VCO web interface and the public portion of an Edge’s authentication certificate. Tenant or operator credentials are not required.

Two things fall out of that.

First, the irony. Moving device authentication from shared secrets to PKI is the right call, and it’s the same argument I made for Fortinet in the Beyond PSK series. Here, the estates that did the more rigorous thing are the ones in scope. That’s not an argument against certificate auth, it’s a reminder that every new authentication path is new code that has to validate its input properly, and this one apparently didn’t.

Second, “public portion of a certificate” is not much of a barrier. The public half of a certificate is, by design, not secret. I’m not going to speculate on exactly how an attacker obtains a given Edge’s certificate, and Arista doesn’t say, but I’d plan on the assumption that anyone motivated can get hold of one. The real gating factor is network reachability of the VCO web interface, which is why that’s the mitigation that matters most.

Affected and fixed releases

Straight from SA 0183, as of 22 September:

Train	Affected	Fixed in
5.2.x	5.2.3.15 and below	5.2.3.16 or later
6.1.x	6.1.3.7 and below	Not yet available
6.4.x	6.4.2.7 and below	6.4.2.8 or later
7.0.x	7.0.0.2 and below	Not yet available

Arista says fixes for the remaining supported trains are coming and the advisory will be updated when they land. If you’re on a train that’s out of support, the advice is to contact TAC about upgrade options.

Note the knock-on from the July advisory: the releases that fixed CVE-2026-16812 fall inside these affected ranges. If you patched in July and ticked it off, you’re exposed again. And if you’re on 6.1 or 7.0, you currently have no patch to apply, only mitigations.

VeloCloud Edges and Gateways are explicitly listed as not affected by this CVE. The risk to them is second-order, via a compromised Orchestrator.

Indicators of compromise

Arista is upfront that there’s no single definitive indicator, but the advisory does include specifics. If you find any of these, Arista asks you to preserve the VCO’s state and contact TAC:

• Files: /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond, /etc/systemd/system/vc-sysmon.service
• Known malicious vc-sysmond MD5: dc78e206eaeadec59fc5801fe4556bd0
• An x-vc-opt HTTP header in nginx logs
• Connections from 142.93.149.77 or 104.248.126.159

A first pass on the host looks something like this. I haven’t got an on-prem VCO in the lab to verify log locations against, so treat the paths as a starting point and adjust for your build:

# Dropped files and the persistence unit
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond \
       /etc/systemd/system/vc-sysmon.service 2>/dev/null
md5sum /usr/local/sbin/vc-sysmond 2>/dev/null
systemctl status vc-sysmon.service 2>/dev/null

# Known-bad source IPs and the marker header in web logs (including rotated/compressed)
zgrep -E '142\.93\.149\.77|104\.248\.126\.159' /var/log/nginx/*access*
zgrep -i 'x-vc-opt' /var/log/nginx/*

# Anything the VCO host is talking to that it shouldn't be
ss -tnp state established

One caveat on the header check. nginx’s default combined log format doesn’t record arbitrary request headers, so unless your VCO build logs them, not finding x-vc-opt tells you very little. The file checks and the IP checks are the more reliable signals, and your perimeter firewall or NetFlow logs may be a better place to look for those two IPs than the host itself, particularly if the host has already been tampered with.

Beyond the specifics, the advisory suggests reviewing web access logs for unusual URL-like path components, encoded characters, references to local or internal services, and high request rates, then correlating with backend application and system logs around the same timestamps. Unexpected outbound HTTP/S from the VCO, configuration changes nobody made, database exports or archives, and access to certificates or key material are all worth chasing.

Preserve before you remediate. Arista specifically asks for web, backend, system and database logs plus file-system timestamps to be kept before you upgrade or rebuild, where that’s operationally feasible. Upgrading over the top of a compromised host destroys the evidence you’d want later.

What to actually do today

Find out if you’re in scope. On-prem VCO, certificate-based Edge authentication (Certificate Acquire or Certificate Required), and a version in the table above. If you’re on Hosted or Dedicated VCO, Arista has already patched it.

Take the VCO web interface off anything it doesn’t need to be on. This is the one mitigation that directly attacks the precondition. Restrict it to trusted management networks. Remember the Edges need to reach the Orchestrator too, so this is about scoping reachability down to the Edges’ source ranges and your admin networks, not simply slamming the door on the internet and wondering why sites drop off.

Block outbound traffic the VCO doesn’t need. The IOCs point at a backdoor daemon and outbound communication. Egress filtering from the VCO host costs very little and makes a compromised box much less useful.

Patch 5.2 and 6.4 now. 5.2.3.16 or 6.4.2.8 and later. If you’re on 6.1 or 7.0, apply the mitigations, watch the advisory, and patch the day the fix lands.

Hunt before you patch, not after. Run through the IOCs above and preserve logs first.

If you find anything, assume the Edges are in play. Arista’s post-remediation guidance covers credential rotation, reviewing administrator activity, validating managed device state, and restoring or replacing the Orchestrator from trusted sources. Given what a compromised VCO can push to the Edges, I’d add checking the Edges against the September Edge batch fixed releases while you’re at it, since those bugs become much more reachable from a hostile Orchestrator.

Two CVSS 10.0 bugs in the same management plane inside two months, the second one landing on builds that fixed the first, is a pattern rather than bad luck. Whatever process you stood up for July is worth keeping warm.

Source: Arista Security Advisory 0183, 22 September 2026.