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. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.