CVE-2026-16812: a CVSS 10 hole in your SD-WAN control plane

Most weeks the scariest CVE is scary because of what it’s attached to — a database, a CI/CD server, a pile of customer data. This week it’s scarier because of what it’s in front of: the single management plane for an entire SD-WAN fleet. CVE-2026-16812, an unauthenticated OS command injection in Arista’s VeloCloud Orchestrator (VCO) On-Prem, scores a perfect CVSS 10.0, is under active exploitation, and CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of July 30 (CISA). If you run any branch offices, retail sites, or hybrid-cloud links over VeloCloud, this is the one to stop and read carefully.

Root cause

VCO is the web console that operators use to configure and monitor every VeloCloud Edge device in a deployment — think of it as the “cloud console” for your own private SD-WAN. According to Arista’s advisory, the flaw lets “remote attackers access privileged functionality that was intended only for internal use and should not be remotely accessible” (BleepingComputer). In plain terms: some internal-only code path that shells out to the underlying OS is reachable from the external web interface without authentication, and attacker-controlled input reaches that shell call unsanitized. No credentials, no prior access, no user interaction — just network reachability to the VCO web UI is enough to get arbitrary command execution as whatever user the orchestrator process runs as.

The uncomfortable detail from The Register’s coverage is that the exposure is structural: the orchestrator is “exposed by default, with no configuration capable of removing that exposure entirely” (The Register). This isn’t a case of someone forgetting to put the admin panel behind a VPN — On-Prem VCO’s own design assumes some surface has to be internet- reachable for edge devices to phone home to it, and that’s the same surface the vulnerable code path sits on. Arista’s Hosted and Dedicated (SaaS) deployments were already patched before the advisory went public, which narrows this specifically to organizations running their own VCO instance rather than using Arista’s managed service.

Blast radius

This is where CVE-2026-16812 earns the CVSS 10. Compromising VCO doesn’t just hand over one server — it hands over the control plane for every VeloCloud Edge device the orchestrator manages: branch routers, site configurations, routing policy, and the tunnels those edges use to reach each other and the cloud. Arista’s own guidance says exploitation “may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator,” and researchers have flagged the realistic follow-on as attackers using orchestrator access to push malicious configuration to managed edges, effectively turning a single web app bug into a foothold across every site in the WAN. If your VCO manages edges that terminate into a VPC or a colo where your workloads live, that’s the pivot path from “someone popped our SD-WAN console” to “someone is on our network.”

CISA has already observed active exploitation, and researchers have published three IP addresses seen scanning and delivering payloads: 8.19.75.217, 206.72.242.124, and 206.72.242.162. Worth feeding those into your firewall/IDS blocklists today regardless of your patch status — they’re a known-bad signal, not a mitigation on their own.

Remediation

Arista has shipped fixed builds for every affected On-Prem branch:

• 5.2.x → 5.2.3.14
• 6.1.x → 6.1.3.4
• 6.4.x → 6.4.2.4
• 7.0.x → 7.0.0.1

Patch first, but don’t stop there. Because the flaw grants unauthenticated RCE and has apparently been exploited since before public disclosure, Arista’s own advisory goes further than “update and move on” — it recommends rotating credentials, validating that managed edge devices haven’t had unauthorized configuration changes pushed to them, and treating a confirmed-compromised instance as a candidate for restore-from-clean rather than trusting an in-place patch. That’s a strong signal from the vendor that patching alone may not be sufficient remediation if you can’t rule out prior compromise — check orchestrator and edge audit logs for activity around the known-bad IPs above before you consider this closed.

If patching isn’t immediate, restrict the VCO web interface to trusted management networks now. It won’t fully close the hole given how the product’s exposure is architected, but cutting off casual internet scanning buys time, and it’s the same “assume it’s reachable, so fence it” posture you’d want for any management plane with this much downstream reach.

The bigger lesson

The recurring theme this year is that orchestration and management planes — CI/CD servers, RMM consoles, and now SD-WAN orchestrators — are increasingly the preferred target, precisely because compromising one system fans out into control over everything it manages. If you run on-prem management software for infrastructure with real blast radius, the question worth asking isn’t just “is it patched” but “what does an attacker get if this one box falls” — and whether that answer is something you’re comfortable with by design, not just by patch level.