deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Arista warns of actively exploited CVSS 9.9 SQL injection in VeloCloud Orchestrator

Arista says CVE-2026-114625, a CVSS 9.9 SQL injection in VeloCloud Orchestrator, is being exploited in the wild and needs only a read-only login. Fixed builds exist for the 5.2, 6.1 and 6.4 trains.

Arista warns of actively exploited CVSS 9.9 SQL injection in VeloCloud Orchestrator

A SQL injection vulnerability in VeloCloud Orchestrator, tracked as CVE-2026-114625 and rated 9.9 out of 10 on the CVSS scale, is being exploited in the wild, according to Arista Security Advisory 0199. Exploitation needs a valid account with Enterprise Read Only permissions or above, which limits who can attack but leaves any exposed orchestrator with a loose account inventory at risk. A writeup on dev.to translates the advisory into an order of work for owners.

What the advisory establishes

As the dev.to summary lays out, two facts drive the response. VCO ships exposed by default, and no setting inside the product removes that exposure. And because an account as limited as Enterprise Read Only is enough to exploit the injection, knowing which accounts exist is as important as knowing which hosts exist.

The fixed releases are per train: 5.2.3.18 for the 5.2 train, 6.1.3.10 for 6.1, and 6.4.2.12 for 6.4. Arista has already applied the fix to its Hosted and Dedicated orchestrators. Gateway and Edge components are unaffected, and nothing on the 7.0 train is listed as vulnerable. Owners on end-of-support trains need to raise the matter with Arista TAC.

One detail will catch operators out: the builds that resolved the July and September VCO flaws fall short of the current fixed releases, so even a host patched twice in recent months remains an upgrade candidate.

What to fix first

Since most organisations run more orchestrators than they can upgrade in a single evening, the dev.to writeup proposes this order:

  1. Capture logs from every orchestrator that was reachable at any point while unpatched — VCO web access logs, backend application logs, system logs, database logs and file-system timestamps — before an upgrade overwrites them.
  2. Record the exact build running on each host and map it against its own train; a 6.4 build cannot be judged by the 5.2 row.
  3. Upgrade externally reachable orchestrators first, then internal ones, then lab and standby instances.
  4. Bring the tenants behind partner accounts into the same patching window, because a partner login often spans several customers and one unpatched host can turn into a multi-customer incident.
  5. Re-scan the whole estate once the window closes; incomplete rollouts are where multi-tenant environments most often fail.

Accounts and interim controls

Because a read-only login is sufficient for exploitation, the access review carries the same weight as the patch itself. The writeup recommends enumerating every account with web interface access — auditor and integration accounts, partner staff, and anything opened for a project that has since ended — deleting what lacks a clear justification, and treating whatever must remain as a possible route to operator-level rights until the fixed build is deployed.

For hosts that cannot be upgraded immediately, Arista recommends limiting VCO web interface access to trusted administrative networks, watching for connections from known malicious addresses, monitoring the VCO host for unexpected outbound traffic, blocking outbound ports that normal operations do not use, hunting 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. In VCO web access logs, the patterns worth searching for are URL-like path segments that look out of place, encoded characters, references aimed at local or internal services, and unusually high request rates.

What the advisory leaves open

The advisory does not say whether an upgrade evicts an attacker who has already gained access, nor whether a compromised orchestrator continues to expose the edge devices it manages. Both questions were also unanswered in earlier VCO advisories, so operators should not assume the patch closes a live intrusion.

The dev.to writeup draws a useful line: the vulnerability can be considered closed once the fixed build runs on every reachable host, while the incident only closes when the preserved logs and the administrator activity review turn up nothing. Those two milestones rarely land on the same day.

For triage, a ZoomEye query for the VeloCloud page title returns 529 assets. The writeup stresses that this counts visible VeloCloud web surface, not confirmed vulnerable orchestrators, making it a guide for where to look first rather than a measure of impact.

Why it matters

A 9.9-severity SQL injection in the management plane of an SD-WAN estate, confirmed as actively exploited, is close to the worst case for enterprise networking. Three details raise the practical stakes. A read-only account is enough to exploit the bug, so forgotten auditor, integration and partner accounts become part of the attack surface. Hosts patched for this summer's VCO flaws are still vulnerable, so past patching is not proof of safety. And because the advisory is silent on whether an upgrade removes standing attacker access, remediation has two halves — a patch rollout and a log-and-account review — and only finishing both closes the incident.

  • #security
  • #sql-injection
  • #vulnerability
  • #velocloud
  • #arista

Related posts