Logged-In Users Can Seize Control of Arista VeloCloud Orchestrator Through Exploited SQL Flaw

Arista Networks has released fixes for a critical, actively exploited zero-day flaw in VeloCloud Orchestrator (VCO). VCO is the central management system for VeloCloud SD-WAN networks. The company disclosed the flaw in an advisory dated October 22. It is tracked as CVE-2026-114625 and is a SQL injection bug. Anyone who can log in to an orchestrator, even with the most limited customer account, can use it to gain operator privileges, the highest level of control in the system. A zero-day is a flaw that attackers exploit before a fix is available. This is the third VCO flaw since late July that Arista has reported as exploited in real attacks.

What happened

According to Arista's advisory, as reported by The Hacker News and BleepingComputer, attackers have been exploiting a previously unknown weakness in the orchestrator's web interface. Arista has already patched its Hosted and Dedicated orchestrators, which the company runs for customers. Organisations that run VCO on their own infrastructure, known as on-premises or "On-Prem" deployments, have to install the update themselves.

Arista has seen two IP addresses carrying out the attacks: 74[.]82.197.86 and 38[.]54.50.151. The brackets are added so the addresses cannot be clicked by accident. The company advises customers to block both addresses and to search their logs for any sign of them.

The flaw follows two earlier exploited VCO bugs: CVE-2026-16812 in July and CVE-2026-93952 in September. BleepingComputer notes that Arista has also patched a fourth exploited zero-day this year, CVE-2026-7473 in May. That flaw affected the company's Extensible Operating System (EOS) rather than VCO.

Arista took over the VeloCloud SD-WAN product line from Broadcom, announcing the deal in July 2025. The products were previously sold as VMware SD-WAN by VeloCloud.

Who is affected

The flaw affects on-premises VeloCloud Orchestrator deployments. The fixed releases for each supported release train are:

• 5.2 train: VCO 5.2.3.18
• 6.1 train: VCO 6.1.3.10
• 6.4 train: VCO 6.4.2.12

Applying the earlier fixes does not protect against this flaw. Orchestrators running the releases that fixed the July and September bugs are still vulnerable, because those releases are older than the new ones.

Arista says VeloCloud Gateway and VeloCloud Edge devices are not affected. The 7.0 release train does not appear on the affected list, and the company says any release not on the list is not vulnerable. Arista has not checked releases that have reached end of support. Customers on those trains are asked to contact Arista's Technical Assistance Center (TAC) about upgrade options.

Customers on the 6.1 train face an added complication. As of October 22, the September flaw has fixes only for the 5.2 and 6.4 trains. On 6.1 it affects releases up to 6.1.3.7, and no fixed release is listed. Neither advisory says whether the new 6.1.3.10 release also closes the September hole.

The two outlets describe the patch status a little differently. The Hacker News says the listed versions are the fixes for on-premises orchestrators and that hosted ones are already patched. BleepingComputer's wording links those same version numbers to hosted deployments. Admins should treat the version numbers above as the targets for on-premises upgrades.

How it works

VCO is a web portal used to configure, monitor and manage SD-WANs (software-defined wide area networks) and the edge devices connected to them. An SD-WAN links an organisation's branch offices and data centres, and software controls how traffic moves between them. Accounts in VCO are layered. Operators sit at the top and create partner and customer accounts. Partners can manage groups of customers, and customers have their own users with different roles.

SQL injection is a long-known class of bug. It happens when an application lets user-supplied input change the database commands it runs. Here, the result is privilege escalation, meaning a low-level user gains powers they should not have. The minimum role an attacker needs is Enterprise Read Only, the weakest built-in customer role. Arista said that on an affected system, "any authenticated user can gain operator privileges." The attacker can then pose as a local "superuser operator" with full access. That includes internal functions that were never meant to be reachable over the network.

BleepingComputer reports that the attack is low in complexity and needs no action from a victim. Arista also warns that it may let an attacker affect the VCO host machine itself. That could expose, alter or disrupt both the orchestrator and the data it manages.

To use the flaw, an attacker needs two things: network access to the orchestrator's web interface and a valid login. According to The Hacker News, VCO is exposed by default, and no VCO setting prevents that exposure.

How serious is it?

The flaw is rated 9.9 out of 10 on the CVSS severity scale, according to The Hacker News. BleepingComputer describes it as critical. Both outlets agree it is being exploited in the wild.

The login requirement makes it slightly different from the earlier VCO bugs. Neither the July nor the September flaw required credentials, so this is the first of the three that does. That should not be much comfort. Read-only customer accounts tend to be common and are often loosely protected. An attacker might obtain one through phishing, password reuse or an earlier breach.

Arista's earlier advisories warned that a compromised orchestrator could also give attackers access to VeloCloud Edge devices. The new advisory does not say whether the same risk applies this time.

What to do now

For VCO administrators:

• Upgrade on-premises orchestrators to 5.2.3.18, 6.1.3.10 or 6.4.2.12, depending on your release train.
• If you run an end-of-support release, contact Arista TAC about upgrade paths.
• Restrict access to the VCO web interface to trusted administrative networks only.
• Block 74[.]82.197.86 and 38[.]54.50.151, and search your logs for past connections from them.
• Monitor for connections from other known malicious IP addresses.
• Look for unexpected outbound traffic from the VCO host. Consider blocking outbound ports that normal operation does not need.
• Check for backdoor processes and webshells, which are hidden programs attackers leave behind to keep access.
• Review recent administrator activity for unexpected changes.
• Inspect web access logs for requests with unusual URL-like path components, encoded characters, references to local or internal services, or high request rates.
• If you suspect a compromise, preserve evidence before fixing anything where you can. That means web access, backend application, system and database logs, plus relevant file-system timestamps.
• Audit customer and partner accounts, including read-only ones, and remove any that are not needed.

For everyday users:

• You cannot patch this yourself. It is a back-end management system run by IT teams and service providers.
• If you hold a VCO customer login, use a strong, unique password and report any account activity you do not recognise.

What we still don't know

• When the attacks began and how many orchestrators were hit.
• What attackers did after gaining operator access.
• Whether a compromised orchestrator exposed connected Edge devices in this case.
• Whether upgrading removes access an attacker has already gained.
• Whether 6.1.3.10 also fixes the September flaw on the 6.1 train.
• Who is behind the attacks, and whether they are connected to the earlier VCO campaigns.

ITVedas analysis: Three exploited VCO flaws in about three months point to attackers who are deliberately targeting SD-WAN management systems. Patching alone is not enough here. Keeping orchestrators off the open internet and checking them for signs of earlier compromise should be standard practice for any team running them.