On-Prem VeloCloud Exploit: Read-Only Login Becomes Superuser

Attackers are using an on-prem VeloCloud exploit, CVE-2026-114625 (CVSS 9.9), to turn the lowest-privilege Enterprise Read Only portal account into local superuser on the Arista VeloCloud Orchestrator host. That host runs the SD-WAN management plane for every branch and site it controls. A forgotten login is now the shortest path to the management plane.

What happened: an on-prem VeloCloud exploit that starts with a read-only login

On 26 October 2026, a community alert posted to r/blueteamsec warned that attackers are exploiting CVE-2026-114625 against on-premises Arista VeloCloud Orchestrator (VCO) deployments. The flaw carries a CVSS score of 9.9.

According to the post, an authenticated user with the Enterprise Read Only role, which the alert describes as the lowest-privilege portal role, can escalate to local superuser on the VCO host.

The poster attributes the exploitation report to Arista, which observed attack traffic from two IP addresses. The alert names no threat actor, no victim count and no start date.

VCO is the central management plane for VeloCloud SD-WAN. It configures, monitors and pushes policy to the edge devices that link branches, stores, offices and data centers. If your web servers, CMS admin panels or payment back ends are reached through that fabric, the orchestrator shapes how traffic gets to them. Retail chains and banks often run SD-WAN this way, so one orchestrator can touch many locations.

Does CVE-2026-114625 affect cloud VeloCloud or only on-prem orchestrators?

The alert reports only on-prem VCO deployments as affected and does not mention cloud or SaaS orchestrators. If a provider hosts yours, ask the provider to confirm in writing whether your instance is in scope and when it was patched.

The bug is not described as pre-auth: the attacker needs network access to the portal and a valid session. A login requirement protects you only if you control who gets accounts, how their credentials are protected and who can reach the portal. Read-only access often fails all three: a contractor login left over from a rollout, a shared NOC monitoring account, a password reused from a breached service. Any one hands an attacker the session this exploit needs.

The alert lists no affected or fixed build ranges. Until Arista gives you that information for your branch, treat every on-prem VCO as in scope.

How does a read-only role become local superuser?

The reported chain crosses two security boundaries in one step. Enterprise Read Only governs what a user can view inside the portal. Local superuser means control of the operating system on the server that runs the orchestrator. The attacker does not get promoted inside the portal; they leave the application and take the host beneath it.

The community post does not confirm a root cause. A link shared alongside it points to a CISA Known Exploited Vulnerabilities (KEV) entry titled Arista VeloCloud Orchestrator SQL Injection Vulnerability. SQL injection is a cause: untrusted input interpreted as database commands. Privilege escalation is an outcome. Both labels can describe the same bug.

We see a familiar pattern in pentests: a low-privilege user feeds input into a query that runs with more rights than the role should have. That could fit here, but the KEV title does not say which queries are involved, what database privileges they run with, or how the attacker reached the operating system. Hold off on injection-specific detection rules until Arista publishes the technical chain.

CISA adds entries to KEV on evidence of exploitation. Its Binding Operational Directive 22-01 deadlines bind US federal civilian agencies; everyone else should treat the listing as a priority signal and check the entry’s due date.

What can an attacker change with local superuser on the orchestrator?

In principle, anything the orchestrator can do, plus anything root can do on that host. VCO holds edge configurations, routing and security policy, portal accounts and the management connections to every edge. Root would let an attacker read and alter all of it, create accounts and plant persistence that a portal password reset will not touch.

The source gives no post-exploitation details. Nothing confirms data access, modified edges or lateral movement. If you suspect a hit, scope it as a possible management-plane compromise without assuming damage nobody has shown.

For the sites behind the fabric, the risks are concrete: traffic to your back ends rerouted through paths an attacker controls, internal admin interfaces exposed, locations taken offline. Attackers on network management planes favor quiet persistence, as we saw when a web shell was hidden in F5 BIG-IP memory.

Action plan for CISOs: inventory, patch, account audit

You cannot patch an orchestrator nobody owns, so work in this order:

1. Inventory. List every on-prem VCO instance with its hostname, branch, exact build and who administers it: an in-house team, an MSP or an integrator. Include leftover pilot or lab instances that still have network access. To pin down the build:
   1. Sign in to the Orchestrator portal with an operator-level account and open its version or About information. The location varies by release.
   2. Cross-check that build against your last upgrade record or the installer’s change ticket.
   3. If the records disagree, or nobody can sign in, ask Arista support to confirm the build and the matching fixed release.
2. Patch. Install the fixed VCO release Arista specifies for your branch. The alert names no version number and no workaround, so do not infer either from forum threads.
3. Shrink reachability. Limit the portal to a dedicated admin network or VPN. This cuts exposure until the upgrade; it does not replace it.
4. Audit accounts. Export every portal user and flag Enterprise Read Only, service and shared accounts. Disable anything without a named owner or recent legitimate use; rotate credentials on the rest. The alert stresses that read-only accounts get little scrutiny. If an MSP runs the orchestrator, ask for the raw account export, not a summary. Forgotten accounts are also how attackers find weak logins on ordinary websites.
5. Enforce a second factor. The exploit needs a valid session, so a stolen password alone should not get one. VeloCloud Orchestrator has offered two-factor authentication and single sign-on in past releases; confirm what your build supports and require it for every role, read-only included.
6. Document. Regulated and critical-infrastructure operators should record the inventory, patch date, account review and log-hunt results.

What should you hunt in logs before and after patching?

Start with the two IP addresses attributed to Arista, then widen the search; two indicators are not a detection rule. We do not reproduce the IOCs here. Take them from the original r/blueteamsec post or confirm them with Arista.

• Preserve first. Copy VCO authentication and audit logs, host logs, and relevant VPN, reverse-proxy and firewall logs before patching or credential resets rotate them. Do not delay an emergency patch to finish forensics.
• Go back as far as retention allows. Exploitation may predate the 26 October warning.
• Match the IOCs. For every hit, record timestamp and timezone, source IP, account, session ID and the actions that followed.
• Profile read-only accounts. Look for logins at odd hours, from new sources, or from accounts idle for months.
• Follow the session. Flag read-only sessions followed by role or privilege changes, new accounts, configuration or policy pushes, API activity or edge-management events.

IP indicators are point-in-time, attackers rotate infrastructure, and VPNs or shared proxies blur attribution. A clean IOC search does not prove the orchestrator was untouched.

If you find a hit, resetting the read-only user’s password is not remediation. Treat it as a possible host-level compromise. The alert reports no host artifacts, so these are precautionary checks, not known indicators: new local users, changed privilege configuration, unfamiliar processes, scheduled tasks and added SSH keys. Compare edge configurations against known-good backups, review every account and policy change, and decide whether the host needs a rebuild rather than a cleanup.

What is still unknown about CVE-2026-114625?

Based on the alert, these remain open:

• The CVSS vector string behind the 9.9 score.
• When Arista first saw exploitation, and how widespread it is.
• Whether Arista confirms SQL injection as the root cause.
• The KEV remediation deadline.
• Who is behind the attacks.
• Any detection guidance beyond the two IPs.

Until then: patch to Arista’s fix, remove accounts you cannot justify, and look hard at any unexplained read-only activity.

FAQ

Is CVE-2026-114625 being exploited in the wild?

Yes, according to the 26 October 2026 r/blueteamsec alert, which attributes reports of active exploitation against on-prem VeloCloud Orchestrator, from two IP addresses, to Arista. A separately linked CISA KEV entry also lists the issue.

Do I need a VeloCloud admin account for this attack to work?

No. Per the alert, an authenticated session with the Enterprise Read Only role, the lowest portal privilege, is enough, so a stale, shared or leaked read-only credential would do.

What VCO version should I upgrade to?

The fixed release Arista specifies for your VCO branch. Get the exact build from Arista's official advisory or support channel, not from forum posts.

Does local superuser mean the attacker already changed my SD-WAN edges?

Not necessarily. Superuser on the VCO host would allow it, but the source reports no post-exploitation activity; review configuration, policy and account changes to rule it in or out.

If your sites sit behind a network you no longer fully trust, check the sites themselves too. Our website protection plans add a firewall and continuous malware monitoring, so a change upstream does not go unnoticed downstream.