New CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited in Certificate-Based Setups

Attackers are exploiting a new flaw in on-premises VeloCloud Orchestrator (VCO), the server that manages the Edge devices in a VeloCloud SD-WAN, Arista said on September 22.

The flaw, tracked as CVE-2026-93952, may allow a remote attacker with no login access to privilege internal functions and affect the VCO host. Only orchestrators set up to authenticate their Edges with certificates are exposed.

As of September 22, fixed releases are out for the 5.2 and 6.4 release trains, but not yet for the 6.1 and 7.0 trains. Arista has already patched the Hosted and Dedicated versions of VCO. The affected releases include those that fixed a different VCO flaw, which Arista reported as exploited in July.

Arista gave the flaw a CVSS 3.1 score of 10.0. A successful attack may compromise the orchestrator and the data it manages. A compromised VCO may also give attackers access to the Edge devices it manages.

Arista said the flaw "was discovered externally and is known to be actively exploited." It did not say when the attacks began or how widespread they are. The Hacker News has contacted Arista for comment.

Which Deployments Are Exposed

VeloCloud Edges can authenticate to the orchestrator in one of three modes. In Certificate Deactivated mode, an Edge uses a pre-shared key (PSK). In Certificate Acquire and Certificate Required modes, it uses a certificate issued by the orchestrator.

Arista said an orchestrator is exposed if "certificate based authentication from the VeloCloud Edge to VeloCloud Orchestrator (VCO) is configured." It did not say which of those modes meets that condition. The attacker also needs network access to the VCO web interface and the public part of an Edge's authentication certificate.

The July flaw did not depend on settings: VCO was exposed to it by default, and no configuration could prevent that.

Fixed Releases

As of September 22, these are the affected releases in each train, the releases that fix them, and the releases that fixed the July flaw:

Train	Affected by CVE-2026-93952	Fixed in	July flaw (CVE-2026-16812) fixed in
5.2	5.2.3.15 and earlier	5.2.3.16 and later	5.2.3.14
6.1	6.1.3.7 and earlier	No fix yet	6.1.3.4
6.4	6.4.2.7 and earlier	6.4.2.8 and later	6.4.2.4
7.0	7.0.0.2 and earlier	No fix yet	No fix listed. 7.0.0.1 and later were not affected.

Arista said fixes for affected trains that are still supported are coming and will be added to its advisory when ready. Customers on an unsupported release train can contact Arista's Technical Assistance Center (TAC) about upgrade options.

If You Cannot Upgrade Yet

Until a fixed release is installed, Arista recommends these steps:

• Limit access to the VCO web interface to trusted administrative networks. This can reduce the risk of exposure.
• Monitor the VCO for access from known malicious IP addresses.
• Monitor for unexpected outbound network traffic from the VCO host.
• Consider blocking outbound ports that are not required for normal operation.
• Monitor for backdoor daemons and webshells.
• Review recent administrator activity for unexpected changes.

Signs of Compromise

Arista said no single indicator proves that a VCO was compromised through this flaw. Check VCO web access logs for requests with unusual URL-like paths, encoded characters, references to local or internal services, or high request rates.

The specific indicators to look for are:

• File: /usr/local/sbin/.vcnode.js
• File: /usr/local/sbin/vc-sysmond
• MD5 (vc-sysmond): dc78e206eaeadec59fc5801fe4556bd0
• File: /etc/systemd/system/vc-sysmon.service
• HTTP header in nginx logs: x-vc-opt
• IP: 142.93.149[.]77
• IP: 104.248.126[.]159

If you find any of these, preserve the state of the VCO and contact TAC or your Arista account team. If you suspect a compromise, save the VCO's web access, backend application, system, and database logs and its file-system timestamps before you fix anything, where that is practical.

Arista also advises incident response after upgrading. That may include rotating credentials, reviewing administrator activity, checking the state of managed Edge devices, and restoring or replacing the orchestrator from trusted sources.