Am I vulnerable?
CVE-2026-16812 is an unauthenticated OS command injection flaw (CWE-78) in Arista Networks VeloCloud Orchestrator On-Prem, the management and control plane for VeloCloud SD-WAN. NVD scores it 10.0 under both CVSS v3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and CVSS v4.0 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/S:P). Arista published the advisory and the fixes on the same day, 27 July 2026, and states the flaw was discovered externally and is known to be actively exploited. CISA added it to the KEV catalog that day with a remediation deadline of 30 July 2026, one of the shortest clocks it has issued.
The exploitation precondition is network access to the VCO web interface. No tenant credentials, no operator credentials, no user interaction, and no special configuration are required. Arista is explicit that there is no config-only fix: "VCO is exposed by default. There is no configuration that can prevent the exposure."
Only the On-Prem Orchestrator is in scope. Arista states that Hosted and Dedicated Orchestrators it operates were patched ahead of disclosure, and that VeloCloud Edge and VeloCloud Gateway are not affected.
Affected and fixed versions
| Release train |
Vulnerable |
Fixed in |
| VCO On-Prem 5.2 |
5.2.0 up to and including 5.2.3.13 |
5.2.3.14 |
| VCO On-Prem 6.1 |
6.1.0 up to and including 6.1.3.3 |
6.1.3.4 |
| VCO On-Prem 6.4 |
6.4.0 up to and including 6.4.2.3 |
6.4.2.4 |
| VCO On-Prem 7.0 |
7.0.0 |
7.0.0.1 |
Orchestrators on unsupported release trains have no fixed build to move to; Arista directs those operators to contact TAC about upgrade paths.
Diagnostic checks (read-only)
- Orchestrator version, web UI (vendor-documented): log in as Operator, click the Help icon at the top right, then select About. Compare the reported build against the table above. This is the fastest check when you do not have appliance shell access.
- Orchestrator version, appliance shell (vendor-documented):
dpkg -l | grep vco. The VCO On-Prem appliance is Ubuntu-based. Any vco-* package below the fixed build for its train is vulnerable.
- External reachability: from an untrusted vantage point,
curl -4 -sk -o /dev/null -w '%{http_code}\n' --max-time 10 https://<vco-fqdn>/. Any HTTP response from outside your administrative network means the interface is externally reachable, which is the entire barrier to exploitation.
- Vendor-published attacker IPs: Arista names three source addresses it observed conducting attacks:
8.19.75.217, 206.72.242.124, 206.72.242.162. Search your logs for them: sudo grep -rE '8\.19\.75\.217|206\.72\.242\.124|206\.72\.242\.162' /var/log/ 2>/dev/null | head -50. Arista documents the Portal, Upload and Backend application logs at /var/log/{portal,upload,backend}/velocloud.log.
Absence of hits is not clearance. Arista states directly that there is no single definitive indicator of compromise for this issue, and those three addresses are only the sources it happened to observe.
Vulnerability
The flaw sits in internal Orchestrator functionality that was not intended to be reachable from outside the appliance. An unauthenticated request that reaches that functionality results in operating system command execution on the Orchestrator host with elevated privileges. Arista's CNA record classifies it as CWE-78 and CAPEC-88, OS Command Injection. Neither the vulnerable endpoint nor the injected parameter has been made public, and no public exploit code, PoC repository or scanner template had surfaced as of 29 July 2026.
Two scoring details are worth reading closely. The CVSS v4.0 vector carries S:P (Safety: Present) with subsequent-system confidentiality, integrity and availability all rated High. That is the scoring model saying the Orchestrator itself is not the endpoint of the compromise. CISA's SSVC vulnrichment records Exploitation: active, Automatable: yes, Technical Impact: total, which is the maximum-urgency combination and the machine-readable statement that this is mass-exploitable rather than a targeted-only concern.
Set the EPSS score aside. It reads 0.0098 for this CVE, which reflects a model with almost no data on a vulnerability five days old, not a low likelihood of exploitation. KEV listing already confirms exploitation in the wild.
As of 29 July 2026 no security firm had published independent technical analysis. Searches across Mandiant, watchTowr, GreyNoise, Rapid7, Tenable, Sophos, CrowdStrike and Arctic Wolf returned nothing on this CVE. The vendor advisory is the only primary technical source; the trade press coverage listed in References adds the fixed-build matrix and defender guidance but no independent research.
Threat model
Who would exploit this: the operator set splits by phase. Before disclosure this was a zero-day against an internet-facing SD-WAN management plane, which fits a resourced, targeted actor. State-aligned espionage groups and top-tier initial-access brokers both favour edge and management appliances precisely because those hosts rarely carry EDR telemetry and hold credentials for everything downstream. After the 27 July KEV listing, expect the usual commodity wave: mass scanning by ransomware affiliates and access brokers working a now well-signposted unauthenticated bug. Insider risk is largely beside the point here, since the flaw needs no credentials at all.
What they are after:
- Foothold: privileged command execution on the Orchestrator host
- Persistence on a low-telemetry management appliance
- Credential and key material theft: tenant and operator credentials, certificates, tunnel key material
- Lateral movement from the control plane into the managed Edge fleet and the branch networks behind it
- Data exfiltration: database exports, device inventory, full network topology and policy configuration
- Access brokerage or ransomware staging, particularly against MSP orchestrators where one host reaches many customer tenants
Attack chain: an attacker locates an internet-reachable VCO On-Prem web interface, which Arista states is exposed by default, then sends a crafted request that reaches privileged internal functionality never intended for external callers. That request yields OS command execution on the host as a privileged service account with no credentials involved. The typical progression from there is to establish persistence, harvest the Orchestrator database and stored secrets, then pivot outward using the Orchestrator's legitimate management relationships with the Edge fleet. Arista's own indicator list points at that shape: unusual encoded path components in web access logs, unexpected outbound HTTP or HTTPS from the VCO host, unauthorised configuration changes, database exports, and unexpected file creation.
Blast radius: a compromised VCO is a compromise of the SD-WAN control plane, not of a single server. Arista's advisory warns that Orchestrator compromise may extend to the managed VeloCloud Edge devices, and directs defenders to hunt for access to device inventory, configurations, certificates, credentials and key material. Concretely, that means the Orchestrator database and its stored tenant and operator credentials, the certificates underpinning Edge tunnels, and the ability to push configuration and policy to every managed Edge appliance, which converts control-plane access into traffic redirection, routing and firewall policy change, or connectivity loss across a branch estate. In an MSP or service-provider deployment the same host fronts many customer tenants, so one Orchestrator becomes multi-customer exposure.
No actor, group or campaign has been publicly named. Arista, CISA and every outlet covering the disclosure decline to attribute it.
Mitigation
Patch
Upgrade to the fixed build for your train. Arista's Resolution section lists 5.2.3.14, 6.1.3.4 and 6.4.2.4 explicitly; the 7.0.0.1 fixed build is derived from the CVE record's affected range and is reported consistently across trade coverage.
| Train |
Upgrade to |
| 5.2 |
5.2.3.14 or later |
| 6.1 |
6.1.3.4 or later |
| 6.4 |
6.4.2.4 or later |
| 7.0 |
7.0.0.1 or later |
Patching alone does not close the incident. Arista's guidance is to preserve VCO web access logs, backend application logs, system logs, database logs and relevant filesystem timestamps before remediating where operationally feasible, then rotate credentials, review administrator activity for unexpected changes, and validate the state of managed Edge devices. CISA's required action invokes its Forensics Triage Requirements, so federal operators must triage for compromise, not merely patch.
Configuration mitigation
Arista publishes no configuration snippet, ACL syntax or CLI flag, and states plainly that no configuration removes the exposure. What follows is generic defence-in-depth to buy time until the fixed build is deployed, not a vendor workaround.
Review current exposure and restrict the admin path (read-only inspection first):
# Inspect what is currently permitted on the appliance
sudo iptables -S | grep -E ' --dport (80|443) '
sudo nft list ruleset 2>/dev/null | head -50
# Allow-list shape, applied on the upstream firewall rather than the appliance:
# permit tcp <admin-subnet> any eq 443
# deny tcp any any eq 443
#
# WARNING: VeloCloud Edges must reach the Orchestrator for management and
# heartbeat. Blanket-blocking 443 will break SD-WAN management. Scope the
# allow-list to the administrative UI path and confirm Edge reachability after.
Check for contact from the vendor-published attacker IPs:
for ip in 8.19.75.217 206.72.242.124 206.72.242.162; do
echo "== $ip =="
sudo grep -rF "$ip" /var/log/ 2>/dev/null | head -20
done
Compensating controls
- Treat any unpatched, internet-reachable Orchestrator as presumed compromised until log review says otherwise, given confirmed in-the-wild exploitation since at least 27 July.
- Rotate operator and tenant credentials, and reissue certificates and tunnel key material, on any instance that was reachable while unpatched. The advisory names these as the data at risk.
- Validate managed Edge configuration and policy against a known-good baseline. The Orchestrator's legitimate push capability is the attacker's lateral-movement path.
- Monitor Orchestrator egress. A VCO that starts acting as an HTTP client toward address space that is neither Arista infrastructure nor your own Edge estate is the highest-value signal available on a host with little other telemetry.
- MSP and service-provider operators should assume tenant-boundary crossing and scope incident response across all tenants fronted by the affected Orchestrator, not just the one that reported an anomaly.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.
No vendor-supplied Sigma rule, detection regex or compromise-assessment script exists for this CVE. Arista names log categories but publishes no file paths. The rules below key on behaviour rather than on any request signature, so they survive not knowing the vulnerable endpoint.
Network and log signals
- Unauthenticated requests on 443 whose URL, query string or body carries shell metacharacters or their percent-encoded forms (
;, |, backtick, $(, &&, %3B, %7C, %60), path traversal, or double encoding, arriving from outside the management network. Correlate the nginx layer with the Portal, Upload and Backend logs at /var/log/{portal,upload,backend}/velocloud.log.
- Bursts of GET and POST probing from a single source, or requests reaching privileged functionality with no preceding authenticated session in the Portal log.
- Web and API tier processes (nginx, the Node.js Portal, Upload and Backend services) spawning shell interpreters or network tooling:
sh, bash, python3, perl, curl, wget, nc, ncat, socat. On a healthy Orchestrator the only shells under the web tier come from vendor maintenance, so parentage is the highest-fidelity pivot available.
- Outbound connections from the Orchestrator to address space that is neither Arista update or telemetry infrastructure nor your own Edge and Gateway estate, especially on high or uncommon ports, or plain HTTP.
- New or recently modified files under
/opt/vc/, /var/lib/velocloud/ and the static web root, plus new executables under /tmp, /var/tmp and /dev/shm. Diff against the package manifest rather than eyeballing timestamps.
- New persistence: unit files under
/etc/systemd/system, entries in /etc/cron.* or /var/spool/cron/crontabs/, new authorized_keys for vcadmin or root, new local accounts or additional UID 0 entries.
- Credential and data staging: unexpected reads of
/etc/mysql/velocloud.cnf or the TLS private keys under /etc/nginx/velocloud/ssl/, unscheduled mysqldump activity, archive creation in world-writable directories followed by a large outbound transfer. Also watch for truncated or zeroed log files and timeline gaps.
YARA
rule VCO_OnPrem_PostExploit_Dropper_Or_Webshell
{
meta:
description = "Starter behavioural rule for post-exploitation staging artifacts (remote droppers, reverse shells, small command-relay webshells) on a VeloCloud Orchestrator On-Prem host following OS command injection"
reference = "CVE-2026-16812"
author = "CVE Brief"
date = "2026-07-29"
confidence = "medium"
note = "AI-generated starter rule, validate in your environment before deploying. Contains no CVE-specific hashes and no exploit payload. It matches generic attacker tooling and will also match legitimate vendor and administrator scripts, so scope it to writable and web-served directories and to captured request payloads."
scope = "Scan the VCO web root, /opt/vc, /var/lib/velocloud, /tmp, /var/tmp, /dev/shm, and any captured HTTP request bodies. Do not scan the whole filesystem without tuning."
strings:
// remote stage-and-execute chains
$dl1 = "curl " ascii nocase
$dl2 = "wget " ascii nocase
$dl3 = "fetch -o" ascii nocase
$pipe1 = "|sh" ascii
$pipe2 = "| sh" ascii
$pipe3 = "|bash" ascii
$pipe4 = "| bash" ascii
$pipe5 = "|python" ascii
$pipe6 = "| python" ascii
$b64a = "base64 -d" ascii
$b64b = "base64 --decode" ascii
// reverse shell and TTY upgrade scaffolding
$rs1 = "/dev/tcp/" ascii
$rs2 = "pty.spawn" ascii
$rs3 = "SOCK_STREAM" ascii
$rs4 = "nc -e" ascii
$rs5 = "ncat --exec" ascii
$rs6 = "socat" ascii nocase
$rs7 = "sh -i" ascii
$rs8 = "dup2(" ascii
// generic command-relay / webshell constructs (multi-language)
$ws1 = "child_process" ascii
$ws2 = "shell_exec" ascii
$ws3 = "passthru(" ascii
$ws4 = "os.system" ascii
$ws5 = "subprocess.Popen" ascii
$ws6 = "proc_open" ascii
$ws7 = "execSync" ascii
// request-derived input reaching those constructs
$p1 = "$_REQUEST[" ascii
$p2 = "$_POST[" ascii
$p3 = "$_GET[" ascii
$p4 = "req.query" ascii
$p5 = "req.body" ascii
$p6 = "QUERY_STRING" ascii
// host-level persistence written by a dropper
$per1 = "authorized_keys" ascii
$per2 = "/etc/systemd/system/" ascii
$per3 = "/var/spool/cron/crontabs/" ascii
condition:
filesize < 512KB
and (
( any of ($dl*) and any of ($pipe*) )
or ( any of ($b64a, $b64b) and any of ($pipe*) )
or ( 2 of ($rs*) )
or ( any of ($ws*) and any of ($p*) )
or ( any of ($dl*) and any of ($per*) and any of ($pipe*) )
)
}
Sigma
title: Shell or Network Tool Spawned by VeloCloud Orchestrator Web Tier
id: 6f3b1c8a-2d47-4e19-9b0c-5a7c8d21f4e3
status: experimental
description: |
Detects a shell interpreter, download utility or network tool spawned as a child of the VeloCloud
Orchestrator On-Prem web and API tier (nginx and the Node.js Portal, Upload and Backend services).
Unauthenticated OS command injection in VCO On-Prem (CVE-2026-16812, CVSS 4.0 10.0, CISA KEV,
exploited in the wild as of 2026-07-27) executes commands with elevated privileges on the
orchestrator host, and the first host-side observable is normally an unexpected child process under
the web tier. AI-generated starter rule, validate in your environment before deploying.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-16812
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- https://www.arista.com/en/support/advisories-notices
author: CVE Brief (AI-generated starter rule)
date: 2026-07-29
tags:
- attack.execution
- attack.t1059.004
- attack.t1190
logsource:
category: process_creation
product: linux
detection:
selection_parent_image:
ParentImage|endswith:
- '/nginx'
- '/node'
- '/nodejs'
- '/httpd'
- '/apache2'
selection_parent_cmdline:
ParentCommandLine|contains:
- '/opt/vc/'
- 'velocloud'
- '/var/lib/velocloud'
selection_child_shell:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/ksh'
- '/python'
- '/python3'
- '/perl'
- '/ruby'
selection_child_tool:
Image|endswith:
- '/curl'
- '/wget'
- '/nc'
- '/nc.openbsd'
- '/nc.traditional'
- '/ncat'
- '/netcat'
- '/socat'
- '/base64'
- '/crontab'
- '/useradd'
- '/chattr'
- '/whoami'
- '/id'
- '/uname'
selection_child_cmdline:
CommandLine|contains:
- '/dev/tcp/'
- 'base64 -d'
- 'base64 --decode'
- '|sh'
- '| sh'
- '|bash'
- '| bash'
- 'pty.spawn'
- 'sh -i'
- '-e /bin/sh'
- 'authorized_keys'
- 'chmod +x'
- '/dev/shm/'
filter_vendor_maintenance:
ParentCommandLine|contains:
- 'vco_software_update'
- 'vco_upgrade_check.sh'
- '/opt/vc/scripts/db_backup.sh'
- '/opt/vc/scripts/vco_observability_manager.sh'
- 'cloud_init_ctl'
condition: (selection_parent_image or selection_parent_cmdline) and (selection_child_shell or selection_child_tool or selection_child_cmdline) and not filter_vendor_maintenance
falsepositives:
- VCO upgrade and patch runs, which legitimately invoke shell scripts, curl, tar and systemctl from the application tier
- Vendor diagnostic and support bundle collection, which runs id, uname, whoami and archiving utilities under the service accounts
- Administrator troubleshooting or maintenance actions initiated from the web UI or the vcadmin account
- Scheduled database backup, certificate renewal, telegraf and other monitoring jobs launched from the application tier
- Configuration management agents (Ansible, Salt, Puppet) executing under or alongside the web tier
level: high
Rule notes
The Sigma rule keys on parentage rather than on any request signature, so it works without knowing the vulnerable endpoint: any shell, download utility or network tool whose parent is the VCO web and API tier is anomalous, and vendor maintenance scripts are filtered by name. The YARA rule is behavioural only, carries no CVE-specific hashes, and targets dropped staging artifacts, reverse shells and small command-relay webshells, so scope it to writable and web-served directories plus captured request payloads rather than running it filesystem-wide. Sourced from Arista documentation: the appliance is Ubuntu-based, uses nginx with SSL material under /etc/nginx/velocloud/ssl/, installs under /opt/vc/, logs Portal, Upload and Backend to /var/log/{portal,upload,backend}/velocloud.log, ships MySQL configured via /etc/mysql/velocloud.cnf, and has a default vcadmin account. Inferred rather than sourced: the exact process image names of the Node.js services, the nginx access log path, the static web root path, and the service account names, which is why both rules match on generic parent patterns and directory substrings instead of exact identifiers.
References