Arista VeloCloud Orchestrator SQL Injection (CVE-2026-114625)

Latest confirmed position (26 October 2026)

Arista published Security Advisory 0199 on 22 October 2026 for CVE-2026-114625, a SQL injection weakness (CWE-89) in VeloCloud Orchestrator On-Prem. Arista states that it detected the issue and that it is known to be actively exploited. CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalogue on 23 October 2026 as "Arista VeloCloud Orchestrator SQL Injection Vulnerability", with a due date of 26 October 2026 for US federal civilian agencies. CISA's entry lists known ransomware use as unknown.

Arista scores the flaw 9.9 on CVSS 3.1 and 9.4 on CVSS 4.0. The advisory is at its initial revision (1.0) as of this check. Arista lists no separate workaround, only interim defence-in-depth controls, so the real fix is an upgrade. Information may still develop as Arista revises the advisory.

Who should check

This affects organisations that run their own VeloCloud Orchestrator (formerly VeloCloud Orchestrator by Broadcom), typically the management plane for a VeloCloud SD-WAN estate. If your SD-WAN is managed entirely by a provider or by Arista's hosted service, ask them to confirm; Arista says hosted and Dedicated versions were impacted but have already been patched. Other Arista products in the advisory, such as EOS platforms, CloudVision and DANZ Monitoring Fabric, are listed as not affected.

Check the version shown in your orchestrator against these ranges. Arista's advisory lists the affected on-premises builds and the first fixed build in each train:

• VCO 5.2.x before 5.2.3.18 is affected. Fixed in 5.2.3.18 and later.
• VCO 6.1.x before 6.1.3.10 is affected. Fixed in 6.1.3.10 and later.
• VCO 6.4.x before 6.4.2.12 is affected. Fixed in 6.4.2.12 and later.
• Arista says end-of-support versions have not been assessed. Its 7.0.x train is not named in this advisory, so do not read that as confirmation that 7.0.x is unaffected; confirm with Arista TAC if you run it or any unsupported train.

Understand the risk

SQL injection means the application passes attacker-controlled input into a database query in an unsafe way. In this case Arista says the practical result is privilege escalation: any authenticated user can gain operator privileges and masquerade as a local "superuser operator" user, reaching internal functionality and affecting the VCO host.

The precondition is a valid login plus network access to the web interface. The lowest built-in tenant role, Enterprise Read Only, is enough. That matters because many organisations hand out read-only accounts widely, to customers, tenants, contractors and monitoring tools. Arista also states that VCO is exposed by default and that no configuration can prevent the exposure. Reachability of the web interface is therefore your main control until you patch.

An orchestrator controls how your sites and edge devices are configured, so a compromised one is a significant foothold. That is our assessment rather than a statement from the advisory, but it is why we would not leave this one waiting for the next maintenance window.

What to do now

Work through these in order. The first three are quick and non-disruptive. Upgrading will interrupt management access to the orchestrator, so schedule it deliberately, but do not let it slip.

1. Identify every on-premises VCO you run and note its version from the orchestrator's own interface. Compare it with the ranges above. If you cannot find an instance's owner, treat that as the first problem to solve.
2. Restrict access to the VCO web interface to trusted administrative networks. This is Arista's interim control. If the interface is reachable from the internet, remove that exposure first, using your firewall or network access rules. Confirm the change by trying to reach the interface from an untrusted network and checking that the connection fails.
3. Block 74.82.197.86 and 38.54.50.151 at your perimeter and search your VCO web access logs for them. These are the two source addresses Arista names. Treat them as a starting point only; attackers change addresses and their absence does not prove you are clean.
4. If you suspect compromise, preserve evidence before you change anything. Arista asks operators to keep VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps before remediation, where operationally feasible. Take copies off the orchestrator host.
5. Upgrade to the fixed build in your release train, following Arista's upgrade documentation for your version. Arista says customers on unsupported release trains should contact its Technical Assistance Center (TAC) about upgrade options. Taking a VM snapshot or backup first is our suggestion, not an Arista requirement, but it gives you a rollback route if an upgrade misbehaves. Once the upgrade finishes, confirm the orchestrator reports the new version and that administrators and edge connectivity look normal.

Patch, then check whether anyone got in first

Installing a fixed build closes the vulnerability. It does not tell you whether someone used it beforehand, and it will not remove anything they left behind. Because exploitation is confirmed, review the orchestrator as though it may have been touched, especially if it was reachable from the internet before the patch.

Arista's advisory points to these checks:

• Web access logs: look for requests with unusual URL-like path components, encoded characters, references to local or internal services, and unusually high request rates.
• Administrator activity: review recent changes made by operators and administrators for anything nobody on your team can account for. Include new or modified accounts.
• Outbound traffic: look for unexpected outbound connections from the VCO host, and consider blocking outbound ports it does not need for normal operation.
• Persistence: monitor for webshells (small scripts that give an attacker remote control through the web server) and backdoor daemons on the host.

If you find something suspicious

Stop and keep the evidence. Do not rebuild or wipe the host until logs and timestamps have been copied elsewhere. Then involve whoever handles your incident response, and contact Arista TAC. In the UK, the NCSC's guidance on responding to active exploitation is a sensible reference for scoping and recovery. Credentials and API tokens stored on or reachable from the orchestrator should be considered for rotation once you understand the scope.

What is and is not publicly known

The exploitation evidence is Arista's own statement and CISA's KEV listing. We have found no public report naming an affected organisation that is specifically tied to CVE-2026-114625, and a KEV entry does not identify victims, so we name none. We also found no public indication of how widespread the attacks are.

This is the latest in a run of VeloCloud Orchestrator advisories this year. Arista Security Advisory 0144 (27 July 2026) covers CVE-2026-16812, and Advisory 0183 (22 September 2026) covers CVE-2026-93952; Arista describes both as known to be actively exploited. They are separate vulnerabilities with different affected and fixed versions. Being patched for one does not mean you are patched for this one, so check against the builds above rather than assuming.