Arista VeloCloud Orchestrator Zero-Day Is Being Exploited: Patch Now

Arista Networks disclosed a critical, actively exploited zero-day vulnerability in its on-premises VeloCloud Orchestrator (VCO) on October 22, 2026. Tracked as CVE-2026-114625, the flaw lets an authenticated user with the lowest available role escalate to full operator privileges, effectively masquerading as a superuser. CISA added it to its Known Exploited Vulnerabilities catalog the next day, October 23, with a remediation deadline of October 26 for federal agencies — a deadline that has already passed. If you run an on-premises VCO instance, this is not a patch you can leave for next sprint.

What happened

Arista's Security Advisory 0199 says VeloCloud Orchestrator on-prem contains a flaw that lets a remote, authenticated attacker reach privileged internal functionality that isn't meant to be reachable at all. In Arista's own words, "any authenticated user can gain operator privileges and masquerade as a local 'superuser operator' user." Arista says it detected the exploitation itself, and the advisory states the issue is "known to be actively exploited." VCO is exposed by default, and Arista's advisory is explicit that no configuration change can prevent the exposure — only a software update closes it.

The vulnerability, explained

CVE-2026-114625 is classified under CWE-89, SQL injection — a class of bug where an application builds a database query using attacker-supplied input without properly separating code from data, letting the attacker's input change what the query actually does. In this case, the injection point lets a logged-in user with minimal privileges manipulate backend queries in a way that grants them operator-level access, the highest tier of control over the orchestrator. The practical effect: a VCO account that should only be able to view limited customer data can instead take over the whole appliance.

Two CVSS scores apply here, reflecting two different scoring standards. Under CVSS v3.1, Arista rates it 9.9 out of 10. Under the newer CVSS v4.0 framework, the score is 9.4. Both land in the critical band; the slight difference reflects how the two standards weigh factors like required privileges and user interaction, not any disagreement about severity.

For readers less familiar with the term, SQL injection has been one of the most common serious web application vulnerabilities for more than two decades, consistently appearing in industry lists of the most dangerous software weaknesses. It happens when an application takes input from a user — a search box, a form field, an API parameter — and inserts it directly into a database query without properly escaping or parameterizing it first. If the application doesn't separate "this is data" from "this is a command," an attacker can craft input that the database interprets as part of the command itself, effectively hijacking the query to do something the developer never intended, like returning data it shouldn't or, as in this case, altering what privilege level gets assigned to a session. It's an old, well-understood class of bug, which makes it more surprising to find in current, actively maintained enterprise software rather than less.

Why the privilege requirement doesn't make this low-risk

It's tempting to read "requires an authenticated session" as meaning this is less dangerous than a fully unauthenticated flaw, but two things cut against that read here. First, the role required to exploit it — Enterprise Read Only — is the lowest built-in customer role in VCO, the kind of access a managed service provider might hand out routinely to a client's own IT staff, a monitoring tool, or a junior team member. Second, VCO is a management plane for SD-WAN infrastructure: an attacker who compromises the orchestrator doesn't just get into one customer's network, they get into the control plane that manages many sites' worth of routing and connectivity. A low privilege bar combined with a high-value target is exactly the profile of bug attackers go looking for.

The third VeloCloud Orchestrator zero-day since July

This is not an isolated incident for the product. CISA's Known Exploited Vulnerabilities catalog shows three separate actively exploited VeloCloud Orchestrator flaws added in 2026 alone:

Three actively exploited, CISA-catalogued zero-days in the same product within four months is an unusual pace even by the standards of edge and SD-WAN appliances, which have been a favored target for attackers across the industry precisely because they sit at the perimeter and are often under-monitored compared to core infrastructure. If your organization runs on-prem VCO, this history is a reason to treat "patch when convenient" as the wrong posture going forward, not just for this specific CVE.

Indicators of compromise

Arista's advisory names two IP addresses observed in connection with exploitation attempts: 74.82.197.86 and 38.54.50.151. The advisory recommends checking VCO web access logs for connections from these addresses, along with broader signs of compromise: unusual URL-like path components or encoded characters in request logs, references to internal or local-only services appearing in external requests, and abnormally high request rates. If you find anything suspicious, Arista's guidance is to preserve web access logs, backend application logs, system logs, database logs, and relevant file-system timestamps before you start remediation — overwriting that evidence during a rushed fix is a common way investigators lose the ability to determine what actually happened.

It's worth being clear about what these two IP addresses are and are not useful for. They're a snapshot of infrastructure Arista observed during its own investigation, not a complete or permanent list — attackers rotate infrastructure routinely once indicators become public, and a sophisticated operator exploiting a vulnerability this valuable has every incentive to do so quickly. Treat a hit against either address as a strong signal of compromise worth investigating immediately, but don't treat a clean log against only those two addresses as proof you weren't targeted by the same campaign through different infrastructure.

Who's affected

The vulnerability applies specifically to on-premises VeloCloud Orchestrator deployments — that is, instances organizations run and manage themselves, rather than through Arista. Affected versions are:

• VCO 5.2.x releases prior to 5.2.3.18
• VCO 6.1.x releases prior to 6.1.3.10
• VCO 6.4.x releases prior to 6.4.2.12

Arista's Hosted and Dedicated VCO offerings, where Arista itself operates the orchestrator, were also affected but have already been patched by Arista — customers on those tiers don't need to take action for this specific CVE. VeloCloud Gateway and VeloCloud Edge, the other two components of Arista's SD-WAN stack, are not affected; this is an Orchestrator-only issue. Arista's advisory does not assess end-of-support release trains, so organizations still running those are, by definition, not covered by this fix at all.

How to patch and mitigate

Arista's resolution is straightforward: upgrade to VCO 5.2.3.18, 6.1.3.10, or 6.4.2.12, or a later release in the relevant train. Organizations on an unsupported release train should contact Arista's Technical Assistance Center to discuss upgrade paths rather than staying on an unpatched version.

Until you can patch, Arista recommends several interim steps: restrict access to the VCO web interface to trusted administrative networks rather than leaving it reachable from the general internet or a broad internal range; monitor for connection attempts from the known malicious IP addresses listed above; watch for unexpected outbound network activity from the VCO host and consider blocking outbound ports you don't need; look specifically for signs of backdoor processes or web shells, which are common follow-on tools after this type of compromise; and review recent administrator activity logs for changes nobody on your team can account for.

None of those mitigations is a substitute for the actual patch. Restricting network access and watching logs buys time and raises the bar for an opportunistic attacker, but a determined one who already has a foothold inside your administrative network, or who compromises a legitimate low-privilege account through an unrelated method like credential stuffing or phishing, can still reach the vulnerable code path. Treat the interim steps as damage control while you schedule the upgrade, not as a reason to delay it.

CISA's deadline, and what it means if you're not a federal agency

CISA's Known Exploited Vulnerabilities catalog entry set an October 26, 2026 remediation deadline, tied to its Binding Operational Directive on prioritizing security updates based on risk. That directive is legally binding only for U.S. federal civilian agencies — it doesn't carry a legal requirement for private companies or organizations outside that scope. In practice, though, security teams across industries widely treat a CISA KEV listing and its associated deadline as the de facto urgency bar for any internet-facing or business-critical system, because the catalog only includes vulnerabilities CISA has confirmed are already being exploited, not theoretical risks. If your organization has already missed the October 26 date, that isn't a reason to deprioritize the fix — it's a reason to treat it as overdue rather than upcoming.

CISA's required action for this entry also points agencies to its Binding Operational Directive 26-04 guidance and a separate "Forensics Triage Requirements" document, which lays out what evidence agencies need to preserve before remediating a KEV-listed flaw they suspect was actually exploited against them — the same preserve-logs-before-fixing principle Arista's own advisory recommends. Even organizations with no federal reporting obligation can benefit from following that same sequence: confirm exposure, preserve evidence, then remediate, rather than patching first and losing the ability to determine afterward whether you were actually compromised.

What next

Patch your on-prem VCO instances now if you haven't, check your access logs against the two indicators Arista published, and lock down management-plane access to admin-only networks regardless of what else you do. Given that this is the third actively exploited VCO zero-day CISA has catalogued since July, it's also worth asking whether on-prem VCO is still the right deployment model for your organization versus Arista's Hosted or Dedicated offerings, which have so far been patched by Arista before each of these issues reached customers who self-host. For broader context on how to prioritize patches like this one, see our coverage of the PHP2Shell patching wave, and if VPN access is part of your remote-management plan for infrastructure like this, our explainer on VPN kill switches covers a related piece of the access-control picture.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage