CRITICAL: Arista VeloCloud Orchestrator CVSS 10.0 Flaw Exploited in the Wild

Pour one out for anyone running VeloCloud Orchestrator on their own hardware, because the past few days have not been kind.

Arista published Security Advisory 0144 covering CVE-2026-16812, an operating system command injection flaw in on-premises VeloCloud Orchestrator that carries a CVSS score of 10.0 under both the 3.1 and 4.0 scoring systems. That is not a 9.8 that somebody argued up into a perfect ten. The vector string reads AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which in plain English means an attacker reaches it over the network, the attack is easy, no privileges are required, no user has to click anything, the scope changes because the damage spills past the vulnerable component, and confidentiality, integrity, and availability all take a full hit. There is no worse combination available. The scoring system is literally incapable of expressing anything more severe.

Then there is the part that turns a bad Tuesday into a long week. Arista's own advisory states that the issue "was discovered externally and is known to be actively exploited." Translation for anyone who has sat in a war room at two in the morning, somebody found this before the vendor did and has been putting it to work. CISA agreed and added the CVE to the Known Exploited Vulnerabilities catalog, giving federal civilian agencies until July 30, 2026 to patch. When CISA hands you a three day clock on a management platform, that is not a gentle nudge.

What actually broke

VeloCloud Orchestrator is the brain of a VeloCloud SD-WAN deployment. It is where you define policy, push configuration, manage tenants, and watch the health of every Edge appliance in the estate. The product came to Arista by way of the Broadcom sale, and its role has not changed. It remains the single management plane that a service provider or a distributed enterprise uses to run a wide area network across dozens or hundreds of sites.

The flaw itself is textbook CWE-78. Internal functionality in the orchestrator accepts input that ends up inside an operating system command on the VCO host without adequate sanitization. Arista's phrasing on this point is worth quoting, because it is the entire story compressed into one sentence. "This functionality was intended for internal use only and is not intended to be remotely accessible." That is the bug. A privileged internal interface turned out to be reachable from outside, and reaching it requires no tenant credentials, no operator credentials, and no authentication of any kind.

Once an attacker has command execution on the orchestrator host, the blast radius does not politely stop at the orchestrator. Arista is direct about the downstream risk, warning that compromises to the VCO platform may allow attackers access to the VeloCloud Edge devices as well. Sit with that for a second. The orchestrator holds tenant configurations, credentials, certificates, and the trust relationship with every Edge appliance under its management. An attacker who owns it does not have to compromise your branch offices one at a time. They can push configuration, alter routing, and pivot into the networks those Edges terminate.

This is the management plane problem, and it is the reason SD-WAN controllers, VPN concentrators, and remote monitoring platforms keep turning up on the KEV list with depressing regularity. Attackers worked out years ago that the fastest route into a hundred networks is the one console that already has access to a hundred networks. Everything about that console is attractive to them. It is internet facing by design in far too many deployments, it is trusted implicitly by everything downstream, it is rarely covered by endpoint detection, and it tends to be patched on the same leisurely schedule as everything else in the network closet. Edge and management infrastructure has quietly become the most valuable real estate in enterprise security, and the people breaking into it noticed well before most of the people defending it did.

Who needs to move and how fast

Only on-premises deployments are affected. Arista pre-patched the Hosted and Dedicated versions of VeloCloud Orchestrator, so if your instance lives in Arista's cloud you are already covered and you can go back to your coffee. Everybody running their own VCO needs to go look at a version number right now.

The 5.2 branch is vulnerable in any release before 5.2.3.14. The 6.1 branch is vulnerable before 6.1.3.4. The 6.4 branch is vulnerable before 6.4.2.4. The 7.0 branch is vulnerable before 7.0.0.1. Arista shipped fixes across all four branches, which tells you the flawed code has been sitting in the product across a long stretch of release history. There is no partial credit on this one. If you are running anything below the fixed release for your branch, assume you are exposed, and treat the host as a candidate for compromise until you have evidence otherwise.

If you genuinely cannot patch before the next maintenance window, the fallback is network control. Restrict the VCO web interface to trusted administrative networks and nothing else. A management plane for your entire wide area network has no business being reachable from the open internet, and the fact that a vendor advisory needed to spell that out tells you roughly how many of them are. Beyond that, watch outbound traffic from the VCO host, because an orchestrator that suddenly starts making connections it has never made before is trying to tell you something.

Detection and cleanup

Arista published three IP addresses tied to observed attacks, 8.19.75.217, 206.72.242.124, and 206.72.242.162. Run those against your web access logs, firewall logs, and netflow. Finding them is meaningful and should trigger an incident. Not finding them means very little, because an indicator list attached to an advisory is always a subset of reality, and rotating infrastructure costs an attacker close to nothing.

The behavioral guidance ages better. Arista recommends reviewing VCO web access logs for unusual URL like path components, encoded characters, references to local or internal services, and abnormally high request rates. Command injection against a web endpoint tends to look genuinely ugly in the logs, assuming anyone is reading them. On the host itself, hunt for unexpected command execution, database exports nobody authorized, and any access to stored credentials or certificates. Then pull the administrator activity logs and read them properly, because a freshly created operator account or a quietly modified policy is exactly the kind of change that hides in plain sight for months.

If you find anything, understand that patching is step one of an incident response rather than the end of one. An orchestrator that was compromised before the patch stays compromised after it, because the attacker's access no longer depends on the vulnerability that got them in. Rotate the credentials and certificates the platform holds, audit every Edge device it manages, review tenant configurations for unauthorized changes, and work on the assumption that the intruder had free run of the management plane for as long as the box sat exposed. That is an unpleasant scope to accept, and it is far less unpleasant than discovering six months later that you patched the front door while somebody was still living in the basement.

The uncomfortable footnote here is that nobody outside Arista knows how long this was being exploited before the advisory landed. The company acknowledged external discovery without disclosing a timeline or a customer count, which is standard practice and also cold comfort. If your VCO has been internet facing for the past year, the honest position is that you do not know what happened on it, and the only way to change that is to go look.

The MSP angle

Emergency patching of a KEV listed CVSS 10.0 flaw sitting in a client's network management plane is the single cleanest justification for a managed vulnerability and patch program that you will get all quarter, and the federal three day deadline gives you an external reference point for the client who wants to know why it cannot wait until next month. The natural follow-on sale is external attack surface monitoring, because the underlying failure was an administrative interface being reachable from the internet, and most clients have no idea what of theirs is exposed until somebody puts a report with their own IP addresses in front of them.