Arista warns of actively exploited SQL injection in VeloCloud Orchestrator, publishes log indicators

Arista has confirmed that CVE-2026-114625, a SQL injection flaw in VeloCloud Orchestrator, is being exploited in the wild. Alongside the disclosure, the vendor published material defenders can act on immediately: two source IP addresses tied to the attacks and a description of how the malicious requests appear in orchestrator logs. A technical write-up on dev.to walks through how to put those indicators to work.

A superuser behind a login

VeloCloud Orchestrator (VCO) is the central management platform for VeloCloud SD-WAN deployments. According to Arista's Security Advisory 0199, the vulnerability is a SQL injection reachable through the web interface by any authenticated user holding the Enterprise Read Only role or above. A successful injection executes with the privileges of a local superuser, the operator role, which carries full access to the system. The flaw scores 9.9 on CVSS.

Reachability is not in question: Arista states that VCO is exposed to the internet by default and that no orchestrator setting changes that. The one mitigating factor, the login requirement, is weaker than it sounds. As the dev.to analysis points out, a request carrying the injection can travel inside a session that authenticated normally, so the attack leaves no failed-login trail.

Indicators and log patterns

Arista names two addresses observed conducting the attacks: 74.82.197[.]86 and 38.54.50[.]151. Blocking them is the obvious first move, but the historical search matters more: if either address appears in VCO web access logs from before a block was put in place, that orchestrator should be treated as a candidate for compromise, and the earliest sighting becomes the anchor for the investigation.

Within those access logs, Arista points to several request characteristics: unusual URL-like path components, encoded characters, references to local or internal services, and elevated request rates. Each is the signature of someone pushing crafted input through an interface that expects structured parameters.

Three practical caveats from the write-up sharpen that search:

• Requests may arrive with a valid session cookie, so filters built around authentication failures will not catch them.
• Enterprise Read Only is the lowest role that can trigger the flaw, so a read-only or auditor account issuing requests that modify state is a red flag.
• Partner accounts that administer multiple customers should be reviewed individually, since one compromise can extend to every tenant they manage.

Assume persistence is possible

Arista's guidance also covers the scenario where an attacker already reached operator level. The vendor recommends monitoring the VCO host for unexpected outbound network activity, closing outbound ports that normal operation does not require, and inspecting the system for backdoor daemons and webshells.

Evidence should be collected before anything is changed: VCO web access logs, backend application logs, system logs, database logs and relevant file-system timestamps. Remediation overwrites state, and once it does, those logs may be the only surviving record of the intrusion.

Who needs to patch

Affected on-premises builds are those below 5.2.3.18, below 6.1.3.10 and below 6.4.2.12, depending on the release train. Arista has already patched its Hosted and Dedicated orchestrators. VeloCloud Gateway and VeloCloud Edge are not affected, and the 7.0 train is not listed as vulnerable.

Crucially, deployments that addressed the earlier VCO flaws from July and September remain exposed. An orchestrator running 5.2.3.16 or 6.4.2.8, the builds that fixed those issues, was still open to this flaw for the entire window between those fixes and now.

What the advisory leaves open

Arista does not say whether upgrading revokes access an attacker may already have, whether a compromised orchestrator can be leveraged to reach VeloCloud Edge devices, a concern raised in the earlier advisories, or what the observed attackers did after gaining access. Those gaps argue for going beyond patching: verifying which accounts hold operator-level rights and reviewing recent administrator actions, as the interim guidance suggests, is the practical way to catch anything the intrusion may have left behind.

Why it matters

An authenticated SQL injection on a management plane that is internet-exposed by default is close to a worst case for SD-WAN estates: one valid low-privilege credential plus one request can yield full operator control of the orchestrator. Because the flaw was exploited before disclosure, patching closes the door but does not tell you whether someone already walked through it; only the logs can. ZoomEye currently returns 529 assets whose title matches VeloCloud, a count of visible management interfaces rather than confirmed-vulnerable orchestrators, but a measure of how much of this surface sits online. For anyone running an affected on-premises build, patching and log review should be treated as a single operation, not two.