The disclosure of CVE-2026-93952, a critical vulnerability affecting on-premises VeloCloud Orchestrator deployments, deserves immediate attention from organizations using VeloCloud SD-WAN infrastructure.

The vulnerability carries a CVSS v3.1 score of 10.0, the maximum possible severity rating, and has already been observed under active exploitation.

According to Arista, which now maintains VeloCloud following its acquisition of the business, successful exploitation could allow a remote attacker to access privileged internal functionality and affect the VeloCloud Orchestrator host.

The consequences could include compromise of the confidentiality, integrity, and availability of both the Orchestrator and the data it manages.

This is especially significant because VeloCloud Orchestrator is not an ordinary application server. It acts as the central management platform for SD-WAN infrastructure and can control configuration and operational functions across multiple VeloCloud Edge devices.

What makes CVE-2026-93952 particularly dangerous?

The CVSS v3.1 vector for the vulnerability is:

AV:N / AC:L / PR:N / UI:N / S:C / C:H / I:H / A:H

In practical terms, this indicates:

  • the vulnerability is reachable over a network;
  • attack complexity is considered low;
  • VCO credentials are not required;
  • no victim interaction is required; and
  • successful exploitation could have a high impact on confidentiality, integrity, and availability.

That combination alone would justify urgent remediation.

The fact that exploitation has already been observed makes the situation substantially more serious.

Certificate-based authentication is the key exposure condition

There is an important qualification organizations should understand.

The vulnerability does not affect every VeloCloud deployment automatically.

According to Arista, a VCO is exposed when certificate-based authentication between the VeloCloud Edge and VeloCloud Orchestrator is configured.

The attacker also requires:

  • access to the public portion of the VeloCloud Edge authentication certificate; and
  • network access to the VCO web interface.

However, VCO tenant or operator credentials are not required.

This distinction is important.

Organizations should not simply search for VeloCloud Orchestrator in their asset inventory and conclude that every instance is exploitable. They should determine whether certificate-based Edge-to-Orchestrator authentication is enabled and whether the VCO web interface is reachable from networks that should not have access to it.

Why compromising an SD-WAN Orchestrator is so serious

A centralized SD-WAN controller represents an unusually valuable target.

The Orchestrator maintains information about managed devices, configurations, networks, administrators, certificates, and potentially other operational data necessary to control the SD-WAN environment.

If attackers gain privileged access to this management layer, the security consequences can extend beyond the server running VCO.

Arista explicitly warns that compromise of the VCO platform may allow attackers to gain access to VeloCloud Edge devices as well.

That creates the possibility of an attack moving from the management plane toward the broader network infrastructure.

Depending on the level of access achieved, a compromised orchestration platform could potentially provide opportunities to:

  • access sensitive SD-WAN configuration information;
  • manipulate network or device configuration;
  • obtain credentials, certificates, or key material;
  • interact with managed Edge devices;
  • modify administrative settings;
  • establish persistence on the Orchestrator;
  • extract databases or configuration archives; or
  • use the compromised management platform as a launching point for further intrusion.

Not every one of these outcomes has necessarily been demonstrated in every observed attack, but they illustrate why compromise of a centralized network-management platform has much wider implications than compromise of an isolated endpoint.

Arista has published concrete indicators of compromise

Another notable aspect of this disclosure is that Arista has provided several indicators organizations can immediately investigate.

Administrators should look for suspicious files including:

/usr/local/sbin/.vcnode.js

/usr/local/sbin/vc-sysmond

/etc/systemd/system/vc-sysmon.service

Arista also published an MD5 hash associated with a malicious vc-sysmond file:

dc78e206eaeadec59fc5801fe4556bd0

Organizations should additionally search nginx logs for the unusual HTTP header:

x-vc-opt

Arista has identified connections involving the following IP addresses for investigation:

142.93.149.77

104.248.126.159

These indicators should not be treated as the complete detection set. Attackers can change filenames, infrastructure, hashes, and headers once indicators become public.

Security teams should therefore combine IOC-based detection with behavioral analysis.

Behaviour that deserves investigation

Arista recommends reviewing VCO web access logs for unexpected requests, particularly requests containing:

  • unusual URL-like path elements;
  • encoded characters;
  • references to local or internal services; and
  • unusually high request rates.

Organizations should correlate this activity with VCO backend application logs and system logs.

Particular attention should be paid to:

  • unexpected outbound HTTP or HTTPS traffic originating from the VCO;
  • unexplained configuration changes;
  • privileged maintenance actions with no corresponding administrator activity;
  • unexpected command execution;
  • newly created files;
  • database exports or archive files; and
  • suspicious access to credentials, certificates, configuration data, device inventory, or key material.

This is important because successful exploitation may not necessarily produce an obvious service failure.

A compromised Orchestrator can continue functioning normally while an attacker quietly establishes persistence or extracts information.

Affected versions

Arista currently identifies the following as affected:

  • VCO 5.2.3.15 and earlier in the 5.2.x train
  • VCO 6.1.3.7 and earlier in the 6.1.x train
  • VCO 6.4.2.7 and earlier in the 6.4.x train
  • VCO 7.0.0.2 and earlier in the 7.0.x train

Hosted and Dedicated VCO deployments were also affected, but Arista states that those environments have already been patched.

The immediate concern therefore falls particularly on organizations operating self-managed, on-premises VCO installations.

Patch availability is currently uneven

As of September 22, 2026, Arista has released fixes for:

  • VCO 5.2.3.16 and later
  • VCO 6.4.2.8 and later

Fixed releases for other supported branches are still being added.

Organizations operating affected 6.1.x or 7.0.x environments therefore need to monitor Arista's advisory closely and apply the vendor's recommended interim protections until an appropriate fixed release becomes available.

This is one of those uncomfortable situations in vulnerability management where the risk is already active while not every software branch has a final patch. Cybercriminals, displaying their traditional disregard for enterprise change-control calendars, rarely wait for maintenance windows.

What should organizations do immediately?

The first step should be to determine whether an affected VCO release is deployed and whether certificate-based Edge authentication is enabled.

Organizations should then:

Restrict the VCO web interface

Access should be limited to trusted administrative networks and systems wherever possible.

The VCO management interface should not be unnecessarily exposed to the public Internet or broadly accessible from internal user networks.

Install available fixed releases immediately

Organizations running supported branches for which fixes are available should prioritize upgrading.

Monitor outbound traffic from the Orchestrator

Unexpected HTTP or HTTPS connections initiated by the VCO should be investigated.

Organizations should also consider restricting outbound ports that are not required for normal VCO operation.

Search for known indicators of compromise

The files, HTTP header, IP addresses, and hash published by Arista provide an immediate starting point for threat hunting.

Look beyond published IOCs

Security teams should investigate unusual processes, persistence mechanisms, outbound connections, filesystem activity, privileged operations, and unexpected administrator actions.

Preserve forensic evidence if compromise is suspected

Arista specifically recommends preserving web access logs, backend application logs, system logs, database logs, and relevant filesystem timestamps before remediation where operationally possible.

This is important because immediately rebuilding an affected appliance may remove precisely the evidence needed to determine what the attacker accessed.

Patching alone may not be sufficient

Perhaps the most important operational point in this advisory is that installing the fixed software should not automatically be considered the end of the incident.

If an attacker exploited the vulnerability before the upgrade, the environment may already contain persistence mechanisms or compromised credentials.

Arista recommends post-remediation actions including:

  • credential rotation;
  • review of administrator activity;
  • validation of managed Edge device state; and
  • restoring or replacing compromised Orchestrator instances from trusted sources where necessary.

Certificates and other key material should also receive particular attention if evidence suggests the VCO host was compromised.

A patch removes the vulnerability.

It does not necessarily remove the attacker.

This is also not VeloCloud's first critical exploitation issue this year

The latest vulnerability follows CVE-2026-16812, another CVSS 10.0 VeloCloud Orchestrator vulnerability disclosed in July 2026 that Arista also said was being actively exploited.

That earlier issue involved remote access to privileged internal functionality and arbitrary command execution.

The appearance of another actively exploited critical vulnerability affecting the same centralized management platform should encourage VeloCloud operators to reassess not only patching but also the architecture surrounding management access.

VCO management interfaces should be treated as highly sensitive infrastructure and isolated accordingly.

The broader cybersecurity lesson

CVE-2026-93952 illustrates why attackers increasingly focus on management infrastructure rather than attacking individual endpoints one at a time.

Compromising an ordinary workstation may provide access to one employee.

Compromising a centralized network-management system may provide visibility and influence over an entire distributed infrastructure.

SD-WAN orchestrators, firewall managers, virtualization consoles, backup platforms, monitoring systems, and remote-management tools therefore represent high-value attack surfaces.

They should receive security controls proportionate to that role:

restricted management access, strong network segmentation, rapid patching, continuous monitoring, outbound traffic controls, centralized logging, and incident-response preparation.

The combination in CVE-2026-93952 is difficult to ignore:

CVSS 10.0 + no VCO credentials required + low attack complexity + centralized SD-WAN management access + confirmed exploitation in the wild.

For affected organizations, this should be treated as an incident-response priority rather than simply another entry in the vulnerability-management queue.

When attackers compromise the platform responsible for managing the network, the question is no longer only whether the management server is affected. The security state of every device it controls may also need to be questioned.

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

Source: New CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited in Certificate-Based Setups via The Hacker News — published 22 Sep 2026.