Every VeloCloud Orchestrator release that fixed July's exploited flaw falls inside the new CVSS 10.0 bug's range

Four trains, four July fixes, all still in range

On 27 July 2026 Arista told on-premises VeloCloud Orchestrator (VCO) customers to move to 5.2.3.14, 6.1.3.4, 6.4.2.4 or 7.0.0.1 to close CVE-2026-16812, an exploited flaw scored 10.0. On 22 September, 57 days later, it published Security Advisory 0183 for CVE-2026-93952, a second flaw it also scores 10.0 under CVSS 3.1 and also describes as "known to be actively exploited". Its affected ranges run to 5.2.3.15, 6.1.3.7, 6.4.2.7 and 7.0.0.2.

Put the two lists side by side and every release that fixed July's flaw sits inside the new affected range. That is four trains out of four. An organisation that patched promptly in July, on any train, is running a release Arista now lists as affected.

Fixed releases exist for two of those four trains: 5.2.3.16 and 6.4.2.8. For the 6.1 and 7.0 trains the advisory says only that fixes will follow.

This briefing is for the people who run SD-WAN estates and the security teams who answer for them. It covers how to tell whether your orchestrator is exposed, the patch path on each release train, what Arista says to look for in your logs, and why a compromised orchestrator is a larger problem than a compromised router. It deliberately does not describe how the flaw is exploited. Arista has not published that, and a defender does not need it to act.

What Arista has said, and what it has not

VeloCloud has belonged to Arista since it bought the SD-WAN business from Broadcom, which had inherited it with VMware, as reported in July 2025. Advisories for the Orchestrator now come from Arista's PSIRT, not from the VMware advisory series many teams still watch. If your vulnerability feed still keys on VMware or Broadcom for VeloCloud, this is the first thing to fix.

In plain terms: Arista says the flaw may let a remote attacker who has no login reach privileged internal functions of the orchestrator and affect the host it runs on, compromising the orchestrator and the data it manages. The weakness is classed as CWE-20, improper input validation. Arista's CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: network reachable, no privileges, no user interaction, and a changed scope, meaning the vendor scores the impact as reaching beyond the vulnerable component itself.

What Security Advisory 0183 and the NVD record state, checked on 22 September 2026

Question	Stated on the record	Not stated
Is it exploited?	Yes: "discovered externally and is known to be actively exploited"	When attacks began, how many victims, who reported it
Which product?	VCO On-Prem only; Hosted and Dedicated already patched	When the hosted fix went in
Which versions?	5.2.3.15, 6.1.3.7, 6.4.2.7, 7.0.0.2 and below	Whether older unsupported trains are affected
Which setups?	Where Edge to VCO certificate authentication is configured	Which of the certificate modes qualifies
What must the attacker have?	Network access to the VCO web interface and the public part of an Edge certificate	How that certificate is obtained
Fixes?	5.2.3.16 and later; 6.4.2.8 and later	Dates for 6.1 and 7.0 fixes
Link to July's CVE-2026-16812?	Nothing	Whether it is a variant, a bypass or unrelated
Proof of compromise?	"No single definitive indicator"	Which indicators came from which intrusions

Two gaps matter most. The first is attribution of discovery: "discovered externally" tells you Arista did not find it itself, and nothing more. No researcher, incident responder or government agency is named, so there is no second account of the intrusions to check the vendor's against. The second is the relationship to July. The two CVE descriptions open with the same sentence about reaching "privileged internal functionality", and both were exploited before disclosure. That similarity is worth noting and not worth over-reading. Arista has not said the September flaw is a way round the July fix, and this briefing does not claim it.

What "certificate-based setups" means, and why the name misleads

Arista's VeloCloud 7.0 administration guide gives every Edge one of three authentication modes, chosen in the Provision an Edge dialog under SD-WAN service, Configure, Edges, Add Edge. The setting is per Edge, not per profile.

• Certificate Deactivated. The Edge authenticates with a pre-shared key. The guide says the system selects this mode by default.
• Certificate Acquire. The Orchestrator tells the Edge to generate a key pair and send a certificate signing request to the Orchestrator's own certificate authority. Certificates are issued at activation and renewed automatically, and the Edge then uses the certificate to authenticate to the Orchestrator and to build its VCMP tunnels.
• Certificate Required. Only for what the guide calls "static" enterprises, and it refuses peers that present a pre-shared key.

The advisory's exposure condition is that "certificate based authentication from the VeloCloud Edge to VeloCloud Orchestrator (VCO) is configured". It does not name a mode. Both Certificate Acquire and Certificate Required make the Edge authenticate to the Orchestrator with a certificate, so the defensible reading, until Arista says otherwise, is that one Edge in either mode puts the orchestrator in scope. That is our inference, not Arista's wording.

The opposite trap also exists. An estate on pre-shared keys should not conclude it can wait. July's flaw was exposed "by default" with "no configuration that can prevent the exposure", in Arista's words, and the next one may be too. Authentication modes also change: one Edge re-provisioned with a certificate changes the answer for the whole orchestrator. The administration guide page we read describes the setting at provisioning time and does not say where to review it for Edges already in service, so confirm that with your own console or with Arista's Technical Assistance Center (TAC) rather than from memory.

Two scores, two exploitation signals

Arista scored the flaw twice and the two vectors disagree on one input. Under CVSS 3.1 attack complexity is Low and the score is 10.0. Under CVSS 4.0 attack complexity is High and the score is 9.5. The advisory does not explain the difference. A reasonable reading is that the 4.0 vector reflects the certificate precondition, but that is inference. Either number puts it at the top of the queue; the headline 10.0 is simply the older scale.

The public exploitation signals also disagree, for a more ordinary reason: timing.

Exploitation and scoring signals for CVE-2026-93952 as fetched on 22 September 2026, from Arista, NVD and the CISA KEV feed

Source	What it says	What it does not tell you
Arista advisory	Actively exploited; CVSS 3.1 10.0, CVSS 4.0 9.5	Scale, start date or actor
NVD record	Published 22 Sep 08:16 UTC, status Received; vendor scores only	Any NVD assessment of its own
CISA-ADP SSVC in NVD	Exploitation none, automatable yes, technical impact total (13:13 UTC)	It predates any KEV decision
CISA KEV feed	Not listed in catalogue 2026.09.21, released the day before disclosure	Whether or when CISA will add it

Do not wait for the Known Exploited Vulnerabilities catalogue to confirm what the vendor has already said. For comparison, CISA added July's CVE-2026-16812 to the catalogue on 27 July, the day Arista published, with a due date of 30 July: three days. That entry also carries a forensic triage flag, and its ransomware use is recorded as unknown. If CISA follows the same pattern here, expect a listing within days; if it does not, the vendor statement is still the stronger evidence. The SSVC entry's exploitation value of none reflects what CISA's coordinator had recorded at 13:13 UTC, not a finding that the vendor is wrong.

Why the orchestrator is the prize

An SD-WAN orchestrator is the management and control point for every Edge in the estate. It holds the configuration that it pushes to branch appliances, the business policy that decides how traffic leaves each site, the inventory of every location, and the administrator and operator accounts that change all of those. Compromising one Edge gives an attacker a branch. Compromising the orchestrator gives them the tool that manages every branch.

In certificate modes there is a further point. The administration guide says the Edge acquires its certificate from "the Orchestrator's certificate authority". On an estate using certificates, the orchestrator is therefore the issuer the Edges rely on for their identity. Our inference is that a full response to a confirmed compromise has to consider the trust anchored in that authority, not only the passwords on the box. Arista's advisory does not go that far explicitly; it lists credential rotation, review of administrator activity, validation of managed devices and restoration from trusted sources.

That post-remediation list is the telling part of the advisory. A vendor that expected the damage to stay on one server would not tell customers to validate the devices it manages. The changed scope in the CVSS 3.1 vector points the same way. Arista has not said that Edges were tampered with in the attacks it has seen, and this briefing does not say so either. It says the vendor's own guidance treats the Edges as part of the response.

The exposure also sits where it is hardest to see. Arista has patched its Hosted and Dedicated services, so the remaining risk is on orchestrators customers or their service providers run themselves. If a managed service provider runs your SD-WAN, you may not know whether your orchestrator is on-premises in Arista's sense, which release it runs, or how your Edges authenticate. Those are the first three questions to put to the provider today.

How to tell if you are exposed

Answer three questions in order, and write the answers down with the evidence, because you will be asked for them.

1. Whose orchestrator is it? Hosted and Dedicated VCO are patched by Arista. Everything else, including an orchestrator a service provider runs for you on its own infrastructure, should be treated as on-premises until someone confirms otherwise in writing.
2. What exact release is it on? Record the full four-part build, not the train. 6.4.2.7 is affected and 6.4.2.8 is fixed; a note that says "6.4" answers nothing.
3. Does any Edge authenticate with a certificate? Check every Edge, not a sample, because the mode is set per Edge. One Edge on Certificate Acquire or Certificate Required is enough, on our reading, to put the orchestrator in scope.

A fourth question sets the urgency: can the VCO web interface be reached from networks you do not administer? Arista's attacker needs network access to that interface. If it answers on the internet, you are exposed in practice as well as in theory. If only a management network can reach it, you have reduced the risk, which is exactly how Arista describes that control: it reduces exposure, it does not remove it.

Patch path by release train for CVE-2026-93952, from Arista advisories 0183 and 0144 as published on 22 September 2026

Train	Affected by 93952	Fixed in	July fix inside range?
5.2	5.2.3.15 and below	5.2.3.16 and later	Yes: 5.2.3.14
6.1	6.1.3.7 and below	No fix yet	Yes: 6.1.3.4
6.4	6.4.2.7 and below	6.4.2.8 and later	Yes: 6.4.2.4
7.0	7.0.0.2 and below	No fix yet	Yes: 7.0.0.1 was the July cut-off

On 5.2 and 6.4 the path is plain: upgrade to 5.2.3.16 or 6.4.2.8 or later. On 6.1 and 7.0 there is no fixed build as of 22 September, and Arista says fixes for supported trains will be added to the advisory when ready. Customers on unsupported trains are told to contact TAC about upgrade options. Moving from 6.1 or 7.0 to a fixed train is a major-version decision with its own compatibility testing, so raise it with Arista now rather than when the fix lands.

Until a fix is installed, Arista's mitigations are: restrict the VCO web interface to trusted administrative networks; monitor for access from known malicious addresses; monitor for unexpected outbound traffic from the VCO host; consider blocking outbound ports not needed for normal operation; watch for backdoor daemons and webshells; and review recent administrator activity. None of these is a fix. They narrow who can reach the flaw and shorten the time before you notice it being used.

What to check for compromise

Arista's own framing sets expectations: "There is no single definitive indicator of compromise for this issue." It asks operators to review the VCO web access logs for requests with unusual URL-like paths, encoded characters, references to local or internal services, or high request rates, and then to look at backend and system logs around the same timestamps for sensitive configuration changes, privileged maintenance actions outside normal administration, unexpected command execution or file creation, and unexpected outbound HTTP or HTTPS.

It also publishes specific artefacts:

• File /usr/local/sbin/.vcnode.js
• File /usr/local/sbin/vc-sysmond, MD5 dc78e206eaeadec59fc5801fe4556bd0
• File /etc/systemd/system/vc-sysmon.service
• HTTP header x-vc-opt appearing in nginx logs
• Source addresses 142.93.149[.]77 and 104.248.126[.]159

None of the three addresses Arista listed for July's attacks (8.19.75[.]217, 206.72.242[.]124 and 206.72.242[.]162) appears in September's list. That does not show different actors; addresses are cheap to change. It does mean a block list built in July will not catch these.

# Run on a copy of the logs, or on the host only after it has been imaged.
# Adjust log paths to your VCO build; these are placeholders.

# Files Arista lists
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond /etc/systemd/system/vc-sysmon.service
md5sum /usr/local/sbin/vc-sysmond   # compare with dc78e206eaeadec59fc5801fe4556bd0
systemctl status vc-sysmon.service

# Header and addresses Arista lists, across current and rotated nginx logs
zgrep -i 'x-vc-opt' /path/to/nginx/logs/*
zgrep -E '142\.93\.149\.77|104\.248\.126\.159' /path/to/nginx/logs/*

# July's addresses from advisory 0144, if you did not hunt for them then
zgrep -E '8\.19\.75\.217|206\.72\.242\.124|206\.72\.242\.162' /path/to/nginx/logs/*

A clean result from those checks is weak evidence. Named files and addresses are the easiest things for an intruder to change, and Arista has said there is no definitive indicator. Give more weight to the behavioural checks: outbound connections from the orchestrator that your baseline does not explain, administrator accounts or API tokens you did not create, and configuration pushes to Edges that no change ticket accounts for. Where your SIEM already receives the VCO's logs, run the searches there too, since logs held off the host are harder for an intruder to edit.

Reading the vendor fairly

Arista deserves credit for the parts of this it has done well. It said plainly that the flaw is exploited, published file paths, a hash, a header and addresses rather than generalities, told customers to preserve evidence before remediating, and patched its hosted service before disclosure. That is better practice than many network vendors manage.

The gaps are also real, and they fall on customers. Patching the hosted service first is sensible, but it means the on-premises estate learns of an exploited flaw after the vendor's own platform is safe, and the advisory gives no date for that hosted fix. Two of four trains have no fix on the day of disclosure. And the advisory's silence on July leaves customers unable to judge whether the product has one problem that keeps resurfacing or two unrelated ones. None of that is an accusation of bad faith; it is the list of questions an account manager should be able to answer.

What to do, in order

The question to ask

Most teams will ask whether they have patched. The harder question is about the time before the patch. If your estate uses certificates, the orchestrator was the authority your Edges trusted for their identity, and it was reachable by a flaw that was exploited before anyone outside the attackers knew about it. So the question to put to your team, or your provider, is this: if the orchestrator was touched before today, which of the configurations and certificates it has issued would you still trust, and how would you prove it?

Key facts