Vulnerabilities

Arista published Security Advisory 0199 on October 22, 2026 for CVE-2026-114625, a SQL injection flaw in on-premises VeloCloud Orchestrator (VCO) that it says is "known to be actively exploited." It is rated CVSS 9.9 (version 3.1) and 9.4 (version 4.0). Any user who can log in to the VCO portal, down to the lowest built-in tenant role, Enterprise Read Only, can gain operator privileges and pose as the local "superuser operator" account.

This is the third exploited VCO zero-day since July, and it lands on systems many teams patched only a month ago for CVE-2026-93952. Those September builds are still vulnerable to this one. On the 5.2, 6.1 and 6.4 release trains you need 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later. Hosted and Dedicated VCO were also affected, and Arista says it has already patched them.

How it works

VCO is the management console for Arista's SD-WAN (software-defined wide area network) product, which links branch sites over ordinary internet circuits and is configured from one place. Its users come in two layers. Enterprise roles belong to the customer tenants that use the orchestrator, and Enterprise Read Only is the weakest of them: it can view a tenant's sites and settings and change nothing. Operator roles belong to whoever runs the orchestrator itself, and the superuser operator sits above every tenant on it.

SQL injection (CWE-89) means the application builds a database query from text the user sends without separating data from query code, so a crafted value changes what the query does. In this case Arista says the result is that an authenticated user gains operator privileges and can masquerade as the superuser operator, reaching "privileged internal functionality" and affecting the VCO host. The CVSS vector reflects that: network attack, low complexity, low privileges required, no user interaction, and a changed scope, meaning the damage reaches past the component that holds the bug.

Arista has not named the vulnerable endpoint or parameter. Its log guidance gives a hint: it asks defenders to look in VCO web access logs for URL-like path components, encoded characters, references to local or internal services, and high request rates. Our reading, which Arista has not confirmed, is that exploitation traffic carries injected strings that point the server at its own internal services, and that it is noisy enough to show up as bursts of requests.

Arista lists three conditions: network access to the VCO web interface, a valid authenticated portal session, and at least the Enterprise Read Only role. It also notes that VCO is exposed by default and that no configuration setting removes the exposure. Read-only accounts are often the ones handed out most freely: to managed service customers, auditors, monitoring tools and integrations. Each of those is now a path to operator.

How it relates to the earlier VCO flaws

CVE-2026-16812, published in late July, was an unauthenticated OS command injection rated CVSS 10.0. CVE-2026-93952, in September, was an unauthenticated input validation flaw, also CVSS 10.0, reachable only when Edges authenticate to VCO by certificate. CISA added each to its Known Exploited Vulnerabilities (KEV) catalog on the day Arista published, on July 27 and September 22. The new flaw differs from both: it needs a login, but it works in any configuration and starts from the weakest account the product offers.

Nothing in Arista's advisories says the three share a root cause or an attacker, so treat them as separate bugs in the same product. Two points matter for patching. First, the fixed builds from September (5.2.3.16 and 6.4.2.8) are below the new ones, so an orchestrator patched for CVE-2026-93952 is still exposed. Second, Advisory 0183 for the September flaw still lists no fix for the 6.1 and 7.0 trains, and Advisory 0199 does not say whether 6.1.3.10 also closes CVE-2026-93952. The 7.0 train is not on the affected list for the new flaw; Arista says it did not assess end-of-support releases.

What attackers are doing

Arista says it detected the issue itself and that it is being exploited, but it has not named an attacker, a start date or a number of victims. It has published two source IP addresses seen in the attacks, 74.82.197.86 and 38.54.50.151, and tells defenders to look for backdoor daemons and web shells (scripts planted on a web server to run commands later), which suggests that at least some intrusions went past the database and onto the host.

CISA's catalog update of October 21, the day before the advisory, did not include CVE-2026-114625, and we found no later addition at the time of writing.

What to do

1. Patch to a fixed build

Upgrade on-premises VCO to 5.2.3.18 or later on the 5.2 train, 6.1.3.10 or later on 6.1, or 6.4.2.12 or later on 6.4. Compare your running build with these numbers, not with what you installed in September. If you run a train that is out of support, Arista asks you to contact its Technical Assistance Center (TAC) for upgrade options. BleepingComputer's report ties these builds to hosted deployments, but Arista's advisory lists them as the on-premises fixes and says Hosted and Dedicated VCO were patched by Arista, so cloud customers have nothing to install.

2. If you cannot patch today

Limit the VCO web interface (HTTPS, TCP 443) to trusted administrative networks with a firewall or access list in front of the orchestrator. Arista also suggests blocking outbound ports the VCO host does not need, which makes a planted backdoor harder to reach or use. Then cut the number of logins that can reach the bug: disable Enterprise Read Only and other tenant accounts nobody uses, and reset passwords on shared ones. Every user who can still reach the interface can still exploit the flaw, so treat this as a stopgap until the upgrade.

3. Check whether you were hit

• Search VCO web access logs and perimeter firewall logs for 74.82.197.86 and 38.54.50.151.
• In the same web logs, look for requests carrying encoded characters, URL-like strings in the path, or names of local services such as localhost or 127.0.0.1, and for short bursts of high request rates from one session.
• Review recent operator and enterprise administrator activity in the VCO event and audit logs for changes nobody on your team made, especially new operator users and configuration pushed to Edges.
• On the VCO host, look for unknown daemons, services and web shells, and check firewall logs for unexpected outbound connections from the orchestrator.

If anything looks wrong, preserve web access logs, backend application logs, system logs, database logs and file-system timestamps before you patch, as Arista recommends, because the upgrade can overwrite them. The indicators for the September flaw are in our CVE-2026-93952 post and are worth running in the same pass.

4. If you find signs of compromise

Arista's advisory points to TAC for incident help. Our advice is to rebuild the orchestrator on a fixed build instead of patching in place, since an attacker with operator rights and host access can leave persistence behind. Then reset every operator and enterprise password, revoke API tokens, and rotate credentials and certificates the orchestrator holds for Edges and Gateways.

The wider lesson

VCO has now had three exploited bugs in four months, two of them reachable without a login. An orchestrator that controls every branch should sit on a management network with its own login controls, and the accounts on it should be reviewed like domain admin accounts, read-only ones included.

Our attack surface management work tracks which management consoles like VCO are reachable from the internet, and our security operations team can run the log and host checks above with you. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Arista Security Advisory 0199, BleepingComputer, Strix CVE record, DEV Community analysis, OffSeq Threat Radar, Arista Security Advisory 0183, CISA KEV catalog, Security Affairs on CVE-2026-16812, Gridinsoft on CVE-2026-16812.