Arista reports active exploitation of CVE-2026-114625 in VeloCloud Orchestrator, its portal for managing software-defined wide-area networks. An attacker with a valid tenant session can gain operator privileges, reaching internal functionality beyond that tenant’s authority.
The October 22 vendor advisory identifies a SQL-injection flaw, where input changes a database command’s meaning. The minimum required role is Enterprise Read Only, the lowest built-in tenant role.
A login is required; an administrator login is not
An attacker needs network access to the VCO web interface and an authenticated portal session. Arista says any authenticated user on an affected system can masquerade as a local superuser operator.
That makes the exposure broader than stolen administrator credentials. A low-privilege tenant account can cross the boundary into managing the orchestrator and its data.
The affected supported release trains and fixes are:
| VCO release train | Affected versions | Fixed release |
|---|---|---|
| 5.2.x | Before 5.2.3.18 | 5.2.3.18 |
| 6.1.x | Before 6.1.3.10 | 6.1.3.10 |
| 6.4.x | Before 6.4.2.12 | 6.4.2.12 |
Arista says hosted deployments, including Dedicated, were affected and have already been patched. On-premises customers must upgrade themselves. End-of-support releases have not been assessed; contact support for an upgrade path instead of treating their omission as safety.
The advisory excludes VeloCloud Edge and Gateway, along with the listed Arista EOS and CloudVision products. This is an orchestrator issue, not a blanket vulnerability in every device it manages.
What the attack evidence establishes
Exploitation status: active exploitation reported by the affected vendor. Arista says it detected the issue and provides source addresses observed conducting attacks. Sergiu Gatlan’s BleepingComputer report corroborates the advisory and patch versions, but relies on Arista for the attack findings.
The public notice provides neither a victim count nor a complete intrusion timeline. Its severity score describes potential impact, not the number of compromised networks.
Preserve evidence and close the entry point
- Upgrade to the fixed release for your train or a later release containing the fix. Arista lists no configuration change that repairs the vulnerability itself.
- Restrict portal access to trusted administrative networks while arranging the upgrade. This reduces reachability; it does not replace patching or remove an attacker’s existing access.
- If compromise is suspected, preserve logs before remediation where feasible. Arista names web access, backend application, system and database logs, plus relevant filesystem timestamps.
- Review changes and outbound activity. Investigate unexpected administrator actions, unusual outbound connections, backdoor services and webshells, scripts giving an attacker remote control.
- Use the advisory’s indicators as leads. Review historical traffic against its two reported source addresses and inspect unusual paths, encoded characters and request bursts. An address blocklist alone cannot establish that the system is clean.
A patched version closes the documented entry point. Investigating suspicious changes is a separate task; involve Arista’s support team when compromise is suspected.
Arista develops and sells the affected management platform. Its first-party access makes the advisory the source for fixes and exposure, while limiting independent visibility into the reported attacks.
Caveat: absence of the published indicators does not rule out compromise, and unsupported versions remain unassessed.