VeloCloud Orchestrator Flaw: Read-Only Login Gives Superuser

CVE-2026-114625: How a Read-Only Login Becomes Superuser Control of VeloCloud Orchestrator

Quick Answer
Attackers are exploiting CVE-2026-114625, a VeloCloud Orchestrator SQL injection that lets any logged-in user, even read-only, gain superuser operator access. Patch on-prem VCO to 5.2.3.18, 6.1.3.10, or 6.4.2.12 and hunt for compromise.

Last verified: October 24, 2026

Picture a branch-office manager who only ever uses the SD-WAN portal to glance at link health. Her account is read-only. Nobody has ever worried about it. Then her password turns up in a credential dump, and an attacker logs in to the same dashboard she uses every morning.

Under normal assumptions, that is a minor incident. With the VeloCloud Orchestrator vulnerability tracked as CVE-2026-114625, it is not. According to Arista's advisory, a login at the lowest tenant level is enough to climb all the way to superuser operator.

If you run an on-premises VeloCloud Orchestrator (VCO), treat this as a patch-and-investigate event, not routine maintenance. Arista says it is already being exploited.

Table of Contents

• What happened
• Why an SD-WAN orchestrator is a crown jewel
• How a low-privilege account becomes superuser
• Affected and fixed versions
• Third exploited VCO flaw since July
• Indicators and what to hunt for
• Response playbook for exploited vulnerability management
• Expert tips
• FAQ
• Conclusion

What Happened

Arista Networks published Security Advisory 0199 on October 22, 2026. It describes CVE-2026-114625, an SQL injection flaw (CWE-89) in VeloCloud Orchestrator On-Prem, the web portal used to configure and monitor VeloCloud SD-WAN deployments. Arista tracks it internally as BUG2043622.

Per the advisory, the flaw scores 9.9 under CVSS v3.1 and 9.4 under CVSS v4.0. Arista states it detected the issue itself and that it is known to be actively exploited.

The advisory says any authenticated user on an affected system can gain operator privileges and masquerade as a local "superuser operator." That role reaches functionality meant for internal use only, not for remote access.

Confirmed facts so far:

• Exploitation needs network access to the VCO web interface and a valid authenticated portal session.
• The lowest built-in tenant role, Enterprise Read Only, is reportedly enough.
• The attack is low complexity and needs no user interaction.
• Arista has already patched its Hosted and Dedicated VCO instances.
• Arista says VCO is exposed by default and no configuration setting removes that exposure.

Why an SD-WAN Orchestrator Is a Crown Jewel

An orchestrator is the brain of the network. It pushes policy, tracks every site, and holds the data that describes how branches, data centers, and clouds connect.

That is why SD-WAN security deserves its own line in your risk register. Compromise the management plane and you inherit visibility, and potentially control, over everything it manages.

Arista warns that successful exploitation may affect the confidentiality, integrity, and availability of the orchestrator and its managed data. In its July and September advisories for earlier flaws, Arista also said an orchestrator compromise could give attackers access to VeloCloud Edge devices. For this CVE, reporting by The Hacker News notes the advisory does not say whether that risk applies, so assume nothing either way until you have checked.

How a Low-Privilege Account Becomes Superuser

Arista has not published technical details of the injection itself, and I will not guess at them. What we can reason about, clearly labeled as analysis, is how an attacker would get the login that this flaw requires.

Analysis, not confirmed fact: the "authenticated" requirement is a lower bar than it sounds. Realistic sources of a low-privilege VCO login include:

• Credentials reused from another breach or sold in a dump
• Phished or password-sprayed tenant users
• Shared or long-forgotten read-only accounts created for contractors or dashboards
• Accounts at managed service providers that serve multiple customers

Think of it as a two-stage problem. Stage one is getting any valid login. Stage two is the SQL injection that turns that login into operator control. Many teams defend stage one carefully for admin accounts and barely at all for read-only ones. This flaw punishes that gap.

Affected and Fixed Versions

According to Arista's advisory, on-premises deployments are affected until upgraded to the fixed release in their train:

Release train	Affected	Fixed in
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

VeloCloud Gateway and VeloCloud Edge are not affected by this CVE, and Arista lists its EOS-based products as unaffected too. Arista has not assessed software that has reached end of support, so those customers should contact Arista's Technical Assistance Center about upgrade options.

One detail catches people out. Reporting by The Hacker News points out that the releases that fixed the July and September flaws are older than these new fixed versions, so they remain vulnerable. Being "patched last month" does not mean you are covered.

Third Exploited VCO Flaw Since July

This is the third VeloCloud Orchestrator vulnerability Arista has reported as exploited since late July, and the first of the three that requires a login. SecurityWeek frames it as three zero-days in four months, while other outlets say three months. Since late July is the safest description.

CVE	Disclosed	Login needed	CVSS
CVE-2026-16812	July 27	No	10.0
CVE-2026-93952	September 22	No	10.0
CVE-2026-114625	October 22	Yes (read-only is enough)	9.9 (v3.1)

The first two are described in Arista advisories as not requiring authentication. Do not confuse them with each other, and do not confuse them with unrelated SQL injection stories in other vendors' products.

My read, as analysis: three exploited flaws in one management product in about three months suggests that attackers are actively targeting it. If VCO is in your environment, assume it is being watched.

Indicators and What to Hunt For

Arista named two source IP addresses it observed conducting attacks:

• 74.82.197.86
• 38.54.50.151

Block both and search historical logs for them. Arista also advises examining the following in web and application logs:

• Unusual URL-like paths
• Encoded characters in requests
• References to local or internal services
• Unusually high request rates

Arista has not said when attacks began, which orchestrators were hit, or what attackers did afterward. Lacking that, your hunt window should reach back as far as your logs allow, not just to October 22.

A Starting-Point Log Search

This command searches web server logs, including rotated and compressed files, for the two published IP addresses. Log locations differ by deployment, so adjust the path to wherever your VCO web logs live.

zgrep -hE '74\.82\.197\.86|38\.54\.50\.151' /path/to/vco/web/logs/*

What it does: prints every log line mentioning either address.
When to use it: immediately, before and after patching.
Expected output: no output means no match in those files. Any hit deserves a full timeline review of that session and account.

A second search can surface requests containing encoded characters or internal-service references. These are hunting leads, not attack signatures, so expect noise and review matches by hand.

zgrep -hiE '%2e%2e|%00|localhost|127\.0\.0\.1' /path/to/vco/web/logs/*

What it does: flags requests that contain traversal-style encoding, null bytes, or loopback references.
Expected output: some legitimate matches are normal. Focus on authenticated sessions from low-privilege accounts that suddenly touch operator-only paths.

Response Playbook for Exploited Vulnerability Management

Because exploitation is confirmed, work the problem in this order. The sequence follows Arista's guidance and general incident response practice.

1. Preserve evidence first where feasible. Arista recommends keeping web access, backend application, system, and database logs, plus relevant file timestamps, before remediation. Patching can overwrite the trail.
2. Upgrade to the fixed release for your train, or a later one. Interim controls reduce exposure but do not replace the fix.
3. Restrict the web interface to trusted administrative networks. Arista notes this is a temporary safeguard, not a fix, because the product is exposed by default.
4. Block the two published IP addresses at the perimeter and search history for them.
5. Review administrator changes. Look for new operator accounts, role changes, and configuration edits you did not make.
6. Check for unexpected outbound connections from the orchestrator host, and monitor for backdoor services or webshells.
7. Rotate credentials where compromise is plausible, starting with portal accounts of every tier, including read-only ones.
8. Validate managed device state. In earlier advisories Arista suggested validating Edge device state after an orchestrator compromise. Applying the same discipline here is prudent, even though this advisory is silent on Edge exposure.

For governance teams, this maps cleanly to the patch-management and incident-handling practices in the NIST frameworks. One practical note: at least one October 22 threat brief listed the flaw as not yet on CISA's Known Exploited Vulnerabilities list. Check the current catalog yourself rather than relying on that snapshot.

Expert Tips

• Audit your read-only accounts today. Most organizations cannot say how many exist, who owns them, or when they last signed in. That is the exact population this flaw rewards.
• Put MFA on every tier. Low-privilege accounts often skip it. Strong authentication will not fix the bug, but it raises the cost of stage one.
• Do not expose management portals to the open internet. If remote administration is essential, place it behind a VPN or a zero trust network access gateway with device checks.
• Alert on privilege jumps. A tenant-level account touching operator-only functions should generate a ticket, whatever the root cause.
• Track fixed-version thresholds, not just "latest patch." The July and September fixes did not cover this one. Build a simple spreadsheet of train, current version, and required minimum.
• Be wary of vendor-neutral claims of safety. Hosted and Dedicated instances were patched by Arista, but on-prem customers own their own timeline.

Related Cybersecurity Topics You Should Explore

• 55 Linux Job Control Commands Every SOC Analyst Should Know
  
• PHP2Shell Patch Guide: Fix CVE-2026-109618 & 109619 Fast
  
• FortiSIEM CVE-2026-106173: Public PoC Drops, Patch Now
  
• Linux renice Command: 54 Examples to Control CPU Priority
  
• SBI Data Breach Claim: What's Real and What's Not
  
• Linux nice Command: 30 Examples to Protect Your Server CPU
  
• iOS 27.0.1 Untethered Jailbreak Explained: Risk and Fixes
  
• Nextcloud Servers Backdoored: Collabora Flaw CVE-2026-110447
  
• Linux killall Command: 31 Examples & Safe Usage Cheat Sheet

FAQ

Is CVE-2026-114625 being exploited right now?

Yes. Arista's advisory states the issue was detected by Arista and is known to be actively exploited.

Do attackers need valid credentials?

Yes. Exploitation needs a valid authenticated portal session, but the lowest built-in tenant role, Enterprise Read Only, is reportedly sufficient. It does not require an administrator account.

Which versions are fixed?

On-prem VCO 5.2.3.18, 6.1.3.10, and 6.4.2.12, or later releases in each train. Hosted and Dedicated deployments were already patched by Arista.

Are VeloCloud Edge and Gateway affected?

Per the advisory, VeloCloud Gateway and VeloCloud Edge are not affected by this specific vulnerability.

Can I just restrict network access instead of patching?

No. Arista describes network restriction as a temporary safeguard. Upgrading to a fixed release remains the recommended resolution.

If I patched the July or September flaws, am I safe?

Not necessarily. Reporting indicates the releases that fixed those earlier flaws are still older than the new fixed versions, so you need to upgrade again.

Does a patch remove an attacker who is already in?

Not confirmed. The advisory does not say whether upgrading removes access an attacker has already gained, so run the investigation steps in addition to patching.

Conclusion

CVE-2026-114625 is a reminder that "authenticated" does not mean "safe." A read-only dashboard account, the kind nobody thinks about, can be the first domino in taking over an SD-WAN management plane.

Patch on-prem VCO to the fixed release for your train, lock the portal down to trusted networks, preserve your logs, and hunt before assuming you are clean. Many details are still unpublished, including when attacks began and what attackers did afterward, so stay alert for advisory updates.

Found something in your logs, or running VCO in a multi-tenant setup? Share your questions in the comments, and subscribe for fast, practical write-ups on actively exploited vulnerabilities.