VeloCloud Orchestrator

CVE-2026-16812 is an unauthenticated OS command injection vulnerability (CWE-78) in Arista VeloCloud Orchestrator (VCO) On-Prem — the centralized management plane that configures, monitors, and pushes policy to every VeloCloud Edge device in your SD-WAN fabric. The flaw exposes privileged internal functionality that was *never intended to be remotely accessible*, yet VCO is exposed by default and — per Arista's own advisory — there is no configuration that can prevent the exposure. Affected release trains are VCO 5.2.x 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. Hosted and Dedicated VCO deployments were silently patched before disclosure; only on-prem customers are exposed.

Arista's vendor CVSS of 10.0 is not hyperbole — it is accurate and arguably under-communicates the downstream blast radius. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:C already signals the worst-case combination: unauthenticated, low complexity, no user interaction, scope changed. In practice, a compromised VCO gives the attacker the keys to every managed Edge appliance, meaning branch-office routing, firewall rules, and VPN tunnels across potentially hundreds of sites become attacker-controlled. CISA added this to KEV on July 27, 2026 with a federal deadline of July 30 — a 3-day turnaround that underscores the severity. Active zero-day exploitation was confirmed *before* the advisory dropped. The vendor score matches reality perfectly.

Why this verdict

• Zero authentication barrier: Arista explicitly states 'VCO tenant or operator credentials are not required for this exposure.' The attack chain starts and finishes without any credential, session, or privilege requirement — the rarest and most dangerous class of network-accessible vulnerability.
• No configuration mitigation exists: Unlike most appliance vulns where you can disable a feature or restrict an API, Arista states 'there is no configuration that can prevent the exposure.' The vulnerable surface is architecturally baked in and cannot be toggled off, only patched.
• Active zero-day exploitation confirmed: This was exploited *before* the advisory dropped. CISA added it to KEV on the same day (July 27) with a 3-day federal deadline — one of the tightest turnarounds in KEV history, signaling intelligence-community alarm.
• Role multiplier: VeloCloud Orchestrator is the network orchestration plane for enterprise SD-WAN deployments. 100% of VCO installs occupy the high-value 'network management / orchestration' role by definition. A compromised VCO grants the attacker push access to every managed Edge device — routing tables, firewall policies, VPN tunnels, and potentially firmware across hundreds of branch sites. The blast radius is fleet-scale network compromise. This alone floors the verdict at CRITICAL.
• Scope: Changed in CVSS terms: Arista confirms that 'compromised VCO instances may grant attackers access to VeloCloud Edge devices.' The impact extends beyond the vulnerable component to the entire managed device fleet, validating the S:C scope designation and the 10.0 score.

Why not higher?

CVSS 10.0 and CRITICAL are already the maximum possible severity ratings. There is no higher category to assign. Every signal — unauthenticated remote execution, active exploitation, KEV listing, fleet-scale blast radius, no mitigating configuration — converges on the ceiling.

Why not lower?

Downgrading would require at least one meaningful friction point: authentication requirements, complex preconditions, limited deployment role, or a narrow exposed population. None exist here. The VCO web interface is exposed by default with no config to prevent it, no credentials are needed, complexity is low, and 100% of VCO installs are high-value network orchestration planes. Active zero-day exploitation eliminates any theoretical argument about exploitability. The KEV listing with a 3-day federal deadline independently confirms CRITICAL. Downgrading would be indefensible.

1. Immediately restrict VCO web interface to trusted management IPs only via upstream firewall/ACL — Since VCO has no built-in configuration to limit exposure, you must enforce network-level access control at the perimeter firewall or load balancer. Whitelist only your NOC/SOC management subnets and the specific public IPs of your VeloCloud Edge devices (if direct internet connectivity is required). Deploy within hours — this is an active exploitation scenario that overrides the standard noisgate mitigation SLA. Accept that edge device management may be temporarily disrupted if you cannot enumerate all Edge source IPs.
2. Block known attacker IPs at all network boundaries — Add 8.19.75.217, 206.72.242.124, and 206.72.242.162 to your perimeter deny lists, IDS/IPS, and SIEM correlation rules immediately. These are confirmed IOCs from Arista's advisory. This is necessary but not sufficient — additional attacker infrastructure is likely.
3. Hunt for compromise indicators on VCO hosts immediately — Review VCO web access logs for atypical URL paths, encoded characters, or references to internal services. Check system logs for unexpected outbound connections, unauthorized command execution, new user accounts, modified crontabs, or SSH key additions. If any indicators are found, treat the VCO as compromised — isolate it, preserve forensics, and begin incident response.
4. Rotate all credentials managed by or stored on VCO — If compromise cannot be ruled out, rotate all VCO administrator passwords, API keys, Edge device management credentials, and any VPN pre-shared keys or certificates managed through the orchestrator. A compromised VCO exposes every secret it touches.
5. Validate Edge device configurations against known-good baselines — After patching or rebuilding the VCO, audit all managed Edge device configurations for unauthorized changes — especially routing policies, firewall rules, DNS settings, and VPN tunnel configurations. An attacker with VCO access could have pushed silent changes to your entire branch network.

Run this script on each VeloCloud Orchestrator On-Prem host as root or with sudo. It checks the installed VCO version against the known-vulnerable ranges. Example: sudo bash check_cve_2026_16812.sh

#!/usr/bin/env bash
# check_cve_2026_16812.sh
# Checks VeloCloud Orchestrator On-Prem for CVE-2026-16812 vulnerability
# Run on the VCO host as root or with sudo privileges.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

# Attempt to determine VCO version from known locations
VCO_VERSION=""

# Method 1: Check the VCO build properties file
if [[ -f /opt/velocloud/vco/build.properties ]]; then
    VCO_VERSION=$(grep -oP 'version=\K[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' /opt/velocloud/vco/build.properties 2>/dev/null || true)
fi

# Method 2: Check via the VCO CLI or version file
if [[ -z "$VCO_VERSION" && -f /opt/velocloud/vco/version.txt ]]; then
    VCO_VERSION=$(grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' /opt/velocloud/vco/version.txt 2>/dev/null || true)
fi

# Method 3: Try dpkg or rpm
if [[ -z "$VCO_VERSION" ]]; then
    VCO_VERSION=$(dpkg -l 2>/dev/null | grep -i velocloud-orchestrator | awk '{print $3}' | grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' || true)
fi
if [[ -z "$VCO_VERSION" ]]; then
    VCO_VERSION=$(rpm -qa 2>/dev/null | grep -i velocloud-orchestrator | grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' || true)
fi

if [[ -z "$VCO_VERSION" ]]; then
    echo "UNKNOWN — Could not determine VCO version. Verify manually."
    echo "Check /opt/velocloud/vco/build.properties or your package manager."
    exit 2
fi

echo "Detected VCO version: $VCO_VERSION"

# Parse version components
IFS='.' read -r MAJOR MINOR PATCH BUILD <<< "$VCO_VERSION"

# Version comparison helper
ver_gte() {
    # Returns 0 if $1.$2.$3.$4 >= $5.$6.$7.$8
    local a1=$1 a2=$2 a3=$3 a4=$4 b1=$5 b2=$6 b3=$7 b4=$8
    if (( a1 > b1 )); then return 0; fi
    if (( a1 < b1 )); then return 1; fi
    if (( a2 > b2 )); then return 0; fi
    if (( a2 < b2 )); then return 1; fi
    if (( a3 > b3 )); then return 0; fi
    if (( a3 < b3 )); then return 1; fi
    if (( a4 >= b4 )); then return 0; fi
    return 1
}

VULNERABLE=false

case "$MAJOR.$MINOR" in
    5.2)
        if ! ver_gte "$MAJOR" "$MINOR" "$PATCH" "$BUILD" 5 2 3 14; then
            VULNERABLE=true
        fi
        ;;
    6.1)
        if ! ver_gte "$MAJOR" "$MINOR" "$PATCH" "$BUILD" 6 1 3 4; then
            VULNERABLE=true
        fi
        ;;
    6.4)
        if ! ver_gte "$MAJOR" "$MINOR" "$PATCH" "$BUILD" 6 4 2 4; then
            VULNERABLE=true
        fi
        ;;
    7.0)
        if ! ver_gte "$MAJOR" "$MINOR" "$PATCH" "$BUILD" 7 0 0 1; then
            VULNERABLE=true
        fi
        ;;
    *)
        # Versions outside known trains — may be EOS or newer
        if (( MAJOR > 7 )) || (( MAJOR == 7 && MINOR > 0 )); then
            echo "PATCHED — VCO $VCO_VERSION is on a release train newer than affected versions."
            exit 0
        else
            echo "UNKNOWN — VCO $VCO_VERSION is on an unrecognized or end-of-support release train."
            echo "Assume VULNERABLE unless verified against Arista Security Advisory 0144."
            exit 2
        fi
        ;;
esac

if $VULNERABLE; then
    echo "VULNERABLE — VCO $VCO_VERSION is affected by CVE-2026-16812."
    echo "Upgrade immediately to the fixed version for your release train."
    echo "  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"
    exit 1
else
    echo "PATCHED — VCO $VCO_VERSION includes the fix for CVE-2026-16812."
    exit 0
fi

Sources

1. Arista Security Advisory 0144
2. CISA KEV Alert — July 27, 2026
3. BleepingComputer — Arista patches VeloCloud zero-day
4. The Hacker News — Attackers Exploit Arista VeloCloud
5. SecurityWeek — Critical VCO Vulnerability Exploited as Zero-Day
6. The Register — Arista patches actively exploited VeloCloud bug
7. Mallory.ai — CVE-2026-16812 Intelligence