# VeloCloud Orchestrator: from standard account to superuser via SQL injection

> Arista confirms SQL injection in VeloCloud Orchestrator. An authenticated user can impersonate a superuser operator.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/arista-velocloud-sql-injection-superuser-2026/

**Arista Notice dated October 22, 2026.** [Arista](https://www.arista.com/ko/support/advisories-notices/security-advisory/24838-security-advisory-0199) declares **CVE-2026-114625** actively exploited. The flaw is an SQL injection in VeloCloud Orchestrator. It allows **any authenticated user**, even low privilege, to take the rights of a local operator `superuser` and access internal functions normally not exposed remotely. The word “authenticated” is decisive: the notice does not describe a takeover by a visitor without an account.

## Why SQL injection also crosses an identity boundary

SQL injection occurs when an application assembles a database command with an untrusted value, instead of passing that value as a separate parameter. The database can then interpret part of the input as a query structure. The result depends on the vulnerable query and the privileges of its SQL account: reading rows, modifying values ​​or bypassing a filter. For VeloCloud, Arista publishes the security impact: a standard account can **impersonate a superuser operator**. It does not publish the SQL query, the injected field or a PoC; we cannot therefore claim to know the exact payload that enables impersonation.

Privilege hopping is critical because the orchestrator carries the control plane of an SD-WAN network. Operator rights cover functions that were not intended for the ordinary remote user. Arista asserts that the confidentiality, integrity and availability of the Orchestrator and the data it manages may be compromised. The precise content of each deployment and the actions carried out by the actors observed remain outside the bulletin.

## How to investigate the flaw without inventing a PoC

In an authorized audit, at least two roles must be created: a low-privilege user and a reference superuser. We inventory the calls that the first can reach, then we track their SQL queries and the resulting authorization decisions. Input that changes the query structure, returned identity, or accessible functions is a signal. The fix must be evaluated at two levels: query configuration and authorization control independent of the result of a database search.

This method describes a family of tests, not the actual discovery of the CVE. The Arista bulletin says the flaw was detected by the company and is being exploited, but does not provide a public demonstration detailed enough to attribute an endpoint or injection technique. Publishing an example of SQL presented as the “VeloCloud exploit” would therefore be an invention.

## Scope and response

The bulletin distinguishes **VCO on-premise** from hosted instances, including dedicated ones, which Arista says it has already fixed. For on-premises, compare the actual installed version to the [Arista advisory](https://www.arista.com/ko/support/advisories-notices/security-advisory/24838-security-advisory-0199) affected version table, then examine regular accounts, administrator activity, configuration changes, and internal function access logs. The correction closes the injection path; it does not remove a privileged identity or modified configuration during operation.

The case shows that SQL injection is more than “reading a table”. If the application uses the database to determine identity and privileges, a forged query can move the attacker from a limited role to the entire control plane.

**Primary source:** [Arista Security Advisory 0199](https://www.arista.com/ko/support/advisories-notices/security-advisory/24838-security-advisory-0199).