VeloCloud Orchestrator Grants Operator Rights From a Read-Only Login

TL;DR

• VeloCloud Orchestrator is the management platform that configures and monitors a VeloCloud SD-WAN network, and organisations that run their own copy host it on-premises as a web application.
• Arista published Security Advisory 0199 on 22 October 2026 for CVE-2026-114625, an SQL injection rated 9.9 under CVSS 3.1 and 9.4 under CVSS 4.0, and the advisory states the issue is known to be actively exploited.
• The web interface ships reachable by default, the minimum prerequisite is a valid authenticated session holding Enterprise Read Only, the lowest built-in tenant role, and the advisory states there is no configuration that can prevent the exposure.
• Fixes are available in VCO 5.2.3.18, 6.1.3.10 and 6.4.2.12; hosted and dedicated orchestrators were patched already, and end-of-support releases have not been assessed.
• Two flaws in the same product now carry two different thresholds: CVE-2026-93952 of 22 September 2026 scored 10.0 with an attack vector that required no privileges, and this one reaches operator rights from a tenant login.
• Arista published two source addresses observed in the attacks and a log-review routine, and the advisory is silent on when the campaign started and what the operators did afterwards.

The orchestrator is the piece of a software-defined wide-area network that holds the configuration for every site, the tunnels between them, and the accounts of the partners who resell or manage those sites. Arista sells VeloCloud Orchestrator as software that a customer can host on its own hardware, and that hosting model puts the upgrade in the customer's own change process.

What a VeloCloud orchestrator controls

Arista's advisory names Enterprise Read Only as the lowest built-in tenant role. That role model explains the blast radius of an authorization flaw here: a tenant login on a shared orchestrator belongs to somebody else's administrative hierarchy, and the object behind it is the routing policy for every site the orchestrator manages.

An inventory should tie each orchestrator to a release train named in the advisory. Each installed build is compared against those trains.

The read-only login that reaches operator rights

The advisory's description is specific about the privilege jump: on an affected system, any authenticated user can gain operator privileges and masquerade as a local superuser operator, with access to functionality intended for internal use only and never meant to be reachable remotely. The reporting adds the practical consequence, that the account can belong to a customer with a read-only view.

Customer-facing roles exist to let a tenant check circuit status and inventory without touching policy. When the lowest such role is enough to become a superuser of the orchestrator, the account inventory of the orchestrator becomes the real perimeter, and every tenant account that a partner or an integrator retains after a project ends sits inside it.

Two flaws in the same product with two different thresholds

The previous advisory in this product shows how the entry conditions moved. Arista Security Advisory 0183 of 22 September 2026 covers CVE-2026-93952, scored 10.0 under CVSS 3.1 and 9.5 under CVSS 4.0, with weakness class CWE-20 and an attack vector that requires no privileges at all.

The October advisory carries a privilege-required vector and a slightly lower score, which is the direction a vendor takes when a flaw needs a session to reach its code path. The two advisories cover the same product one month apart. That pace is the useful part for planning: two critical advisories in a month justify booking the upgrade window now.

The interface that ships reachable by default

Arista's own words on exposure are worth reading twice: VCO is exposed by default, and there is no configuration that can prevent the exposure. A successful attack requires network access to the VCO web interface and a valid authenticated session on the portal, and the minimum role is Enterprise Read Only.

That combination leaves two places to act. An operator can shorten the network path to the web interface to management networks and a VPN while the upgrade waits. On the account list, sessions that no longer belong to a working relationship are the accounts to close first.

The other releases are settled. Hosted and Dedicated orchestrators were impacted and have already been patched, so an operator on the hosted service has the fix already. An operator who hosts the appliance on its own hypervisor has the upgrade left to do, in the release train the site actually runs.

An inventory that has to be read per release train

The fix exists in three places, and the version numbers differ by train: 5.2.3.18 in the 5.2 train, 6.1.3.10 in the 6.1 train and 6.4.2.12 in the 6.4 train, each with later releases included. Arista states that end-of-support versions have not been assessed, and points operators on an unsupported train to its Technical Assistance Center for upgrade options.

The same table carries an awkward detail that belongs in the plan. The October advisory does not mention the September flaw or its fixed releases. The October advisory does not state whether 6.1.3.10 also carries the September fix, so an operator on 6.1 is upgrading into a version whose coverage of the earlier flaw is undocumented. Ask the vendor, and record the answer.

Inventory work here is unglamorous and short: list every orchestrator, name its train and build, and mark the ones behind the fixed version. The infrastructure monitoring with plain-language alerts approach follows the same habit for the systems that report on it: one asset register, one version column, one owner.

What the logs show after an exploitation window

Arista publishes two source addresses observed conducting the attacks, 74.82.197.86 and 38.54.50.151, and asks operators to block them and search logs for their presence. The advisory also names the patterns worth reading in VCO web access logs: unusual URL-like path components, encoded characters, references to local or internal services, and high request rates.

Those patterns describe a SQL injection being probed, and they describe it after the fact. If a compromise is suspected, the advisory asks operators to preserve VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps before remediation, where that is operationally feasible. Preservation before the upgrade is the difference between knowing what happened and replacing the only evidence.

Two limits belong next to that advice. The Hacker News reports that the advisory does not say when the attacks began, which orchestrators were hit, or what the attackers did after exploiting the flaw. The advisory says nothing about whether an upgrade removes access an attacker already holds. Treat the fix as a closing of the entry path and keep hunting.

An order of work for an on-premises orchestrator

Start with the register, because every later step depends on it. One row per orchestrator: host, release train, build, who operates it, which partners hold accounts on it. Compare each build against 5.2.3.18, 6.1.3.10 and 6.4.2.12 in its own train, and label anything older as affected.

Then shrink the reachable surface while the upgrade window is booked: restrict the web interface to management networks, block outbound ports the appliance does not need, and review the administrator list for accounts whose project ended. Then upgrade, one train at a time, and confirm the build string afterwards, since a partially applied rollout looks patched on a dashboard and reports as such.

Then read the logs with the two addresses and the four patterns in hand, and preserve what you find before you touch anything else. The exploitation window predates the advisory, so the log review covers a period that starts before anyone knew to look.

Related reading is the Netics security service. The work the advisory describes is small and completely mechanical: a register, a version column, a network rule, an account review, and an upgrade per train. The earlier PHP leak article is a separate piece on a different flaw.

Sources

Source: Security Advisory 0199 — Arista Networks, arista.com/en/support/advisories-notices/security-advisory/24838-security-advisory-0199, dated 22 October 2026, retrieved 2026-10-23 (CVE-2026-114625; CVSSv3.1 base score 9.9 with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H; CVSSv4.0 base score 9.4; CWE-89; tracked as BUG2043622; a remote attacker may access privileged internal functionality and impact the VCO host; any authenticated user can gain operator privileges and masquerade as a local superuser operator, including functionality intended for internal use only; hosted including Dedicated versions were impacted and have already been patched; the issue was detected by Arista and is known to be actively exploited; affected releases 5.2.x before 5.2.3.18, 6.1.x before 6.1.3.10 and 6.4.x before 6.4.2.12, with end-of-support versions not assessed; VCO exposed by default, exploitation requires network access to the web interface and a valid authenticated session, minimum role Enterprise Read Only, and no configuration can prevent the exposure; observed attack addresses 74.82.197.86 and 38.54.50.151; log patterns to review; preserve web access, backend application, system, database logs and file-system timestamps before remediation; fixed in 5.2.3.18, 6.1.3.10 and 6.4.2.12 and later within each train; unsupported trains handled through TAC).

Source: Security Advisory 0183 — Arista Networks, arista.com/en/support/advisories-notices/security-advisory/24765-security-advisory-0183, dated 22 September 2026, retrieved 2026-10-23 (CVE-2026-93952; CVSSv3.1 base score 10.0 with vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; CVSSv4.0 base score 9.5; CWE-20 improper input validation).

Source: Arista Warns of Critical VeloCloud SQL Injection Zero-Day Exploited in Attacks — The Hacker News, thehackernews.com/2026/10/arista-warns-of-critical-velocloud-sql.html, 22 October 2026, retrieved 2026-10-23 (a read-only customer account can gain operator privileges; orchestrators running the releases that fixed the July and September flaws are still affected; VeloCloud bought from Broadcom with the deal announced in July 2025 and the products earlier known as VMware SD-WAN by VeloCloud; operators create customer and partner accounts and each partner manages a group of customers; the advisory stays silent on when attacks began, which orchestrators were hit and what attackers did afterwards; third VeloCloud Orchestrator flaw reported as exploited since late July and the first requiring a login, with CVE-2026-16812 in July and CVE-2026-93952 in September needing none; VeloCloud Gateway and Edge unaffected and the 7.0 train absent from the affected list; September's flaw fixed only in the 5.2 and 6.4 trains as of 22 October 2026, affecting up to 6.1.3.7 on 6.1 with no fix listed; Arista's earlier warning that a compromised orchestrator could grant access to VeloCloud Edge devices).

Source: Arista Security Advisories 0199 and 0183 and The Hacker News report of 22 October 2026, all retrieved 2026-10-23 — every score, version number and address above traces to one of those three pages. Images are captures of the two Arista advisories plus two Netics editorial diagrams. Related Netics page: security work for small companies.