A CVSS 10.0 under active exploitation, and two of its four release trains have no patch

A maximum-severity flaw under active exploitation, with half its affected versions unpatched

Arista published Security Advisory 0183 on 22 September 2026, covering CVE-2026-93952 in VeloCloud Orchestrator ^[1][2]. The advisory scores it CVSSv3.1 10.0 and CVSSv4.0 9.5, classifies it as CWE-20 improper input validation, and confirms it is actively exploited ^[1]. The flaw lets a remote attacker “access privileged internal functionality and impact the VCO host” without credentials ^[1][2].

Four release trains are affected: VCO 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 ^[1]. Two fixes exist: 5.2.3.16 and later, and 6.4.2.8 and later ^[1]. The 6.1 and 7.0 trains had no fix at disclosure and still had none in reporting two days later ^{[4][5][9][10]}. Arista said fixes for supported trains were coming and would be added to the advisory when ready ^[4].

That is the finding. A vulnerability at the top of the severity scale, confirmed exploited in the wild, and for half the affected population the vendor’s own primary remediation is unavailable. Mayuresh Dani of Qualys put the position plainly: unpatched versions “remain exposed to active exploitation and have only compensating controls as protection” ^[5].

Exposure is set by authentication mode, not only by version

Three conditions have to hold. The orchestrator must use certificate-based authentication between VeloCloud Edge devices and the VCO; deployments using pre-shared keys are not exposed ^[4][9]. The attacker needs network access to the VCO web interface. And the attacker needs the public portion of an Edge authentication certificate ^[4][10]. No VCO credentials are required ^[9][10].

Only on-premises VCO is affected. Arista records that “Hosted, including Dedicated, versions of VCO were impacted and have already been patched” ^[1]. So the population at risk is the self-managed one, which is also the population that patches on its own schedule.

The practical consequence is that a version sweep alone will not tell an operator whether it is exposed. The authentication mode is a configuration fact that lives outside most asset inventories, and it cuts both ways: it narrows the exploitable population, and it means teams running certificate-based authentication may under-count their own exposure because the version number looked like the whole question.

The blast radius is the fleet, not the host

VeloCloud Orchestrator is the management control plane for an SD-WAN estate. Compromise does not stop at the orchestrator: “A compromised VCO may also give attackers access to the Edge devices it manages” ^[4]. Every branch device the orchestrator controls sits downstream of the flaw ^[8].

Arista’s own guidance makes the incident-response point better than most advisories do: “Patching closes the door but doesn’t reverse what came through it” ^[5]. The advisory therefore asks operators to review logs for anomalous administrator activity rather than treating the upgrade as closure ^[7][8].

Two scores, and two different remediation deadlines

The advisory carries two severity figures for one flaw: 10.0 under CVSS v3.1 and 9.5 under v4.0 ^[1][10]. This is not an error. CVSS v4.0 removed the unified Scope metric and replaced it with separate Vulnerable System and Subsequent System impact metrics, added Attack Requirements as a mandatory base metric, and scores through macrovectors and interpolation rather than v3.1’s weighted formula ^[3]. Divergence between the two versions for the same vulnerability is an expected property of the change, not a disagreement about the bug. Any programme that escalates on “CVSS 10.0” alone will sort this flaw differently depending on which version its feed carries.

The remediation deadline is genuinely disputed in the sources. One account states CISA added the flaw to its Known Exploited Vulnerabilities catalogue with federal remediation required within 48 hours ^[6]. Two others give a three-day deadline of 25 September 2026 under Binding Operational Directive 26-04 ^[7][10]. cisa.gov was not reachable from this desk, so the catalogue entry could not be read directly and both figures are published here as they stand.

This is the sixth VeloCloud advisory this month

Arista’s advisory index shows five VeloCloud advisories dated 9 September 2026 — 0178 through 0182, covering SNMPv3 credentials appearing unencrypted in logs, missing authentication on the Edge high-availability interconnect, an out-of-bounds write in the VCMP tunnel protocol, missing input validation in Edge management workflows, and Edge software updates accepting unsigned bundles — followed by 0183 on 22 September ^[2]. Reporting notes this is the second maximum-severity VeloCloud flaw patched in 2026, and the second actively exploited orchestrator zero-day in three months ^[5][9].

One advisory is a vulnerability. Six in a month across one product family, with the orchestrator flaw exploited before a fix existed for every train, is a supplier-risk signal rather than a patching task.

What to do

• Establish the authentication mode first. Certificate-based Edge-to-VCO authentication is the exposure condition; pre-shared key deployments are not affected ^[4][9].
• Upgrade where a fix exists: 5.2.3.16 or later, 6.4.2.8 or later ^[1]. On 6.1 and 7.0 there is nothing to install, so restrict the VCO web interface to trusted administrative networks and treat that as temporary ^[1][10].
• Hunt the published indicators across the whole exposure window rather than from the patch date: the hidden file /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond, the systemd unit vc-sysmon.service, and the HTTP header x-vc-opt in nginx logs ^[9][10].
• Preserve logs before remediating. A rebuild destroys the evidence that would establish whether the orchestrator was already compromised ^[5][8].
• Assume the managed Edge fleet is in scope of any confirmed orchestrator compromise, and scope the investigation to the devices rather than the appliance ^[4][8].
• Record both severity scores in your own tracking, and key escalation to exploitation status rather than to a single number ^[1][3].

Domain close

The instructive part of this one is not the score. It is the gap between the advice and the estate it is addressed to. “Upgrade immediately” is sound guidance that half the affected installed base cannot follow, because the fix does not exist for the train they run. That leaves network restriction and log review as the actual control, which is a meaningfully weaker position than a patched appliance, and it will persist until Arista ships the remaining trains. Management planes are worth this level of attention because they fail upward: the orchestrator is one host, and it speaks with authority to every branch device in the network.