>samit_hota
Back to security news

Security News · SN-2026-586

CRITICALCVE-2026-114625MITIGATED

Arista Patches Actively Exploited VeloCloud Orchestrator Zero-Day (CVE-2026-114625)

Affected: Arista VeloCloud Orchestrator (VCO) On-Prem

Samit Hota·
#news#vulnerability-disclosure#arista

Arista Networks has released emergency patches for a critical SQL injection zero-day in its VeloCloud Orchestrator web portal. Tracked as CVE-2026-114625 with a CVSS score of 9.9, the vulnerability is actively being exploited in wild attacks to escalate low-level account privileges to full operator superuser access. The flaw impacts on-premises deployments of VeloCloud Orchestrator (VCO), the central management platform responsible for coordinating VeloCloud Software-Defined Wide Area Network (SD-WAN) infrastructure.

How the CVE-2026-114625 SQL Injection Works

At its root, CVE-2026-114625 is an SQL injection flaw in the web-based management backend of VeloCloud Orchestrator. SQL injection occurs when an application improperly sanitizes user-controlled input before passing it into dynamic database queries. This allows an attacker to alter query logic, bypass authentication logic, or directly query internal application databases.

Unlike previous zero-days affecting VeloCloud Orchestrator disclosed earlier this year, CVE-2026-114625 requires an authenticated session to exploit. However, the barrier to entry is extremely low: an attacker only requires access to an account with the “Enterprise Read Only” role, which is the lowest built-in customer permission level in VCO. Because the VCO web interface is exposed by default with no internal setting available to disable web access, any attacker who compromises a low-privilege customer login—whether through phishing, credential stuffing, or password reuse—can interact directly with the vulnerability.

Once authenticated, a low-complexity web request containing crafted SQL payloads allows the user to act as a local “superuser operator.” This grants access to internal administrative functionality that was never intended to be exposed remotely, completely compromising the confidentiality, integrity, and availability of the orchestrator host.

Blast Radius Across SD-WAN Architecture

In a enterprise SD-WAN architecture, the orchestrator acts as the central control plane, responsible for pushing configuration policies, routing rules, and management commands down to distributed edge appliances. In VeloCloud deployments, operator accounts hold top-tier control across both single-tenant enterprise setups and multi-tenant partner environments, where a single partner account manages multiple customer organizations.

Gaining local superuser access on a VCO instance carries severe implications for the entire network:

  • Host and Database Compromise: Attackers gain high-level access to the underlying database and host operating system, enabling data extraction, state modification, or persistent access.
  • Control Plane Takeover: Operator privileges allow attackers to manipulate tenant accounts, alter routing and traffic management policies, or disrupt network operations across connected organizations.
  • Downstream Edge Device Exposure: As observed in previous VeloCloud Orchestrator vulnerabilities, compromise of the central management orchestrator can serve as a jumping-off point to gain administrative access to connected VeloCloud Edge devices at remote branch locations.

Threat Context and Active Exploitation

This zero-day marks the third actively exploited flaw in VeloCloud Orchestrator reported since late July. While the July flaw (CVE-2026-16812) and September flaw (CVE-2026-93952) were unauthenticated entry points, CVE-2026-114625 demonstrates that threat actors are actively hunting for post-authentication escalation vectors to bypass perimeter fixes. Systems running updates that fixed the July or September flaws remain vulnerable to CVE-2026-114625 unless updated to the latest builds.

According to Arista’s security advisory issued on October 22, active attacks have been confirmed from specific external infrastructure. Security teams should monitor and block connections associated with the following indicators of compromise (IoCs):

  • 74[.]82.197.86
  • 38[.]54.50.151

Fixed Versions and Mitigation Guidance

Arista has already applied patches to hosted and dedicated cloud instances running VCO. For on-premises VeloCloud Orchestrator deployments, administrators must update to the following fixed software builds immediately:

  • 5.2 Release Train: Upgrade to 5.2.3.18 or later
  • 6.1 Release Train: Upgrade to 6.1.3.10 or later
  • 6.4 Release Train: Upgrade to 6.4.2.12 or later

VeloCloud Gateway and VeloCloud Edge devices are not affected by this flaw. The 7.0 release train is also listed as unaffected, and Arista confirmed that any software release not explicitly listed in its advisory is not vulnerable. End-of-support release trains have not been evaluated, and organizations running unsupported software must contact the Arista Technical Assistance Center (TAC) to determine upgrade paths.

If immediate patching is not operationally feasible, administrators should immediately enforce the following defensive measures:

  1. Restrict Access: Restrict network traffic to the VCO web interface so that it is accessible only from trusted administrative management networks.
  2. Block Known Attack Infrastructure: Block traffic to and from 74.82.197.86 and 38.54.50.151 at network boundaries.
  3. Log Analysis: Audit VCO web access logs for suspicious web requests featuring encoded characters, references to internal local services, unexpected URL path segments, or abnormal request spikes.
  4. Outbound Traffic Controls: Monitor outbound network connections originating from the VCO host and block unneeded egress ports.
  5. Audit Administrative Activity: Review recent administrator account creations, role assignments, and system modifications for unapproved changes.
  6. Preserve Forensic Evidence: If a compromise is suspected, capture and preserve VCO web access logs, backend application logs, system and database logs, and file-system timestamps prior to performing remediation steps.

Found something similar in your stack?

Let's find out before it becomes an incident.

Book an advisory call