Summary

Arista has disclosed a critical zero-day (CVE-2026-93952) in its on-premises VeloCloud Orchestrator (VCO), the server that manages the Edge devices in a VeloCloud SD-WAN. Rated CVSS 10.0, the flaw lets a remote attacker take privileged control of the VCO host with no login at all, threatening the confidentiality, integrity, and availability of the orchestrator and everything it manages, and because the orchestrator controls the Edge fleet, one compromise can spread across the network.

Only Arista VeloCloud Orchestrator deployments that authenticate their Edges with certificates are exposed, and an attacker needs network access to the VCO web interface plus the public part of an Edge's certificate, but no credentials. CVE-2026-93952 was found externally and is already being exploited.

Affected Products

CVE

Vulnerability Details

1. #01

   CVE-2026-93952 is an improper input validation weakness (CWE-20) in the on-premises VeloCloud Orchestrator. At its core, the orchestrator does not properly validate certain input it receives, which lets a remote attacker slip past intended boundaries and reach privileged internal functions that should never be exposed to an outside caller.

2. #02

   Exploitation happens over the network against the VCO web interface, and what makes the flaw dangerous is how little the attacker needs: no VCO tenant or operator credentials at all. The one real precondition is configuration-specific, the orchestrator must be set up so that VeloCloud Edges authenticate to it using certificates, and the attacker must hold the public portion of an Edge's authentication certificate. VeloCloud supports three Edge authentication modes, and the two that rely on orchestrator-issued certificates (Certificate Acquire and Certificate Required) are the ones that create the exposure, while a pre-shared-key setup does not. Deployments that limit VCO web access to trusted administrative networks meaningfully reduce the risk.

3. #03

   The vulnerability affects VCO On-Prem releases at or below 5.2.3.15 in the 5.2.x train, 6.1.3.7 in the 6.1.x train, 6.4.2.7 in the 6.4.x train, and 7.0.0.2 in the 7.0.x train. Arista's hosted and dedicated VCO offerings were also affected but have already been patched. The company states plainly that the flaw was discovered externally and is known to be actively exploited, though it has not said when the attacks began or how widespread they are. Investigators have tied the activity to concrete host-level artifacts, a hidden Node.js file (.vcnode.js), a malicious daemon (vc-sysmond) that persists through a systemd service (vc-sysmon.service), an anomalous x-vc-opt HTTP header in nginx logs, and outbound connections to attacker infrastructure, which points to hands-on-host activity rather than mere scanning.

4. #04

   The real-world risk is amplified by an incomplete fix picture. As of Arista's September 22, 2026 advisory, patches exist for the 5.2 train (5.2.3.16 and later) and the 6.4 train (6.4.2.8 and later), but not yet for the 6.1 and 7.0 trains, leaving a meaningful population of orchestrators exposed with no vendor patch to apply. This is also the third actively exploited zero-day Arista has addressed in 2026, following an EOS flaw in May and an earlier VCO flaw in July, so defenders treating VCO as a recurring target rather than a one-off are reading the pattern correctly.

Vulnerability

Recommendations

1. 01
   Patch Without Delay Where Fixes Exist

   Upgrade on-prem VeloCloud Orchestrator to a remediated release as soon as possible: 5.2.3.16 or later on the 5.2 train, and 6.4.2.8 or later on the 6.4 train. For the 6.1.x and 7.0.x trains, where no fix has shipped yet, watch Arista's advisory for updates, and if you are on an unsupported release train, contact Arista's Technical Assistance Center (TAC) about upgrade options.

2. 02
   Hunt for Compromise Now

   Because exploitation is active and patches are still incomplete, assume exposed orchestrators may already be hit. Check the VCO host for the known malicious artifacts (/usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond with MD5 dc78e206eaeadec59fc5801fe4556bd0, and /etc/systemd/system/vc-sysmon.service), review nginx logs for the x-vc-opt header, and look for connections involving 142[.]93[.]149[.]77 and 104[.]248[.]126[.]159.

3. 03
   Restrict Access to the Web Interface

   Until fixes are fully deployed, limit VCO web interface access to trusted administrative networks. This single control significantly narrows who can reach the vulnerable endpoint and is the most effective stopgap Arista recommends for deployments that cannot yet upgrade.

4. 04
   Monitor for Malicious and Outbound Activity

   Watch the orchestrator for inbound requests from known malicious IPs, unexpected outbound HTTP or HTTPS traffic from the VCO host, backdoor daemons, and webshells. Consider blocking outbound ports that normal operation does not require, and review recent administrator activity for changes that do not map to legitimate workflows.

5. 05
   Rotate Credentials and Validate the Fleet After Suspected Compromise

   Because a compromised orchestrator can expose credentials, certificates, and key material and can open a path to the managed Edge devices, follow full incident-response guidance if you suspect exploitation. Rotate affected credentials and certificates, validate the state of managed Edges, and restore or rebuild affected orchestrator instances from trusted sources.

Indicators of Compromise (IoCs)

MITRE ATT&CK TTPs

References & Patch Links

Patch Link

• Arista Advisory 0183https://www.arista.com/en/support/advisories-notices/security-advisory/24765-security-advisory-0183

References

• https://www.arista.com/en/support/advisories-notices/security-advisory/24765-security-advisory-0183