Arista VeloCloud Orchestrator SQL injection: CVE-2026-114625

VeloCloud Orchestrator is the control plane for a VeloCloud SD-WAN: the single console that provisions and configures every edge. CVE-2026-114625 is a SQL injection in the on-premises version of that console, and its effect is a privilege jump. A user holding the lowest built-in tenant role can reach functions reserved for a local "superuser operator" and act against the orchestrator and the host it runs on.

Arista published Security Advisory 0199 on 22 October 2026 and stated that it detected the issue itself and that it is being actively exploited. CISA added the CVE to its Known Exploited Vulnerabilities catalog the next day, 23 October, set a 26 October due date, and flagged it for forensic triage. Hosted and Dedicated VeloCloud instances were affected but Arista has already patched them; on-premises operators have to act.

Who is affected

The flaw is specific to on-premises VeloCloud Orchestrator (formerly VeloCloud Orchestrator by Broadcom). Each supported release train has its own fixed build.

Arista did not assess end-of-support versions. For exposure, the advisory is blunt: the VCO web interface is exposed by default, and no configuration prevents that exposure. A successful attack requires network access to that interface and a valid authenticated session on the portal, with Enterprise Read Only, the lowest tenant role, sufficient.

How CVE-2026-114625 works

Arista classifies the root cause as SQL injection (CWE-89) but does not disclose the vulnerable endpoint, parameter or component. What the advisory describes is the outcome: through the injection, any authenticated user can gain operator privileges and masquerade as a local superuser operator, including access to functionality intended for internal use only and not meant to be remotely reachable.

The preconditions are therefore low. An attacker needs a foothold account on the portal at the lowest tenant tier and network reach to the web interface. From there the injection turns a read-only tenant login into effective operator control, which Arista says can compromise the confidentiality, integrity and availability of the orchestrator and the data it manages.

One third-party summary described the preconditions differently, suggesting credentials were not required and referring to certificate-based edge-to-orchestrator authentication. Arista's advisory says neither of those things; it requires a valid authenticated portal session. Where a secondary source and the vendor advisory disagree, follow the advisory.

Is it being exploited?

Yes, on the vendor's own statement. Arista says the issue was detected by Arista and is known to be actively exploited in the wild. It does not say when exploitation began or how many systems were hit, and it names no actor or campaign.

• CISA KEV: added 23 October 2026, due 26 October 2026, forensic triage required.
• Known malicious source IPs: 74.82.197.86 and 38.54.50.151, per Arista, to block and to search for in logs.
• Ransomware: CISA lists use as unknown.

Check your exposure

There is no reliable unauthenticated version banner to key on, so start from your own inventory and your logs.

# On the orchestrator host, confirm the installed release train and build.
rpm -qa | grep -i vco 2>/dev/null
cat /opt/vc/VERSION 2>/dev/null || cat /etc/velocloud/VERSION 2>/dev/null
 
# Search web access logs for the two source IPs Arista flagged.
grep -E '74\.82\.197\.86|38\.54\.50\.151' /var/log/nginx/*access* 2>/dev/null

Paths vary by install; adjust to your deployment. If you manage assets centrally, inventory every on-prem VeloCloud Orchestrator and record its build against the table above.

Fix it

Upgrade on-prem VCO to the fixed build for your train: 5.2.3.18, 6.1.3.10 or 6.4.2.12, or later. Customers on unsupported release trains should contact Arista TAC for a path forward.

Until the upgrade is in place, Arista's interim steps are to restrict the VCO web interface to trusted administrative networks, block the two known IPs and monitor for access from them, watch for unexpected outbound traffic from the VCO host and block outbound ports that normal operation does not need. If you suspect compromise, preserve the web access logs, backend application logs, system and database logs, and relevant file-system timestamps before you remediate.

Detect attempts and compromise

Arista's indicators are log-centric. Review VCO web access logs for:

• Unusual URL-like path components and encoded characters in request paths, the usual texture of injection probing.
• References to internal or local services in requests that a tenant login should never generate.
• High request rates from a single source.
• Traffic to or from 74.82.197.86 or 38.54.50.151.

If compromise is suspected, Arista also advises checking for backdoor daemons and webshells on the host and reviewing recent administrator activity for changes you did not make. Treat an orchestrator that shows these as a control-plane compromise: it configures every edge in the fabric.

Beyond this patch

A management plane that is internet-exposed by default, with a privilege-jump bug reachable by the lowest role, is a reminder to put admin consoles behind network controls rather than trusting role separation alone. Inventory matters most here: you cannot patch an orchestrator you forgot you ran. For how continuous testing surfaces that kind of exposure on every change, see AI pentesting on every pull request.