Hunting VeloCloud Orchestrator exploitation: what CVE-2026-114625 leaves in the logs

When Arista reported CVE-2026-114625 as exploited, it also published the material a defender needs to look for the attack. The advisory names two source addresses and describes the log patterns that suggest someone abusing the SQL injection.

That guidance matters more than usual, because the flaw sits behind a login. A request that carries the injection may pass authentication the way any legitimate session would.

The technical starting point

CVE-2026-114625 is a SQL injection in VeloCloud Orchestrator, the management system for VeloCloud SD-WAN. An attacker who can reach the web interface and holds a valid login at Enterprise Read Only or above can reach the vulnerable query. Arista describes the effect as running in the context of a local superuser, the operator role with full access. CVSS is 9.9.

The interface is reachable by design. Arista states VCO is exposed by default and no VCO setting prevents that.

Indicators named by the vendor

Two addresses were seen conducting the attacks:

74.82.197[.]86
38.54.50[.]151

Blocking them is a first step. The more useful search is across historical logs for any sign of either address. If either appears in VCO web access logs before the block was applied, the timeline matters more than the rule.

What to look for beyond the addresses

Arista points to specific request characteristics in VCO web access logs: unusual URL-like path components, encoded characters, references to local or internal services, and high request rates. Each points to someone reaching a backend query through an interface that expects structured parameters.

A few practical notes for that search:

Requests may carry a valid session cookie. Filtering only on failed authentication misses them.
Read-only accounts are the minimum role for exploitation, so an auditor account making write-shaped requests deserves a look.
Partner accounts that manage multiple customers widen the blast radius and should be reviewed individually.

Arista also recommends watching the VCO host for unexpected outbound network activity, blocking outbound ports that normal operation does not need, and checking for backdoor daemons and webshells. Those steps assume an attacker who has already gained operator rights and may want persistence.

Evidence to preserve

Before fixing anything, Arista advises saving the evidence: VCO web access logs, backend application logs, system logs, database logs and the relevant file-system timestamps. Remediation overwrites state. If a compromise is suspected, the logs are the only reliable account of what happened.

Version context for the hunt

Affected on-premises builds are below 5.2.3.18, below 6.1.3.10 and below 6.4.2.12, depending on the train. Hosted and Dedicated orchestrators were patched by Arista. VeloCloud Gateway and VeloCloud Edge are not affected. The 7.0 train is not listed and, per Arista, is not vulnerable.

Builds that fixed the July and September VCO flaws are still exposed to this one. An orchestrator patched with 5.2.3.16 or 6.4.2.8 is a candidate for compromise during the window between those fixes and now.

The unanswered questions

Arista does not say whether upgrading removes access an attacker already gained. It does not say whether a compromised orchestrator can still reach VeloCloud Edge devices, a risk raised in both earlier advisories. It does not describe post-exploitation activity by the observed attackers.

Those gaps shape how far a hunt should go. Verifying the operator tier and reviewing recent administrator activity, as the interim guidance suggests, is a way to check for actions the intrusion may have left behind.

Exposure context

ZoomEye matches 529 assets for title="VeloCloud". This counts visible VeloCloud web surface, not orchestrators confirmed vulnerable. It indicates where VeloCloud management interfaces appear online, which is a starting point for checking whether the hosts in your estate are among them.