Arista published Security Advisory 0183 on September 22, 2026 for CVE-2026-93952, an improper input validation flaw (CWE-20) in on-premises VeloCloud Orchestrator, scored CVSSv3.1 10.0 and described there as "discovered externally and is known to be actively exploited." CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a remediation due date of September 25 and a forensic triage requirement. Arista's Hosted and Dedicated tenants "have already been patched."
As of today, September 28, the advisory is at revision 1.1 and names fixed releases for two of the four affected trains: VCO 5.2.3.16 and later in the 5.2.3 train, and 6.4.2.8 and later in the 6.4.2 train. For the rest it says "Releases in other release trains that fix this will be added over time." The deadline was Friday. For half the affected fleet, the release it looks like it is asking for did not exist then and does not now.
What the advisory actually says
Affected, quoted: 5.2.3.15 and below in the 5.2.x train, 6.1.3.7 and below in 6.1.x, 6.4.2.7 and below in 6.4.x, and 7.0.0.2 and below in 7.0.x.
The exploitation precondition is worth reading twice, because the phrase points the wrong way. VCO is exposed if certificate-based authentication from the VeloCloud Edge to the orchestrator is configured, and the attacker needs "access to the public portion of the VeloCloud Edge authentication certificate" plus network access to the VCO web interface. Arista states the rest plainly: "VCO tenant or operator credentials are not required for this exposure." Certificate-based authentication reads like a control. Here it is the precondition.
The same product had CVE-2026-16812 added to KEV on July 27 with a due date of July 30 — also three days, also flagged for forensic triage. The releases that fixed it were 5.2.3.14, 6.1.3.4, 6.4.2.4 and 7.0.0.1. Every one sits inside September's affected ranges. The upgrade that closed the July deadline put you on a release the September advisory calls vulnerable 57 days later, the same shape as JFrog's July fixed version landing inside August's affected range.
The practice: read the required action, not the due date
The KEV entry's own requiredAction field does not say patch. It says: "Apply mitigations in accordance with vendor instructions ... Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable."
That is not the instruction most change processes read, and the three-day clock comes from BOD 26-04 rather than from any judgment about this bug. For a 6.1.x operator, Friday was never blocked on Arista. It was blocked on the six items in the advisory's Mitigation section, which is a separate section from Resolution.
Five of those six change what you can see: monitoring for known malicious source IPs, for unexpected outbound activity, and for backdoor daemons and webshells, plus blocking unneeded outbound ports and reviewing administrator changes. One changes exposure, and Arista says it twice — in Required Configuration ("Deployments that restrict VCO web interface access to trusted administrative networks can reduce risk of exposure") and again in Mitigation. Do that one first.
Its cost is not the ACL. Restricting the orchestrator's web interface to an allow-list breaks whatever reaches it from outside: an on-call engineer at home without VPN, a managed provider's NOC, an automation client calling the API from a cloud egress range. The work is the inventory of who calls the orchestrator, and nobody has one. The version that survives a real change window is to pull a week of VCO web access logs, list the distinct source ranges, allow the ones you can attribute to a person or a system, and put the rest behind the VPN. A range you cannot attribute after a week of logs is a finding on its own.
Do not treat the wait as quiet time. Arista's post-remediation guidance states that compromise of the orchestrator "may allow attackers access to the VeloCloud Edge devices as well," and asks for credential rotation, validation of managed device state, and "restoration or replacement of affected orchestrator instances from trusted sources." The orchestrator is the authority for every branch under it, so the questions that outlive the fix are which edge credentials it held and which branches anyone would notice changing. Both VCO entries in KEV carry the forensic triage flag — CISA asking you to look, not only to fix, the same position as a KEV entry that names no product version to patch. The sweep and the log preservation do not depend on a fixed release, and get harder every day the logs roll.
If the network restriction genuinely cannot happen, the third clause of CISA's sentence is what is left: discontinue use of the product. Decide now, in writing, what would trigger that, rather than in week four with an incident open.
What to check this week
- Which train are you on? 5.2.x below 5.2.3.16 and 6.4.x below 6.4.2.8 have an upgrade. 6.1.x and 7.0.x have none as of September 28.
- Is certificate-based authentication from Edge to Orchestrator configured? Required Configuration makes that the gate on exposure.
- Does the VCO web interface answer from outside your administrative networks? Test from an unrelated network.
- Run the advisory's indicators, and preserve state before remediating:
/usr/local/sbin/.vcnode.js
/usr/local/sbin/vc-sysmond md5 dc78e206eaeadec59fc5801fe4556bd0
/etc/systemd/system/vc-sysmon.service
nginx access logs x-vc-opt request header
connections involving 142.93.149.77, 104.248.126.159
- Do your VCO web access, backend application, system and database logs still cover September 22 onward? If they have rolled, "were we hit" has no answer you can give.
North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of orchestrator-to-edge path review described above. northinfosec.com