Arista published Security Advisory 0199 on 22 October: CVE-2026-114625, an SQL injection in on-premises VeloCloud Orchestrator, scored 9.9 on CVSS v3.1 and 9.4 on v4.0. The advisory carries one sentence that settles its priority: "This issue was detected by Arista and is known to be actively exploited."

VeloCloud Orchestrator is the management plane for an SD-WAN estate: the console that decides which branch office talks to which, over which link, under which policy. The advisory lists the affected product as VeloCloud Orchestrator On-Prem, "Formerly VeloCloud Orchestrator by Broadcom", and says the hosted and dedicated versions were impacted too and have already been patched.

The bar is a read-only tenant account

The advisory is precise about what an attacker needs, and the precision is the story. It is filed as CWE-89, ordinary SQL injection, and scored 9.9. "On an affected system, any authenticated user can gain operator privileges and masquerade as a local superuser operator user." The requirement is network access to the web interface and a valid session, and "the minimum user role required is Enterprise Read Only".

That is the lowest built-in tenant role. An orchestrator is multi-tenant by design, and Enterprise Read Only is the account you hand to somebody who should look and not touch: a junior engineer, an auditor, a customer who wanted visibility. Every one of those is now an administrative account on the box that manages the network.

No configuration prevents it

The sentence that follows is rarer still: "VCO is exposed by default... There is no configuration that can prevent the exposure." Most advisories offer a setting to turn off or a flag to flip while you schedule the upgrade. This one says in advance that there is not one, and the 6 measures Arista offers instead are all perimeter controls.

Restrict the web interface to trusted administrative networks. Watch for known malicious sources. Block outbound ports you do not need. Every one of those reduces who can reach the portal, and none of them changes what a legitimate low-privilege session can do once it is there.

Three exploited Orchestrator flaws since July

Arista has now reported three exploited VeloCloud Orchestrator vulnerabilities in three months: an unauthenticated OS command injection in July, tracked as CVE-2026-16812, another in September as CVE-2026-93952, and this one on 22 October. All three were exploited rather than merely found.

Three in a quarter is a pattern about a product rather than a run of bad luck, and it has an operational consequence. If you patched in July and again in September, you have no reason to believe October is the last of it. Plan the upgrade path, not the upgrade.

The advisory also notes that end-of-support versions "have not been assessed", which is not the same as unaffected.

Read the mitigation list as a finding

Two items on Arista's defence-in-depth list are not generic: monitor for backdoor daemons and webshells, and review recent administrator activity for unexpected changes. Vendors do not usually name webshells in a hypothetical. Combined with two attacker addresses published as indicators, 74.82.197.86 and 38.54.50.151, the list reads as a description of what has already been found on somebody's orchestrator.

The advisory also asks operators to preserve web access logs, backend application logs, system logs, database logs and file-system timestamps before remediation. That is the same ordering problem we wrote about on the SiteGuard flaw whose patch may delete the evidence: the fix and the investigation want the machine in different states, and the vendor is telling you which comes first.

What to do

  • Upgrade on-premises orchestrators to 5.2.3.18, 6.1.3.10 or 6.4.2.12. Hosted and Dedicated instances were affected and Arista says they are already patched.
  • Preserve the logs before you upgrade, in the order the advisory lists them.
  • Search web access logs for unusual URL-like path components, encoded characters, references to internal services, and high request rates. Block the two published addresses and check whether they appear historically.
  • Audit tenant accounts, particularly read-only ones you have forgotten about. The lowest role is the attack surface here.
  • If you are on an end-of-support train, assume affected until told otherwise and talk to support about the upgrade path.

What is not established

  • When the attacks began, how many orchestrators were reached, or what was done after access. Arista does not say.
  • Who is behind it. No attribution is offered.
  • Whether the 6.1 fix also covers the September flaw. Neither advisory makes that clear.
  • Whether end-of-support versions are affected. They were not assessed.
  • How the two published addresses relate to each other or to any known actor.
  • Whether the three Orchestrator flaws exploited since July share a root cause or an actor.