Three Exploited Zero-Days in One SD-WAN Orchestrator Since July. The Latest Only Needed a Read-Only Login.

Network security advisories arrive on a schedule. Arista's, published on Thursday, reads like the others: a critical SQL injection, three fixed builds, two IP addresses to block, and a line stating that the flaw is already being exploited.

What makes this one worth more than a skim is the count. It is the third exploited zero-day in VeloCloud Orchestrator since late July, and, by BleepingComputer's tally, the fourth actively exploited Arista flaw this year. The other two in the orchestrator needed no credentials at all. This one needs a login, which sounds like an improvement until you look at which login.

What Arista put in writing

The advisory is unusually direct about the floor. On an affected system, any authenticated user can gain operator privileges and masquerade as a local "superuser operator", and the minimum role required is Enterprise Read Only, the lowest built-in tenant role. The CVSS vector carries PR:L and S:C, low privileges required and a scope change, which is the formal way of saying the attacker starts inside a customer tenant and finishes in control of the host.

The flaw is CWE-89, a SQL injection, tracked internally as BUG2043622. Arista scores it 9.9 on CVSS 3.1 and 9.4 on version 4.0. No user interaction, no second bug, no social engineering. The same section adds something vendors tend to leave out: VCO is exposed by default, and there is no configuration that can prevent the exposure.

Then there is a small wording detail that repays attention. September's advisory says the issue was discovered externally. October's says Arista detected it. The company found its own bug and found it already in use, and the advisory does not say whether that reflects better detection or a longer dwell time.

Three trains, three fixes, and a gap

Patched builds exist on three release trains: 5.2.3.18, 6.1.3.10 and 6.4.2.12. Hosted and Dedicated orchestrators were affected as well, and Arista says those are already patched, which pushes the work onto whoever runs VCO on their own metal. End-of-support releases were not assessed at all, so the advisory's helpful rule that any unlisted release is not vulnerable carries an exception each customer has to work out for themselves.

Now the arithmetic. September's maximum-severity flaw, CVE-2026-93952, was fixed in 5.2.3.16 and 6.4.2.8. Arista's advisory for it, still at revision 1.1 dated 23 September, lists no fixed release for the 6.1 or 7.0 trains and says fixes for other trains will be added over time. As of Thursday it had not been updated. The Hacker News reached the same conclusion the same day, and noted that neither advisory says whether 6.1.3.10 also closes September's hole.

An operator on the 6.1 train therefore faces a version decision the vendor has not settled in public. 6.1.3.10 is the fix for October's bug. It may or may not be the fix for September's. That is a documentation gap more than a code gap, and Arista may well have shipped a 6.1 build for the September flaw without amending the page. But a network team planning a Thursday maintenance window had to guess, and guessing on a CVSS 10.0 is not a comfortable place to be.

Ninety days, and a shrinking clock

The federal record shows how fast these have been moving. CISA added CVE-2026-16812 to the Known Exploited Vulnerabilities catalogue on 27 July with a due date of 30 July. It added CVE-2026-93952 on 22 September, the day Arista published, with a due date of 25 September. Both gave federal civilian agencies three days.

CVE-2026-114625 does not appear in that catalogue as of its 21 October release, which predates the advisory by a day, so the omission reflects timing rather than judgement. Given the pattern, a listing with a similarly short clock is the reasonable expectation, and Rapid7's entry for the CVE already records the KEV field as false.

The indicators tell their own story about what changed. September's advisory named two source addresses, then added a file path, a systemd unit, an MD5 hash and a custom HTTP header, x-vc-opt, to look for in nginx logs. That is the fingerprint of an intrusion that reached the host and stayed. Thursday's advisory names two addresses and then describes behaviour instead: unusual URL-like path components, encoded characters, references to local or internal services, high request rates. The two are 74.82.197.86 and 38.54.50.151.

Read the three together and the detection advice inverts. September's list tells you what to look for after someone has been inside. October's tells you what probing looks like on the way in. Neither says what a successful October compromise leaves behind, and after an operator-level escalation the orchestrator's own audit trail is the first thing an attacker can edit. That last point is inference rather than a vendor statement, but it explains why Arista's guidance points at outbound traffic and backdoor daemons instead of at its own logs.

The account you forgot you issued

The account problem should worry network teams more than the SQL injection does. Enterprise Read Only is not an administrative role. It is the role you hand to somebody who needs to look at dashboards. Arista's description of the account model is that operators create customer and partner accounts, and each partner can manage a group of customers. That structure is why orchestrators accumulate logins. Managed service providers hold them, integrators hold them, auditors hold them, and the ones issued to a partner who has since been replaced rarely get revoked.

Arista's stopgap list reflects that reality. Restricting the web interface to trusted administrative networks is item one, and it is worth saying only because so many deployments do not do it. The exposure note that no VCO setting removes the risk is a polite way of saying the product cannot fix this on the customer's behalf.

What the acquisition included

There is an ownership layer here that is hard to ignore. Arista bought the VeloCloud SD-WAN portfolio from Broadcom, closing on 1 July 2025. Dell'Oro Group's Mauricio Sanchez described it at the time as an asset-plus-talent carve-out: Arista took the intellectual property and roughly half of VeloCloud's thousand or so employees, mostly engineering, while most sales and marketing roles stayed behind. Neither party disclosed terms, and press accounts put the consideration well under a billion dollars.

Sanchez's account of what Arista bought is less flattering than a press release. VeloCloud launched in 2012, built more than 3,700 gateways and reached about 16 percent of SD-WAN revenue by 2020, carried by a service-provider channel that accounted for roughly 70 percent of bookings. Then the market shifted toward SASE, the VMware acquisition spent eighteen months in limbo, and by late 2023 the share had slid toward single digits. Under Broadcom, Sanchez wrote, the platform saw layoffs, a partner re-qualification programme that alienated resellers, and release cycles that lengthened.

None of that is a security finding, and Dell'Oro's assessment is analyst judgement rather than an audit. It does frame the advisory sequence. Arista paid for a production-proven control plane with a large installed base, and took on the maintenance backlog of a product that had spent nearly two years inside a company optimising VMware for cost. Gartner, cited around the deal, put VeloCloud at roughly 21,000 enterprise customers. BleepingComputer describes Arista itself as having more than 10,000 customers. Those are different denominators and should not be swapped or added, but both are large enough that a management-plane bug is an industry event rather than a vendor embarrassment.

The obvious next question is how many of these are reachable from the internet, and nobody has published a defensible count. One researcher ran a ZoomEye query for pages titled VeloCloud on 22 October and got 520 matching assets, then noted that a narrower query for the product name combined with an HTTP service match returned only a handful. The gap between those two numbers does most of the work. 520 counts a product family, including gateway and edge management surfaces that Arista says are not affected by this CVE, and it says nothing about which builds sit below the fixed version. It is a scope indicator, not an exposure census, and treating it as the latter is how bad numbers reach board decks.

Who still has a login

Anyone who assumed the data centre is where the security budget belongs should find this uncomfortable. The orchestrator is not a router. It is a web application with a database behind it, an account model inherited from three owners, and reachability the vendor describes as on by default. Three exploited zero-days in one product in ninety days looks less like bad luck than like a codebase that defenders and attackers started examining in the same quarter, with the attackers getting there first.

The procurement question that follows is not which build to run. It is who holds an account on the system that pushes policy to the branches it manages, when each of those accounts was last reviewed, and whether the interface they log into answers from anything wider than a jump host. For hardware and networking companies absorbing an installed base through acquisition, the same question applies one level up. The security debt of the product you bought arrives with the customers you wanted, and it does not appear on the asset register.

At DMC we work with hardware businesses through exactly this kind of transition, from sourcing and cost modelling to the operational due diligence that tends to get left out of the integration plan. If you are inheriting a management plane, or building one, let's talk.