What to fix first for CVE-2026-114625: a practical sequence for VeloCloud Orchestrator owners

Arista's advisory settles the technical facts of CVE-2026-114625: a SQL injection in VeloCloud Orchestrator, CVSS 9.9, exploited in the wild, requiring a valid login at Enterprise Read Only or higher, with per-train fixed releases.

What remains is the order of work. Most organisations have more orchestrators than they can patch in one evening, and the advisory leaves a few questions open that change the sequence.

The facts that drive the order

VCO is exposed by default and no VCO setting prevents that exposure. Any valid login at Enterprise Read Only or higher is enough, so the account inventory matters as much as the host inventory.

Builds that fixed the July and September VCO flaws are below the current fixed releases and remain exposed. An orchestrator that was patched twice this quarter is still a candidate.

Train	Fixed release
5.2	5.2.3.18
6.1	6.1.3.10
6.4	6.4.2.12

Hosted and Dedicated orchestrators are already patched by Arista. Gateway and Edge are not affected. Releases on the 7.0 train are not listed as vulnerable. End-of-support trains require a conversation with Arista TAC.

A defensible sequence

Preserve logs on every orchestrator that has been reachable while unpatched. Arista lists VCO web access logs, backend application logs, system logs, database logs and file-system timestamps. Do this before the upgrade overwrites anything.
Record the exact build of each host and map it to its own train. A 6.4 build cannot be judged against the 5.2 row.
Patch externally reachable orchestrators first, then internal ones, then lab and standby instances.
Patch the tenants behind partner accounts in the same window. A partner login that reaches several customers turns a single unpatched host into a multi-customer problem.
Re-scan the estate once the window closes. Partial rollouts are the common failure mode in multi-tenant environments.

The account work that runs in parallel

Because a read-only login is sufficient, the access review carries the same weight as the patch. Enumerate every account with web interface access, including auditor and integration accounts, partner staff and any account created for a project that has ended. Remove what cannot be justified. Where removal is not possible, treat the account as a path to operator rights until the fixed build runs.

Interim controls while the window stays open

Arista recommends restricting VCO web interface access to trusted administrative networks, monitoring for connections from known malicious addresses, watching the VCO host for unexpected outbound traffic, blocking outbound ports normal operations do not need, looking for backdoor daemons and webshells, and reviewing recent administrator activity for unexplained changes.

The two addresses named in the advisory are 74.82.197[.]86 and 38.54.50[.]151. The request patterns to search for in VCO web access logs are unusual URL-like path components, encoded characters, references to local or internal services, and high request rates.

Deciding when the incident is closed

The advisory does not say whether upgrading removes access already gained. It does not say whether a compromised orchestrator still exposes edge devices. Both were open questions in the earlier VCO advisories as well.

A workable rule: the vulnerability is closed when the fixed build runs everywhere it is reachable, and the incident is closed when the preserved logs and the administrator activity review come back clean. Those are different dates.

Exposure

ZoomEye matches 529 assets for title="VeloCloud". That is a count of visible VeloCloud web surface, not confirmed vulnerable orchestrators, and it is useful for deciding where to look first rather than for estimating impact.