al-ice.ai

The Lowest Role in the Tenant Becomes Superuser: Arista Patches an Exploited VeloCloud SQL Injection

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Arista Networks published Security Advisory 0199 on 22 October 2026 (revision 1.0, same day) covering CVE-2026-114625, a SQL injection in on-prem VeloCloud Orchestrator — the central management plane for VeloCloud SD-WAN fabrics, the product line Arista acquired from Broadcom. The advisory carries two scores for one bug, CVSS v3.1 9.9 and CVSS v4.0 9.4, classifies it as CWE-89, tracks it internally as BUG2043622, and closes the description with the sentence that should reorder the week: “This issue was detected by Arista and is known to be actively exploited.”

The mechanics are worse than the score suggests, and the advisory is unusually candid about why.

Enterprise Read Only is enough

Arista's “Required Configuration for Exploitation” section states that VCO is exposed by default, that a successful attack needs network access to the VCO web interface plus a valid authenticated session on the portal, and that the minimum user role required is Enterprise Read Only — the lowest built-in tenant role. Then it adds the line that removes the usual escape hatch: “There is no configuration that can prevent the exposure.”

In the advisory's own words, “any authenticated user can gain operator privileges and masquerade as a local ‘superuser operator’ user,” reaching functionality “intended for internal use only and which is not intended to be remotely accessible.” Read that against how a VeloCloud Orchestrator is actually populated. Enterprise Read Only is the role an MSP hands to the customer who wants to watch their own tunnels, the role a NOC gives to tier-1, the role an auditor gets for a quarter. It is the account you create without a change ticket. On an unpatched VCO it is a path to the provider-level identity that administers every tenant on the box.

That is what the CVSS v3.1 vector is quietly recording. AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — low privileges required, and S:C, scope changed. Scope change in a multi-tenant orchestrator is not an abstraction: it is the security authority of tenant A being used to act as the authority over tenants B through Z. The v4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) says the same thing with subsequent-system impact set high across the board. The headline numbers differ — 9.9 against 9.4 — for the usual structural reason we keep running into in this autumn's advisories: the two scales weight privilege and scope differently. Neither is the interesting number. “Lowest role on the box becomes superuser, and exploitation is under way” is the interesting number.

Affected versions, and the hosted-versus-on-prem split

Per the advisory, the affected software is VCO 5.2.x prior to 5.2.3.18, VCO 6.1.x prior to 6.1.3.10, and VCO 6.4.x prior to 6.4.2.12. Those same three trains carry the fixes: 5.2.3.18, 6.1.3.10 and 6.4.2.12 and later. Arista notes that end-of-support versions have not been assessed — which, for a vulnerability already in use, should be read as unknown rather than safe.

Arista also states that hosted and Dedicated VCO instances were impacted and have already been patched. Only VeloCloud Orchestrator On-Prem remains exposed; VeloCloud Gateway and VeloCloud Edge are explicitly listed as unaffected, as are Arista's EOS platforms, CloudVision in all its delivery models, Wi-Fi access points, DANZ Monitoring Fabric, NDR, and the rest of the portfolio. The blast radius is narrow by product and deep by consequence — the classic shape of a management-plane bug.

The NVD record, which we read directly from the 2.0 API, was published 2026-10-22T21:17:16Z and last modified 2026-10-22T23:18:30Z, source psirt@arista.com, status Received — vendor-supplied data, no NVD analysis yet. The version ranges in the CVE record match the advisory exactly.

One inconsistency is worth flagging for anyone working from the text: the advisory's Mitigation section recommends upgrading “as soon as it is available,” while the Resolution section names three fixed builds. The fixed builds exist. Treat the Resolution section as authoritative.

Two IPs, and what they are and are not

Arista publishes two addresses “observed conducting the attacks” and advises blocking them and searching logs for them: 74.82.197.86 and 38.54.50.151. We did not resolve, probe or contact either address, and neither should you beyond log search. Two IPs from one vendor's incident visibility are a hunting lead, not a perimeter control — absence in your logs clears nothing.

The detection guidance is more durable than the indicators. Arista tells operators to review VCO web access logs for “unusual URL-like path components, encoded characters, references to local or internal services, or high request rates.” References to local or internal services in a request path is a notable tell: it points at the privileged internal functionality the advisory says the flaw reaches, which suggests the exploitation chain does not stop at reading the database. The hardening advice reinforces that reading — Arista asks operators to monitor for unexpected outbound network activity from the VCO host, to consider blocking outbound ports not needed for normal activity, and to monitor for backdoor daemons and webshells. Those are post-exploitation controls for host compromise, not for a data-read bug.

The advisory's forensics instruction deserves repeating verbatim in your runbook, because patching destroys evidence: if compromise is suspected, preserve VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps before remediation where operationally feasible.

The third one this year

We pulled the CISA KEV catalogue directly (version 2026.10.21, 1,754 entries). CVE-2026-114625 is not in it yet — the catalogue predates the advisory by a day. What is in it: CVE-2026-93952, Arista VeloCloud Orchestrator, added 22 September 2026, and CVE-2026-16812, Arista VeloCloud Orchestrator, added 27 July 2026. Plus CVE-2026-7473 in Arista EOS, added 9 June 2026.

That makes CVE-2026-114625, on Arista's own exploitation statement, the third VeloCloud Orchestrator flaw exploited in the wild inside four months. One exploited bug in a management plane is an incident. Three is a research programme — somebody is working this product deliberately, and the pattern says the next one is already in progress. If your VCO has been internet-reachable since July, the correct assumption today is not “patch and move on” but “patch, then go look,” against all three CVEs. That is the same discipline we argued for after Qilin and INC spent four months walking through a patched PAN-OS bypass: on an edge appliance, the patch closes the door and says nothing about who is already inside.

There is a second, quieter lesson in the credit line. Arista found this one itself, in a product it inherited through acquisition, and shipped the advisory with live-exploitation language and indicators attached on day one. Compare that with the vendor-scale-versus-CVSS gaps and the “fixed version: to be announced” tables we have catalogued all month. An advisory that names the minimum exploiting role, admits no configuration helps, publishes IOCs, and tells you to preserve logs before you patch is a good advisory. It is also an advisory written by people who have already seen what the attacker did.

What to do

  • Upgrade on-prem VCO to 5.2.3.18, 6.1.3.10 or 6.4.2.12 today. This is an exploited flaw in a management plane with no configuration workaround. It does not wait for a maintenance window. If you are on an unsupported train, Arista directs you to TAC for upgrade options — EOS versions were not assessed, so assume affected.
  • Preserve evidence before you patch. Snapshot web access logs, backend application logs, system logs, database logs and file-system timestamps. Patching an appliance frequently rotates or rebuilds exactly the artefacts an investigation needs.
  • Hunt back to July, not to Tuesday. Two earlier VCO CVEs are already in KEV with add-dates of 27 July and 22 September 2026. Scope the review to the full exposure window, and search access logs for URL-like path components, encoded characters and internal-service references, not only for the two published IPs.
  • Audit the low-privilege tenant accounts. Enterprise Read Only is the exploitation floor here. Enumerate every account at that tier across every tenant, remove the stale ones, and ask who issued the rest. A read-only account on a multi-tenant orchestrator is no longer a low-risk grant.
  • Put the orchestrator behind administrative network controls permanently. Arista's interim guidance — restrict web-interface access to trusted administrative networks, monitor for unexpected outbound traffic, block unnecessary outbound ports, watch for webshells and backdoor daemons — is good architecture after the patch too. A product with three exploited management-plane bugs in four months should not be reachable from the open internet by design.

This write-up is our analysis of Arista Security Advisory 0199 and the NVD 2.0 record for CVE-2026-114625, both read first-hand, plus the CISA KEV catalogue queried directly at version 2026.10.21. The exploitation claim, the attacking IP addresses and the detection guidance are Arista's statements, carried as vendor telemetry and not independently confirmed by us. We did not test the vulnerability, write or obtain a proof of concept, contact any VeloCloud deployment, or resolve or probe either published IP address. The reading that the post-exploitation guidance implies host compromise beyond database access is our inference from the advisory's own mitigation text, not an Arista statement.

Sources: