Arista VeloCloud Flaw Exploited, Scores 10.0

Arista has disclosed that attackers are actively exploiting a maximum-severity vulnerability in the on-premises version of its VeloCloud Orchestrator, the server that manages the Edge devices in a VeloCloud SD-WAN deployment. The flaw, tracked as CVE-2026-93952, carries a CVSS 3.1 score of 10.0 and affects only orchestrators configured to authenticate their Edges with certificates.

The company's advisory surfaced on September 22, alongside a note that fixes are already out for two of the four release trains that carry the flaw. The remaining two trains are still waiting on patches, and Arista has not said when the attacks began or how many deployments have been hit.

A Maximum-Severity Score

The CVSS 3.1 rating of 10.0 is the highest score the scale allows. Arista described the flaw as one that may let a remote attacker with no login access privilege internal functions and affect the VCO host. In practice, that means an unauthenticated outsider does not need a valid account to reach the vulnerable code path — they need network access to the orchestrator's web interface and the public part of an Edge's authentication certificate.

A successful attack may compromise the orchestrator and the data it manages. Because the VCO is the hub that manages Edge devices, a compromised orchestrator may also open a path to the Edges it controls. 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.

The disclosure is the second VeloCloud Orchestrator problem Arista has reported in recent months. The earlier flaw, tracked as CVE-2026-16812, was exploited in July. Notably, the affected releases for the new flaw include versions that had already been patched for the July issue.

Certificate-Based Setups Are Exposed

Exposure hinges on how an Edge authenticates to the orchestrator. VeloCloud Edges can authenticate 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." The advisory does not specify which of those two certificate modes meets that condition, leaving administrators to confirm their own configuration against the description.

That is a meaningful difference from the July flaw. According to Arista's account, that earlier bug did not depend on settings at all: VCO was exposed by default, and no configuration choice could prevent it. The new flaw narrows the exposed population to certificate-based setups, but the attacker still needs reachability to the VCO web interface plus the public portion of an Edge's authentication certificate.

Arista has already patched the Hosted and Dedicated versions of VCO, so those customers are not waiting on a fix. The on-premises deployments are the ones that must be upgraded or mitigated by hand.

Which Trains Have Fixes Today

As of September 22, fixed releases exist for the 5.2 and 6.4 release trains. The 6.1 and 7.0 trains have no fix yet. Arista said fixes for affected trains that are still supported are coming and will be added to its advisory when ready.

The version boundaries matter because the affected ranges include releases that already addressed the July flaw. For the 5.2 train, affected releases are 5.2.3.15 and earlier, with the fix landing in 5.2.3.16 and later. The July flaw had been fixed in 5.2.3.14.

For 6.4, affected releases are 6.4.2.7 and earlier, fixed in 6.4.2.8 and later. The July flaw was fixed in 6.4.2.4. The 6.1 train lists affected releases as 6.1.3.7 and earlier with no fix yet, while the July flaw had been fixed in 6.1.3.4. The 7.0 train lists 7.0.0.2 and earlier as affected with no fix yet, and no fix listed for the July flaw — 7.0.0.1 and later were not affected by that earlier issue.

• 5.2 train: affected in 5.2.3.15 and earlier; fixed in 5.2.3.16 and later.
• 6.1 train: affected in 6.1.3.7 and earlier; no fix yet as of September 22.
• 6.4 train: affected in 6.4.2.7 and earlier; fixed in 6.4.2.8 and later.
• 7.0 train: affected in 7.0.0.2 and earlier; no fix yet as of September 22.

Customers on an unsupported release train can contact Arista's Technical Assistance Center (TAC) about upgrade options, according to the advisory. The fixed releases are listed on Arista's security advisory.

Interim Hardening Before You Upgrade

Arista published a set of recommendations for teams that cannot install a fixed release right away. The first is to limit access to the VCO web interface to trusted administrative networks, which the advisory says can reduce the risk of exposure. That aligns with the attacker requirement for network reachability to the web interface.

The remaining steps are detection-oriented. Arista recommends monitoring the VCO for access from known malicious IP addresses, watching for unexpected outbound network traffic from the VCO host, and considering a block on outbound ports that are not required for normal operation. It also recommends monitoring for backdoor daemons and webshells, and reviewing recent administrator activity for unexpected changes.

None of these steps substitutes for upgrading. They are stopgaps meant to shrink the window while a patched release is tested and deployed, particularly for teams on the 6.1 and 7.0 trains that have no fix available yet.

Indicators of Compromise to Hunt For

Arista cautioned that no single indicator proves a VCO was compromised through this flaw. Its guidance is to check VCO web access logs for requests with unusual URL-like paths, encoded characters, references to local or internal services, or high request rates — patterns that can accompany exploitation attempts against a web-facing interface.

The advisory lists specific artifacts to look for. Two are files on the host: /usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond. The MD5 hash for vc-sysmond is dc78e206eaeadec59fc5801fe4556bd0. A third artifact is a systemd unit file at /etc/systemd/system/vc-sysmon.service.

On the network side, Arista points to an HTTP header in nginx logs — x-vc-opt — and two IP addresses: 142.93.149[.]77 and 104.248.126[.]159. Teams hunting across logs should search for both the header and the addresses rather than relying on a single signal.

The naming of the two files is worth noting for defenders: .vcnode.js sits in /usr/local/sbin with a dot prefix, and vc-sysmond mimics a system daemon name alongside a matching systemd service. Those choices are consistent with an attempt to blend into the host's normal file layout rather than stand out.

What to Preserve After a Suspected Hit

If any of the indicators turn up, Arista's instruction is to preserve the state of the VCO and contact TAC or your Arista account team. If a compromise is suspected, the advisory says to save the VCO's web access, backend application, system, and database logs and its file-system timestamps before fixing anything, where that is practical. Capturing evidence first keeps the option of a fuller investigation open.

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

The scope of that checklist reflects the orchestrator's role. A VCO holds the data it manages and reaches the Edges under its control, so an attacker who establishes a foothold there has more than one direction to move. The advisory's own framing — that a compromised VCO may give attackers access to the Edge devices it manages — is why it recommends checking Edge state as part of the response.

Why This One Matters for SD-WAN Teams

The practical problem for defenders is the split between trains. Teams on 5.2 or 6.4 can patch now; teams on 6.1 or 7.0 cannot, and must lean on access restrictions and monitoring until Arista ships fixes. The very fact that patched versions for the July flaw appear in the affected range for this one suggests that upgrading for an earlier bug does not clear the board for the next one.

The exposure condition also puts a configuration question in front of administrators. Certificate-based authentication is a common and generally preferable way to authenticate Edges, and Arista's description of the exposed state ties directly to it. That could mean some organizations find themselves exposed precisely because they adopted the stronger authentication mode. For anyone unsure which mode their deployment uses, confirming that should be the first step.

A CVSS score of 10.0 combined with active exploitation is a combination that warrants prioritizing the upgrade over routine maintenance work where a fixed release is available. For teams without one, the mitigations and the indicator list are the available levers until Arista publishes fixes for the remaining trains.