CVE-2026-93952: VeloCloud VCO Fixes 5.2/6.4, 6.1/7.0 Await

Arista's CVE-2026-93952 Puts On-Prem VeloCloud Orchestrator at Maximum Severity​

Arista's Security Advisory 0183 says the VCO on-prem flaw may allow a remote attacker to access privileged internal functionality and impact the VCO host, and that successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator. The advisory scores it CVSSv3.1 Base Score: 10.0, 9.5 under CVSS 4.0, and classifies it as CWE-20, improper input validation. Arista tracks the fix internally as BUG1907167 and BUG1937417.

According to Arista, this issue was discovered externally and is known to be actively exploited. Arista does not attribute the attacks to anyone, and it has not said how many customers were hit. The Canadian Centre for Cyber Security published its own notice listing the same affected product and version ranges, and it says open-source reporting indicates that CVE-2026-93952 is being exploited in the wild. SecurityWeek and The Hacker News reported the same disclosure separately.

For readers who don't run SD-WAN, some background. SecurityWeek describes VCO as a centralized management tool for configuring, monitoring, and orchestrating edge devices, policies, and traffic in Arista VeloCloud SD-WAN. Arista took over the VeloCloud line from Broadcom, which is why some older documentation still says Broadcom. Branch offices, retail sites and remote facilities often connect through VeloCloud Edge appliances, and the orchestrator is where their policies are set. Anyone who controls the orchestrator can potentially reach every edge it manages. The Hacker News makes that point, noting that a compromised VCO may also give attackers access to the Edge devices it manages.

The flaw is limited to on-premises VCO. Rescana's summary of the advisory notes that Arista explicitly lists VeloCloud Gateway; VeloCloud Edge; Arista EOS-based switching/routing platforms; CloudVision family; Wi-Fi APs among the products that are not affected. Arista also says that hosted, including Dedicated, versions of VCO were impacted and have already been patched. BleepingComputer's first report said Arista "patched hosted deployments running VCO 5.2.3.16 or later and VCO 6.4.2.8 or later." That mixes up two separate statements. Hosted and Dedicated VCO customers have already been patched by Arista. The 5.2.3.16 and 6.4.2.8 builds are the fixed releases for on-prem operators to install.

Certificate-Based Edge Authentication Opens the Door to CVE-2026-93952​

Not every on-prem VCO is exposed, and the conditions narrow the risk more than the "unauthenticated CVSS 10" label implies. Arista says VCO is exposed if certificate based authentication from the VeloCloud Edge to VeloCloud Orchestrator (VCO) is configured. It adds: Access to the public portion of the VeloCloud Edge authentication certificate is required. A successful attack requires network access to the VCO web interface. VCO tenant or operator credentials are not required for this exposure.

Put together, an attacker needs three things: an orchestrator that uses certificate-based edge authentication, a network path to its web interface, and the public half of an edge's certificate. No VCO username or password is needed. A certificate's public portion is not secret by design, so it offers little protection. Reachability is what operators can actually control.

There is some uncertainty about which configurations count. The Hacker News explains that 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. It also notes that Arista did not say which of those modes meets that condition. Other writeups, including a Metasploit tracking issue on GitHub, say both Certificate Acquire and Certificate Required are affected and PSK is not. That reading is reasonable, but Arista has not confirmed it. Operators using either certificate mode should assume they are exposed, and PSK-only operators should still apply the upgrade.

The two CVSS vectors in the advisory differ in one way. The 3.1 vector rates attack complexity as low, but the 4.0 vector is AV:N/AC:H/AT:N/PR:N/UI:N, meaning high attack complexity. Our inference: the 4.0 score probably reflects the certificate and reachability prerequisites. It makes no difference to the urgency, since Arista has confirmed attacks are already happening.

July's CVE-2026-16812 Patch Does Not Cover This Flaw​

This part affects operators who think they are already up to date. The Hacker News reports that the affected releases include those that fixed a different VCO flaw, which Arista reported as exploited in July. The July bug, CVE-2026-16812, is described in the Metasploit tracking issue as an unauthenticated OS command injection, also 10.0, also exploited in the wild. If you patched VCO for that flaw and stopped there, you are probably running a build that is vulnerable to CVE-2026-93952.

Here is the affected and fixed status per release train, based on Arista's advisory as of its initial September 22 release:

The ranges match those affected from 5.2.0 through 5.2.3.15; 6.1.0 through 6.1.3.7; 6.4.0 through 6.4.2.7; 7.0.0 through 7.0.0.2 in the CVE record, and The Hacker News confirms that 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 says it will add fixes for the other trains to the advisory as they become available. Customers on unsupported release trains should contact Arista's Technical Assistance Center (TAC) about upgrade options.

Arista also tells operators to first check their software versions against the "Affected Software" list. The build number is what counts, not the hardware or VM the orchestrator runs on. A 6.4 fix does not apply to a 6.1 install. Staying on 6.1 or 7.0 without a fix is not a safe option either, which brings in the interim measures below.

Arista's VCO Compromise Indicators Point to a Persistent Backdoor​

Arista is upfront that detection is imperfect: there is no single definitive indicator of compromise for this issue. It recommends correlating the VCO web access logs with backend application and system logs instead of relying on one signature. In the web logs, look for requests with encoded characters, unusual URL-like path components, references to local or internal services, and unusually high request rates. Unexpected outbound HTTP or HTTPS traffic from the VCO host also deserves a closer look.

The advisory lists specific artifacts to check:

• The files /usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond should not be present on a clean orchestrator.
• A systemd unit at /etc/systemd/system/vc-sysmon.service is an indicator.
• The MD5 hash dc78e206eaeadec59fc5801fe4556bd0 is associated with the vc-sysmond binary.
• nginx access logs should be searched for the x-vc-opt HTTP header.
• Connections to or from 142.93.149.77 and 104.248.126.159 should be blocked and investigated.

Our inference: a hidden JavaScript file, a daemon named to look like a system monitor, and a systemd unit that restarts it at boot are classic persistence. The advisory also tells operators to watch for backdoor daemons and webshells. So upgrading VCO closes the hole, but it may not remove an intruder who got in first. Arista's remediation guidance accounts for this. If compromise is suspected, BleepingComputer quotes Arista as saying operators should preserve VCO web access logs, backend application logs, system logs, database logs, and relevant file-system timestamps before remediation where operationally feasible, and then contact TAC or their account team.

After remediation, Arista's suggested response steps include rotating credentials, reviewing administrator activity, checking the state of managed edge devices, and restoring or replacing affected orchestrator instances from trusted sources. Check the edges too. A VCO holds device inventory, configuration, certificates and key material, and the advisory specifically flags unexpected access to those, along with unexpected database exports or archive files.

Missing indicators do not mean a clean system. The file paths and IP addresses are what Arista has seen so far. A different operator could rename a file or switch servers, which is why Arista puts behavioral log review ahead of any single IOC.

CISA's KEV Listing Gives Federal VCO Operators Until Friday​

CISA added CVE-2026-93952 to its Known Exploited Vulnerabilities catalog on September 22, according to the Canadian Centre for Cyber Security's notice, and several security outlets have repeated the listing. BleepingComputer reports that CISA ordered U.S. federal civilian executive branch agencies to secure affected systems by Friday, September 25. That three-day window is short even by KEV standards. The deadline has not appeared in the other reporting reviewed for this piece, so agencies should confirm it in the KEV entry itself.

KEV deadlines legally bind only federal civilian agencies, but many private-sector patch programs use the catalog to prioritize. A three-day deadline tells other organizations how CISA rates the risk. A VCO sitting in a corporate data center with its web interface reachable from the internet is exactly what the interim advice targets.

Arista's interim measures for systems that can't be patched yet are listed below. The company presents them as ways to reduce exposure and improve detection, not as a replacement for a fixed build:

1. Restrict access to the VCO web interface to trusted administrative networks. Arista says deployments that do this can reduce risk of exposure.
2. Block and monitor connections involving the two listed IP addresses.
3. Watch for unexpected outbound traffic from the VCO host, and consider blocking outbound ports it doesn't need.
4. Look for backdoor daemons and webshells, including the specific file and service artifacts above.
5. Review recent administrator activity and sensitive configuration changes for anything outside normal workflows.

There's a catch with step 1. Edges need to reach the orchestrator, so the web interface can't always be closed off completely. Arista hasn't published guidance on separating edge traffic from administrative access, so network teams will have to work out what they can restrict in their own design. TAC is the right place to ask if that isn't clear.

What this means for you​

If you run on-prem VeloCloud Orchestrator, check your exact build today and treat the result as deciding your next steps. On 5.2 or 6.4, upgrade to 5.2.3.16 or 6.4.2.8 or later. On 6.1 or 7.0, restrict access, hunt for the indicators, and watch the advisory for your train's fix. If you're on hosted or Dedicated VCO, Arista says you're already patched, though reviewing your admin activity logs is still worthwhile. Organizations that don't run VeloCloud can skip this one.

• On-prem VCO builds through 5.2.3.15, 6.1.3.7, 6.4.2.7 and 7.0.0.2 are affected, including builds that fixed the July CVE-2026-16812 flaw.
• Fixed releases were available only for the 5.2 (5.2.3.16) and 6.4 (6.4.2.8) trains as of September 22. The 6.1 and 7.0 trains are still waiting.
• The exposure requires certificate-based edge-to-VCO authentication plus network access to the web interface. No VCO credentials are needed.
• Before upgrading, check for /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond, the vc-sysmon.service unit, and x-vc-opt headers in nginx logs, because patching won't remove an implant that's already there.
• If you find anything suspicious, preserve web, application, system and database logs and filesystem timestamps before remediating, then contact Arista TAC.
• After a confirmed compromise, rotate credentials and check the state of every managed VeloCloud Edge, not just the orchestrator.

Two critical, actively exploited VCO flaws in three months, with July's fixed builds vulnerable to the second, show that on-prem SD-WAN orchestrators are now a regular target, and they should be patched as quickly as VPN gateways and firewalls. The next milestone is Arista updating Security Advisory 0183 with fixed builds for the 6.1 and 7.0 trains. Until then, operators on those trains are relying on restricted access and log review.