CVE-2026-16812: Arista VeloCloud's Perfect-10 Command Injection, and How to Patch It

If your organization runs an on-prem Arista VeloCloud Orchestrator to manage its SD-WAN, stop and check the version number before reading further. CISA added CVE-2026-16812 to its Known Exploited Vulnerabilities catalog on July 27. It’s an unauthenticated OS command injection scored a full 10.0 on CVSS, the ceiling of the scale, and it’s already being used in live attacks.

What the bug actually does

VeloCloud Orchestrator, VCO for short, is the management plane that sits above VeloCloud’s SD-WAN edge devices. It’s where an operator configures policy, pushes changes, and monitors every branch office the deployment covers. That central position is exactly why this bug is bad: VCO isn’t one branch’s router, it’s the console that controls all of them.

CVE-2026-16812 lets a remote, unauthenticated attacker execute operating system commands directly on the orchestrator host. No tenant login, no operator credentials, nothing. Arista’s own advisory notes that the vulnerable functionality was originally built for internal use only and was never supposed to be reachable from outside, but it stayed remotely accessible anyway. That’s a common failure shape in management software: a debug endpoint or internal API that assumes network position is the security boundary, and then the network position changes, or was never as isolated as the design assumed.

Successful exploitation compromises the confidentiality, integrity, and availability of the orchestrator itself and everything it manages. Practically, that means an attacker with a foothold on VCO can read and rewrite SD-WAN configuration, intercept or redirect traffic policy, and pivot toward whatever the orchestrator’s network position gives it access to.

Who’s affected and what’s already fixed

The exposure is specific to on-prem, self-managed VCO deployments:

Deployment type	Status
On-prem VCO, unpatched	Vulnerable
On-prem VCO, patched	Fixed
VeloCloud Hosted / Dedicated	Already patched by Arista before the advisory; not exposed
VeloCloud Gateway	Not affected
VeloCloud Edge	Not affected

If you manage your own VCO instance, the fix is versions 5.2.3.14, 6.1.3.4, or 6.4.2.4 depending on which branch you’re on, or any 7.0.0.1-or-later release, since the 7.x line was never vulnerable to this particular flaw. Arista discovered the issue through an external report rather than internal testing, and hasn’t published attribution or a detailed timeline of when exploitation began, which is itself worth noting: the absence of a clean “exploitation started on this date” line usually means the vendor is still reconstructing what happened, not that the risk window was short.

# Check your current VCO build against the fixed floors:
# 5.x branch -> needs 5.2.3.14+
# 6.1 branch -> needs 6.1.3.4+
# 6.4 branch -> needs 6.4.2.4+
# 7.x branch -> any 7.0.0.1+ release is unaffected

If your VCO is internet-facing at all, and a meaningful number of on-prem SD-WAN orchestrators are, treat patching as urgent rather than routine. An unauthenticated, full-compromise bug on a system with this much blast radius is close to the worst combination the KEV catalog sees.

The Fortinet bug that landed the same day

CISA’s July 27 update wasn’t only about Arista. It also added CVE-2025-68686, an information-disclosure flaw in Fortinet FortiOS that exposes sensitive data to an unauthorized actor. The two are unrelated products from different vendors, but the Fortinet one comes with a catch worth knowing: exploiting it requires the attacker to already have filesystem-level access to the device, meaning it’s a post-exploitation flaw, not an initial-access one. It’s a patch bypass for a symbolic-link persistence mechanism that Fortinet had previously tried to close. If you’re running FortiOS 7.6.0 through 7.6.1, 7.4.0 through 7.4.6, or any 7.2, 7.0, or 6.4 release, and you have any reason to suspect prior compromise on a FortiOS device, this is the flaw an attacker would use to keep sensitive data flowing even after the original entry point gets cleaned up.

Why the federal deadline math changed

Older KEV advisories, including the Langflow authorization bypass we covered earlier this month, operated under a flat deadline: every KEV addition got the same fixed remediation window for federal civilian agencies, regardless of how severe or exposed the specific bug was. That policy, BOD 22-01, has been replaced by BOD 26-04, which scores each KEV addition against four criteria, including whether the affected system is publicly exposed and whether successful exploitation grants full control of the asset, and sets a deadline accordingly. For a bug like CVE-2026-16812, unauthenticated, internet-reachable in many deployments, and a full command-injection compromise, that scoring can produce a remediation window as short as three days.

You don’t have to be a federal agency for that scoring model to be useful. It’s a reasonable way to triage your own patch queue: ask the same four questions BOD 26-04 asks, and the vulnerabilities that would score worst under it are the ones that deserve your team’s attention this week, not next sprint.

What to do this week

Check your VCO version against the fixed floors above and patch if you’re behind. If patching has to wait even a few days, pull the orchestrator off any network path that doesn’t strictly need to reach it, and review access logs for command execution or configuration changes you can’t account for. This is not a bug where “we’ll get to it next patch cycle” is a defensible position, and the KEV listing exists precisely to tell you that.