CVE-2026-114625

What is Arista VeloCloud Orchestrator?

VeloCloud Orchestrator (VCO) is the management plane of the VeloCloud SD-WAN platform, the product line Arista announced it was acquiring from Broadcom in July 2025 after VMware had owned it. VCO is where an operator defines business policy, pushes configuration to VeloCloud Edge appliances in branch offices and data centres, provisions new sites, issues activation keys, and reads the telemetry that the whole fabric reports back. It is multi-tenant: a service provider runs one orchestrator and carves it into enterprise tenants, each with its own set of roles.

That makes it an unusually valuable target. An orchestrator does not just hold configuration, it holds the trust relationship with every Edge device it manages, so control of VCO is a path to control of the WAN itself. Arista ships three delivery models: Hosted and Dedicated instances that Arista runs, and On-Prem instances that the customer runs. Only the On-Prem product is the customer's problem here. One further property matters: Arista states plainly that the VCO web interface is exposed by default and that no configuration setting prevents that exposure.

Overview

CVE-2026-114625 is a SQL injection flaw in the VeloCloud Orchestrator web interface. An attacker who can reach that interface and holds any valid authenticated session can reach functionality the product intends to be internal only, and from there obtain operator privileges and act as the local "superuser operator" account. The practical effect is a complete break of the tenant boundary and of the role model inside it.

The authentication requirement sounds like a meaningful barrier until you see how low the bar is. The minimum role that works is Enterprise Read Only, the least privileged built-in tenant role, the one handed out to auditors, NOC viewers, and read-only integrations. Arista scores it CVSS v3.1 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) and CVSS v4.0 9.4, with scope marked Changed precisely because the compromise does not stay inside the tenant that the attacker logged into.

Arista published Security Advisory 0199 on 2026-10-22, tracked internally as BUG2043622, and stated in the same breath that the issue was detected by Arista and is known to be actively exploited. There was no patch-then-exploit gap: this was disclosed as an in-the-wild zero day. Arista had already patched the Hosted and Dedicated orchestrators it operates. CISA added the CVE to KEV the following day with an unusually short deadline of 2026-10-26.

Affected Versions

End-of-support release trains were not assessed; Arista directs those customers to TAC for an upgrade path. Note the trap for anyone who patched recently: the builds that fixed the July and September VCO vulnerabilities are still vulnerable to this one.

Technical Details

The weakness is CWE-89, SQL injection. In plain words, the application builds a database query by pasting attacker-controlled text into it instead of passing that text as a bound parameter, so input that contains SQL syntax is executed as SQL rather than treated as data. Arista has not published the vulnerable parameter, endpoint, or code path, and no public proof of concept describes it, so the exploitation mechanics below are the shape of the bug rather than its internals.

What Arista does describe is the consequence, and it is the interesting part. The injection does not merely read the database; it crosses a privilege boundary. The attacker uses it to reach internal-only functionality on the VCO host and to assume the identity of a local superuser operator, which is the provider-side administrative role sitting above all tenants. That suggests the injected query touches data the authentication or session layer later trusts, rather than being a pure data-exfiltration primitive.

Attack characteristics: network reachable, low complexity, no user interaction, and low privileges required, but privileges are required. A valid login is the only precondition beyond reachability, which in a multi-tenant service provider deployment means any one of potentially hundreds of legitimate tenant accounts, any stolen credential, and any account left behind after an offboarding.

Discovery

Arista detected the vulnerability itself, and the advisory credits no external researcher or reporting organisation. The wording of SA-0199, that the issue "was detected by Arista and is known to be actively exploited," reads as discovery through incident response on live exploitation rather than through internal code review or a bug bounty submission. Arista has not published a timeline for when the first malicious requests were seen or how long exploitation ran before the advisory.

Exploitation Context

Exploitation is confirmed by the vendor. Arista names two attacker IP addresses, 74.82.197.86 and 38.54.50.151, as sources of the attacks and tells customers to block them and search historical logs for them. No threat actor, group name, or nation-state attribution has been published, and there is no reported ransomware use. Arista has not published victim counts, and neither Shadowserver nor Censys has released an exposure figure; the only public number circulating is a ZoomEye count of roughly 520 to 529 internet-facing assets matching the VeloCloud web fingerprint on 2026-10-22, which measures visible interfaces and not vulnerable orchestrators.

The sharper context is the pattern. This is the third VeloCloud Orchestrator flaw Arista has reported as exploited in three months: CVE-2026-16812, an OS command injection added to KEV in July 2026, and CVE-2026-93952, an input validation flaw added in September 2026, both of which were unauthenticated. CVE-2026-114625 is the first of the three to need a login, which plausibly means an attacker already holding credentials harvested during the earlier rounds. Arista warned with the earlier two that a compromised orchestrator could in turn grant access to the VeloCloud Edge devices it manages; the current advisory does not repeat that claim, but the architecture has not changed. Arista's post-compromise guidance, telling customers to hunt for backdoor daemons and webshells on the VCO host, indicates what the vendor has actually found on victim systems.

Remediation

1. Upgrade VeloCloud Orchestrator On-Prem to 5.2.3.18, 6.1.3.10, or 6.4.2.12, matching your current release train. Hosted and Dedicated instances need no customer action. Do not assume a recent patch covers this: the fixes for the July and September KEV entries do not.
2. If you run an end-of-support train, contact Arista TAC. Those releases were not assessed and no fix exists for them.
3. Until patched, restrict the VCO web interface to trusted administrative networks with a firewall or ACL. Arista states there is no product setting that removes the default exposure, so the control has to live in the network.
4. Block 74.82.197.86 and 38.54.50.151 at the perimeter and search web access, proxy, firewall, and DNS logs retrospectively for both.
5. Review VCO web access logs for unusual URL-like path components, encoded characters, references to local or internal services, and abnormally high request rates, which is the pattern Arista published for hunting this injection.
6. Block outbound ports the orchestrator does not need and alert on unexpected egress from the VCO host.
7. Hunt the host for backdoor daemons and webshells, and review recent administrator activity, new or modified operator accounts, and configuration changes for anything unaccounted for.
8. If compromise is suspected, preserve web access, backend application, system, and database logs plus file-system timestamps before remediating, then treat every credential and Edge activation key handled by that orchestrator as exposed.
9. Audit tenant accounts and retire dormant or unnecessary read-only logins. Enterprise Read Only is enough to exploit this, so the usual reasoning that a viewer account is low risk does not hold.
10. Federal civilian agencies must remediate by 2026-10-26 under BOD 22-01.