Arista VeloCloud Orchestrator is under attack for the third time since July. This time a read only login is enough.

Why the SD-WAN orchestrator keeps getting hit

The VeloCloud Orchestrator is the most valuable box in a VeloCloud SD-WAN, and attackers have now found three separate ways into it in 87 days. At that rate, patching each advisory is the floor, not the control. The control is keeping the orchestrator off the network attackers can reach, cutting down who can log in to it, and checking whether one of the first two flaws was already used before the third arrived.

The newest flaw changes the shape of the problem. The first two needed no login at all. CVE-2026-114625 needs one, but only the weakest one the product offers: a tenant account with the Enterprise Read Only role. That sounds like a step backwards for the attacker. It is not. Read only seats are the accounts nobody audits. They get handed to a network operations dashboard, to a managed service provider's junior staff, to an auditor for a quarter, and then they sit there. Arista's advisory says plainly that "VCO is exposed by default" and that "there is no configuration that can prevent the exposure." The only thing between an attacker and operator control is whether they can reach the web interface and find one valid login.

An orchestrator is not just another management console. It is where the configuration for every branch, every edge and every tunnel is written. Whoever controls it can change how the whole wide area network routes traffic, and Arista's own earlier advisories warn that a compromised orchestrator "may allow attackers access to the VeloCloud Edge devices as well." That is why we treat it the way we treat a domain controller or an identity provider: tier zero, reachable only from a hardened administrative path, with every account on it justified.

We have written about the same pattern on the Cisco side this year, when CISA gave federal agencies 48 hours to patch a Cisco SD-WAN authentication bypass. Different vendor, same lesson. The SD-WAN control plane has become a target in its own right, and the attackers working it are patient enough to come back.

What Arista disclosed about CVE-2026-114625

Arista published Security Advisory 0199 on Thursday 22 Oct 2026. It covers VeloCloud Orchestrator On-Prem, the product formerly sold as VeloCloud Orchestrator by Broadcom. The flaw is a SQL injection, CWE-89, and Arista rates it CVSS 9.9 under version 3.1 and 9.4 under version 4.0. The 3.1 vector tells most of the story: network reachable, low attack complexity, low privileges required, no user interaction, and a changed scope with high impact on confidentiality, integrity and availability.

In Arista's words, "any authenticated user can gain operator privileges and masquerade as a local 'superuser operator' user." The precondition is network access to the orchestrator's web interface and a valid authenticated portal session. The minimum role is Enterprise Read Only, which the advisory describes as the lowest built-in tenant role.

Arista found this one itself. The advisory states that "this issue was detected by Arista and is known to be actively exploited." It publishes two source addresses seen in the attacks, 74.82.197.86 and 38.54.50.151, and tells operators to block them and search their logs for them.

CISA added CVE-2026-114625 to the Known Exploited Vulnerabilities catalog on 23 Oct 2026, the day after the advisory, with a federal due date of 26 Oct. Three days. The KEV entry also flags the bug for CISA's forensic triage requirements, which means federal agencies are expected to look for compromise, not only apply the update.

The affected releases are the 5.2 train before 5.2.3.18, the 6.1 train before 6.1.3.10 and the 6.4 train before 6.4.2.12. Arista did not assess end of support versions, and customers on unsupported trains are told to contact its support team about upgrade options. The 7.0 train is not in the affected list for this flaw, and the advisory says a release that is not listed is not vulnerable.

Two scope notes matter for triage. Hosted orchestrators, including Dedicated ones, were affected and Arista says it has already patched them, so the exposure that remains is on premises. And the bug is in the orchestrator only: VeloCloud Gateways and VeloCloud Edges are listed as not affected. That second point is easy to misread. The Edges are not vulnerable to this flaw. They are still downstream of the box that is.

Three exploited VeloCloud Orchestrator flaws in 87 days

Look at the three advisories side by side and the story stops being about one bug.

On 27 Jul 2026, advisory 0144 disclosed CVE-2026-16812, an OS command injection rated CVSS 10.0 that needed no tenant or operator credentials, only network access to the web interface. Arista said it was discovered externally and actively exploited. CISA listed it the same day.

On 22 Sep 2026, advisory 0183 disclosed CVE-2026-93952, an improper input validation flaw rated CVSS 10.0 under version 3.1. It applied where certificate based authentication from the Edge to the orchestrator is configured, again needed no tenant or operator credentials, and was again discovered externally and actively exploited. CISA listed it the same day. At release, fixes existed only for the 5.2 and 6.4 trains, with the others to follow.

Then 0199, 30 days later. Independent reporting from SecurityWeek counts it as the third exploited zero day Arista has patched in the orchestrator in four months, and all three now sit in CISA KEV.

Three things follow from that list.

First, the patch you applied in September does not cover October. An orchestrator moved to 5.2.3.16 for CVE-2026-93952 was doing the right thing and is still exposed to CVE-2026-114625 until it reaches 5.2.3.18. Teams that closed the September ticket and moved on need to reopen it.

Second, the attention is sustained. We cannot tell from public sources whether one group is behind all three, and Arista has not said. What we can say is that someone kept finding and using new ways into the same product, every month or two, through the same web interface. When that happens to a product, the next advisory is a question of when.

Third, the move from unauthenticated to authenticated is not good news. Either the easier doors are closing and the remaining paths need a login, or attackers already hold logins from earlier access. Neither reading lets a defender relax. If an attacker used the July or September flaw to sit on an orchestrator, it had the chance to read or create tenant accounts, and a read only login is exactly what October's bug needs.

How a read only login becomes the whole SD-WAN

To see why Arista and CISA treat this as critical despite the login requirement, follow what each stage gives the attacker. This is the shape of the attack at the level of outcomes, from the advisories, not a recipe.

The step that decides the outcome is the jump from tenant to operator. Arista's operator guide describes the hierarchy: operators sit at the top and create partners, and partners "independently manage a group of Customers." A tenant account belongs to one customer. A superuser operator belongs to the orchestrator. On a shared orchestrator run by a service provider, that jump crosses customer boundaries, which is why the CVSS vector marks the scope as changed.

The second critical step is the fleet. The July and September advisories both say that "compromises to the VCO platform may allow attackers access to the VeloCloud Edge devices as well," and both list post remediation work that "may include credential rotation, review of administrator activity, validation of managed device state, and restoration or replacement of affected orchestrator instances from trusted sources." Arista would not recommend validating every managed device if the orchestrator were an island.

Read that remediation list again. It is the vocabulary of an identity provider compromise, not of a web application bug. That is the right frame.

How to check whether your orchestrator was already used

Patch first, but preserve evidence before you do. Arista's October advisory asks operators who suspect compromise to keep "VCO web access logs, backend application logs," system logs, database logs and the relevant file system timestamps before remediation, where that is operationally possible. An upgrade that overwrites the evidence answers the wrong question.

Then hunt across all three advisories, not only the newest one. If an orchestrator was exposed in July, the October indicators will not tell you about July.

From 0199, look for the two source addresses above, high request rates, and requests with unusual URL like path components, encoded characters, or references to local or internal services. From 0183, look for the files /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond and /etc/systemd/system/vc-sysmon.service, a known malicious file with MD5 dc78e206eaeadec59fc5801fe4556bd0, an x-vc-opt HTTP header in the nginx logs, and the addresses 142.93.149.77 and 104.248.126.159. From 0144, the addresses 8.19.75.217, 206.72.242.124 and 206.72.242.162, plus unexpected outbound traffic, unauthorized configuration changes, and unexpected database exports or archives.

Arista is clear that none of these is a single definitive indicator. Absence of the published addresses proves little, because addresses are the cheapest thing an attacker changes. The behavioural signs carry more weight: an orchestrator talking to the internet on ports it never needed, a new systemd service, an administrator change nobody can account for.

title: VeloCloud Orchestrator access from advisory addresses or with internal references
status: experimental
description: Web requests to an on premises VeloCloud Orchestrator from source addresses Arista published in advisories 0144, 0183 and 0199, or carrying URL like or internal service references that advisory 0199 tells operators to investigate.
logsource:
  category: webserver
detection:
  advisory_sources:
    c-ip:
      - '8.19.75.217'
      - '206.72.242.124'
      - '206.72.242.162'
      - '142.93.149.77'
      - '104.248.126.159'
      - '74.82.197.86'
      - '38.54.50.151'
  internal_references:
    cs-uri-query|contains:
      - 'localhost'
      - '127.0.0.1'
      - 'http://'
      - 'http%3a'
  condition: advisory_sources or internal_references
falsepositives:
  - Integrations that legitimately pass callback URLs in query strings
level: high

The account review matters as much as the logs. List every tenant account on the orchestrator, when it was created, who asked for it, and when it last logged in. Pay particular attention to Enterprise Read Only accounts and to any account created between late July and today. A read only account nobody can explain is now an incident, not a hygiene finding.

How we test an SD-WAN management plane

On a sanctioned engagement, the SD-WAN orchestrator is one of the first things we look for once we have any foothold, and often before. The questions we ask are simple.

Can we reach it? From the internet, from the guest network, from a standard user's laptop, from a branch. Arista's statement that the interface is exposed by default means reachability is a design decision the customer has to make deliberately. It is easy for that decision never to be made, because the orchestrator is often stood up by a network team or a provider whose priority is getting branches online.

Who can log in? We look at how tenant and operator accounts are issued, whether single sign on and MFA cover them, how many read only accounts exist and why, and whether a managed provider's staff hold accounts the customer cannot see or revoke. A read only seat granted for a monitoring wall is, after this week, a credential worth stealing.

What can it reach? An orchestrator needs to talk to its Edges and Gateways and to a short list of services. We check whether its outbound traffic is restricted to that list, because the October advisory's own mitigations include blocking outbound ports not needed for normal operation and watching for backdoor daemons and webshells. If the host can reach anywhere, a foothold on it can reach anywhere.

What would anyone notice? We check whether the orchestrator's logs leave the box, whether anyone reads them, and whether a new administrator, a configuration push to every branch, or a new service on the host would raise an alert. When the honest answer is no, it is usually because the orchestrator sits between the network team and the security team and belongs fully to neither.

None of this needs the vulnerability. We do not need CVE-2026-114625 to show a customer that their orchestrator is reachable from the wrong place by the wrong accounts. The vulnerability only makes the cost of that gap obvious.

What is still coming for SD-WAN orchestrators

Expect more. Three exploited flaws in one product in 87 days says the product has the attention of people who are good at this, and the web interface keeps yielding new paths. The wider pattern is one we tracked in a week where almost none of the exploited bugs touched a core application: attackers keep walking in through the equipment around the applications. SD-WAN controllers, managers and orchestrators sit in the same blind spot as VPN concentrators and firewalls: critical, internet adjacent, run by network teams, and rarely covered by the endpoint tooling security teams rely on.

Expect the fixes to keep lagging the trains. In September, two of the four affected trains had fixes on day one and the rest were promised later. Organisations on a train without a fix are left with network restrictions and monitoring, which is the architecture this post argues for anyway.

Expect the evidence to matter more than the patch. CISA's forensic triage flag on all three entries is a signal of how it reads the risk: a product exploited three times is a product where the default assumption has to be that someone was already inside.

And expect the read only account to become a standard primitive. Once an authenticated flaw like this is public, every tenant credential on every exposed orchestrator has a new value. Phishing kits, infostealer logs and old provider accounts all become sources. The cheapest defence is the one that makes those credentials worthless: an orchestrator that cannot be reached from where the attacker stands.