Your WAN orchestrator is on the internet by design: VeloCloud's 10.0

On 27 July, Arista published its security advisory 0144. Inside is CVE-2026-16812, a CVSS 10.0: operating-system command injection in the VeloCloud Orchestrator, with no credentials of any kind, and already being exploited when the patch shipped. CISA added it to its exploited-vulnerabilities catalogue the same day, with a federal deadline of 30 July: three days. But the score is not what made us look up. It is a line in the advisory itself, put bluntly: "VCO is exposed by default. There is no configuration that can prevent the exposure."

An SD-WAN orchestrator is the central console from which the kit at every one of a company's sites is configured, watched and updated. It is, quite literally, where the full drawing of your network lives: what leaves over which line, which tunnel lands where, which policy applies at each branch. That concentration is exactly what you buy when you buy SD-WAN, and exactly what is carrying a 10.0 today.

What the flaw is, and who it lands on

The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, and it is worth reading in full because it explains the score. Network attack, low complexity, no prior privileges and no user interaction; the trailing S:C marks a scope change, meaning the impact leaves the vulnerable component behind. All an attacker needs is network reach to the orchestrator's web interface: no tenant or operator credentials required. Arista scores it 10.0 on CVSS v4.0 as well.

It affects the on-premises versions of the orchestrator: the 5.2.x branch before 5.2.3.14, 6.1.x before 6.1.3.4, 6.4.x before 6.4.2.4 and 7.0.x before 7.0.0.1. Edges and gateways are not themselves vulnerable, with one important caveat: compromising the orchestrator can open the door to the edges it manages. Arista also says two things that deserve credit and are not always found in an advisory: that the flaw was discovered externally and is known to be actively exploited, and it publishes three IP addresses seen attacking (8.19.75.217, 206.72.242.124 and 206.72.242.162). What we have not seen it say is since when, or how many customers were reached.

"Exposed by default" is not sloppiness: it is the deal

The first reaction of anyone with two decades of networking behind them is to ask what on earth that is doing on the internet. The answer is uncomfortable because it is reasonable: it has to be there for the edges to find it. The kit at each site calls home from wherever it is and over whatever transport exists, which is often a consumer fibre line ordered last week. Zero-touch provisioning, the thing that saves you sending somebody to a branch 300 kilometres away, consists precisely of a device fresh out of the box finding its orchestrator on its own. An orchestrator hidden behind the corporate VPN cannot welcome a site that does not have the VPN yet.

Whether the admin console has to be just as open is another matter, and here the advisory is more useful than it first looks. On the same page, under mitigation, Arista recommends restricting access to the VCO web interface to trusted administrative networks, watching for access from the known IPs, watching for unexpected outbound traffic from the host, and reviewing recent administrator activity. And the description of the flaw makes clear the attack requires network access to that web interface. These are two different surfaces — the channel your sites use to activate their kit, and the panel where configuration gets changed — and only one of them has to be open to everybody. The vendor's "by default" is only a starting point, and almost nobody moves it.

Even so, the property that makes the product useful and the one that puts it in CISA's catalogue today remain the same. In the brochure that gets sold as a single console for all your sites. In the security advisory it is described as something that "may compromise the confidentiality, integrity and availability of the orchestrator and data managed by the orchestrator". One property told by two different departments, and both versions are true.

To be clear, because two days ago we published the opposite of a sales pitch: this is not an argument against SD-WAN. When we set out when it pays off and when it is overkill we already listed the orchestrator among the costs that never show up in the demo, and there it stays. A deployment with many changing sites is not governed by hand, and the day a line drops you are glad a machine decides the per-application steering. What does not add up is buying the centralisation without looking at what happens the day somebody gets into it.

The vendor's cloud was already patched

There is a line in the advisory you read in two seconds that says a great deal: "Hosted and Dedicated versions of VCO have already been patched in advance of this notice going out." In other words, the instance the vendor operates was covered while the rest of the world was finding out. We think that is the logical order and it is what we would do with our own platform: first you close what is under your control, then you tell people.

But if your orchestrator is on-premises, that line deserves a minute. During that window, the instance you kept to stay in control was the only one with the hole open, and you did not set the clock. Beware the easy conclusion of moving everything to the vendor's managed service: there you gain patching speed and lose maintenance windows, visibility and any say over where your data lives, and you keep the same problem for the day the service itself is the thing compromised. The point is simpler and rather more uncomfortable. "Self-managed" is a term that reads like freedom in the contract and means an on-call rota on a Monday in July. We choose on-premises often and we defend it; we only ask that next to that decision somebody writes down who patches, how fast, and whose permission they need.

Three days, and the catalogue tells you the order

That deadline only binds the US administration; a company in Sant Fruitós or Terrassa can ignore it. It still helps: it saves you the argument about whether this is urgent, because somebody has already had it on your behalf and with better data. And comparing the two deadlines issued on the same day is a free lesson in prioritisation. CISA sorts by real-world exploitation and exposure, which is precisely what the score does not measure.

The useful question, then, is how long you take and who can do it without calling a meeting. If the honest answer is "depends who is on holiday this week", that is the finding of the day, and it is worth considerably more than the patch.

If it was exposed, the patch does not close the incident

Updating to the fixed release comes first. What comes after is the part almost nobody does: when a flaw is exploited before a patch exists, updating only guarantees nobody else comes in that way, and says nothing about who came through earlier. The advisory helps more than most do here. It asks you to preserve the VCO web access logs, application logs, system logs and database logs before remediating, and to look in them for odd path components, encoded characters, high request rates, unexpected outbound traffic from the host, command execution, file creation or database exports, and configuration changes that match no administrator activity. On top of that: search the three published addresses in the orchestrator's and the perimeter's logs, review operator and tenant accounts created or modified in recent weeks, and rotate credentials, API keys and certificates the orchestrator holds in order to talk to the edges. With the same criterion we apply to the zero-days in a perimeter VPN appliance: kit that sits at the edge gets reviewed on the assumption somebody tried.

And the ugly part needs saying: it is useful guidance, but there are no hashes and no signatures, so finding nothing proves nothing either. It is also worth being precise about what exactly you lose if the orchestrator was in someone else's hands. It is not the outage, which there probably was not: it is that the topology of your multi-site network, its policies and its credentials become information somebody else holds. No backup restores that, and it does not expire when you patch.

Who answers for that console

The product in question, incidentally, has changed hands three times: VMware bought VeloCloud in 2017, Broadcom inherited it when it bought VMware, and in July 2025 Arista closed the purchase of the SD-WAN business from Broadcom. Meanwhile, the on-premises instances have carried on in the same cabinet as always. We bring it up because it explains why in many companies the question "who answers for this platform?" has an answer that has already expired three times. The pattern repeats beyond this case: four days ago we were writing about another management console, and the script was the same.

So when we review a network we did not design ourselves, there are four things we always ask, none of which requires buying anything: what each console genuinely exposes to the internet and why it has to; who can get into it, from where, and with which second factor; whether a new account or a configuration change raises an alert somebody reads the same day; and how many hours it takes to apply a critical patch on one person's decision. Centralisation is not the problem. The problem is having it and never having looked it in the face.

Sources (verified): CVE-2026-16812, CVSS v3.1 10.0 (vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and CVSS v4.0 10.0, affected and fixed versions, Hosted and Dedicated versions already patched ahead of the notice, exposure by default with no configuration to prevent it, mitigation (restrict the web interface to trusted administrative networks, monitor access and outbound traffic, review administrator activity), log preservation and review guidance, the requirement of network access to the web interface, no need for tenant or operator credentials, possible access to managed VeloCloud Edge devices, active exploitation and the three IPs: Arista, Security Advisory 0144, 27 Jul 2026. KEV listing on 27 Jul 2026 with a 30 Jul 2026 deadline under directive BOD 26-04, plus FortiOS CVE-2025-68686 due 10 Aug 2026 (the catalogue publishes no CVSS score): CISA, Known Exploited Vulnerabilities Catalog. Score for CVE-2025-68686: 5.9 base in NVD (source Fortinet PSIRT), 5.3 with temporal metrics in the vendor advisory. Coverage and cross-confirmation: BleepingComputer and The Hacker News. VeloCloud, founded in 2012, ended up in VMware and from there in Broadcom; in July 2025 Arista closed the purchase of the SD-WAN business: RCR Wireless, 2 Jul 2025. The review criteria and the four questions are ours.