CRITICAL: Arista Fixes Third Exploited VeloCloud Orchestrator Zero-Day

If you manage SD-WAN for anyone and the words "VeloCloud Orchestrator" give you a slight eye twitch, I have bad news. The twitch is justified. Arista published Security Advisory 0199 on October 22, 2026 for CVE-2026-114625, a critical SQL injection flaw in on-premises VeloCloud Orchestrator (VCO) that attackers were exploiting before a patch existed. That makes three exploited VCO zero-days in roughly four months, which is a pace no orchestration platform should be proud of.

This one is a drop everything and patch it now situation. The orchestrator is the box that pushes configuration to every edge device in a customer's SD-WAN fabric, so whoever owns the orchestrator effectively owns the network. Arista found the exploitation itself and says plainly that the bug is "known to be actively exploited." The hosted and dedicated VCO platforms that Arista runs were patched before the advisory went public, so the burden falls on organizations and service providers running VCO on their own hardware.

What the Bug Actually Does

CVE-2026-114625 is classified as CWE-89, plain old SQL injection, carrying a CVSS 3.1 base score of 9.9 with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Under CVSS 4.0 it scores 9.4. Reading the vector tells you most of the story. It is reachable over the network, it is low complexity, it needs no user interaction, and the scope changes, meaning the damage escapes the vulnerable component and lands on the underlying VCO host.

The one thing keeping this from a perfect 10 is that the attacker needs a valid authenticated session. Before you exhale, look at how low that bar sits. The minimum role required is Enterprise Read Only, the most limited built-in tenant account the product offers. That is the account you hand to an auditor, a junior tech, a customer who wants to look at their own dashboards, or a third party monitoring integration. According to Arista, once an attacker is logged in at that level, the injection lets "any authenticated user gain operator privileges and masquerade as a local 'superuser operator' user." The advisory adds that the flaw "may allow a remote attacker to access privileged internal functionality and impact the VCO host," with confidentiality, integrity and availability of both the orchestrator and every piece of data it manages on the table.

So the real attack chain is short. Get any credential, whether phished, reused from an old breach, scraped from a script on a file share, or belonging to a tenant account nobody remembered to disable. Log in. Inject. Become the operator. From there, an attacker can read every tenant's configuration, change routing and security policy on edge devices, and reach the host itself. In a multi-tenant deployment, which is exactly how many MSPs and carriers run VCO, a read only login for one customer can become the keys to every customer on the box.

Arista also notes that VCO is exposed by default, and in the advisory's own words, "There is no configuration that can prevent the exposure." You cannot toggle your way out of this one. Patching is the fix.

Affected and Fixed Versions

Every supported on-premises VCO train is affected. The 5.2 branch is vulnerable before 5.2.3.18, the 6.1 branch before 6.1.3.10, and the 6.4 branch before 6.4.2.12 as well. Arista did not assess end of support releases, which is vendor speak for "if you are running something older, you are on your own and probably vulnerable." The fix is to move to 5.2.3.18 or later, 6.1.3.10 or later, or 6.4.2.12 or later depending on your train. VeloCloud Orchestrator Hosted and Dedicated customers were patched by Arista ahead of disclosure and do not need to act on the software itself, although they should still review account hygiene, since a compromised read only login remains a compromised login.

Exploitation in the Wild

Arista has not attributed the activity or said how many customers were hit, but it did publish two attacker IP addresses, 74.82.197.86 and 38.54.50.151, observed in the attacks. Those should go into your block lists and your log searches today. The advisory also describes what exploitation looks like in VCO web access logs. Watch for unusually high request rates from a single session, URL style path components that do not belong in normal traffic, encoded characters stuffed into parameters, and references to local or internal services. That last indicator matters. It suggests attackers are using the injected access to reach internal only endpoints that were never meant to be callable from outside, which lines up with the "privileged internal functionality" language in the advisory.

Arista's guidance also tells defenders to watch for backdoor daemons and webshells on the VCO host and for unexpected outbound connections. Vendors do not write that sentence unless they have seen post exploitation persistence, or at least expect it. If you patch a box that was already compromised, the patch closes the door but leaves the intruder sitting comfortably inside.

A Pattern Worth Paying Attention To

This is the part that should change how you think about VCO as a platform. In July, Arista patched CVE-2026-16812, an unauthenticated OS command injection in on-prem VCO rated a perfect 10.0, which CISA added to its Known Exploited Vulnerabilities catalog on July 27 with a three day remediation deadline. We covered that one here at the time. In September came CVE-2026-93952, an improper input validation flaw that CISA added to KEV on September 22, again with forensic triage requirements attached. Now we have CVE-2026-114625. As of this writing it has not yet landed in the KEV catalog, but given the vendor's own confirmation of exploitation, I would not expect that to last long.

Three exploited bugs in the same management plane in four months tells you that someone is deliberately working through this product. Attackers love orchestration and edge management platforms for the same reason we do. One login controls hundreds of sites. Steady discovery of new bugs in the same product usually means somebody has built a working understanding of its internals and has a reason to keep coming back. If you patched July and September and figured you were done, you were not. Treat VCO as a high value, actively hunted asset from here forward, with the monitoring and access controls that implies.

What to Do Right Now

Start by figuring out whether you have on-prem VCO anywhere, including in client environments you inherited, lab instances somebody stood up for a proof of concept, and disaster recovery copies. Then upgrade every instance to 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later for its train. If you cannot patch today, Arista's interim advice is to restrict the VCO web interface to trusted administrative networks only, block and alert on the two published IP addresses, restrict outbound traffic from the VCO host to only the ports it genuinely needs, and review recent administrator activity for changes nobody can explain.

Before you patch, think about evidence. If there is any chance an instance was already hit, Arista recommends preserving VCO web access logs, backend application logs, system logs, database logs and relevant file system timestamps before remediation where operationally feasible. Upgrading first and asking questions later is how you end up with a clean box and no idea what the attacker took or changed on your edges.

After patching, go hunting. Search web logs back at least to July for the two IPs and for the encoded, internal service flavored request patterns described above. Compare operator and superuser accounts against a known good list and look for logins by read only accounts that suddenly performed operator actions. Check the host for unfamiliar listening services, new cron jobs, and files dropped into web directories. Then review configuration changes pushed to edge devices, because an attacker who owned the orchestrator may have left routing, VPN or firewall changes that survive the patch.

Finally, fix the credential side of the equation, since this bug turns every low privilege account into a potential operator. Disable stale tenant users, rotate passwords on shared and integration accounts, enforce MFA everywhere VCO supports it, and stop exposing the orchestrator login page to the entire internet if your workflow does not truly require it. A management interface that only answers from a VPN or a jump host is one that random scanners never get to test.

The Bottom Line

CVE-2026-114625 is a 9.9 severity SQL injection that turns the weakest account in VeloCloud Orchestrator into a superuser, and it was being exploited before anyone outside Arista knew it existed. Coming on the heels of two other exploited VCO flaws since July, this is not a one off. Patch to the fixed builds, hunt for signs you were already visited, and start treating your SD-WAN orchestrator with the same paranoia you reserve for domain controllers and firewall management consoles. It has earned it.

The MSP Angle

Any client running SD-WAN, on VeloCloud or otherwise, now has a fair question about who is watching the management plane, and that opens the door to a quick edge and orchestrator exposure assessment followed by a managed patching and log monitoring agreement. MSPs that host multi-tenant VCO themselves should lead with transparency and a documented compromise review, because a well handled incident response is often what wins the renewal and the managed detection upsell.