← Back to Feed CACHED · 2026-09-23 09:29:58 · CACHE_KEY CVE-2026-93952
CVE-2026-93952 · CWE-20 · Disclosed 2026-09-22

VeloCloud Orchestrator

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

Someone found the master key to your entire branch network and is already inside the building

CVE-2026-93952 is an improper input validation flaw (CWE-20) in Arista VeloCloud Orchestrator (VCO) on-premises deployments. VCO is the central management plane for VeloCloud SD-WAN — it provisions, monitors, and pushes policy to every Edge appliance in the fleet. An unauthenticated remote attacker who can reach the VCO web interface and possesses the *public* portion of any Edge device's authentication certificate can bypass authorization controls, access privileged internal functions, and fully compromise the VCO host. Affected builds span four release trains: 5.2.3.15 and earlier, 6.1.3.7 and earlier, 6.4.2.7 and earlier, and 7.0.0.2 and earlier. Only on-premises VCO instances configured for certificate-based Edge authentication (Certificate Acquire or Certificate Required modes) are vulnerable — pre-shared-key deployments are not affected. Hosted and Dedicated VCO instances have already been patched by Arista.

Arista's CVSS 10.0 score is aggressive but defensible. VCO is internet-facing by design — branch Edge devices must discover and register with it over the public internet, so the management interface cannot be fully air-gapped. The attack is unauthenticated, low-complexity, and requires no user interaction. The one narrowing factor — the certificate-auth mode prerequisite — limits the vulnerable population but does *not* change the severity class, because certificate-auth is the recommended enterprise-grade configuration (PSK is the exception, not the norm for security-conscious deployments). Arista confirmed active exploitation on disclosure day, with IOCs including backdoor daemons and C2 infrastructure already in the wild. When we factor in that compromising a single VCO instance gives an attacker control over every Edge device it manages — potentially hundreds of branch routers — the vendor's CRITICAL rating is warranted. We bring the reassessed score to 9.4 solely to account for the certificate-auth-mode population narrowing, but the verdict stays CRITICAL.

"Actively exploited SD-WAN controller zero-day gives unauthenticated attackers fleet-wide network control."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify internet-facing VCO instance

The attacker scans for VeloCloud Orchestrator web interfaces exposed on the public internet. VCO is designed to be internet-reachable so that Edge devices at remote sites can auto-provision. Standard service fingerprinting (HTTP headers, TLS certificate subject, login page signatures) identifies VCO instances. Tools like Shodan, Censys, or FOFA reliably enumerate them.
Conditions required:
  • VCO on-prem instance is deployed
  • VCO web interface is reachable from the internet (true by design)
Where this breaks in practice:
  • Hosted/Dedicated VCO instances are already patched and not vulnerable
  • On-prem VCO deployments behind a properly segmented admin-only VPN would reduce reachability — but the Edge activation channel must remain open
Detection/coverage: Network scanners can fingerprint VCO. GreyNoise or internal IDS can flag reconnaissance against VCO endpoints.
STEP 02

Obtain Edge public authentication certificate

The attacker acquires the public portion of any Edge device's authentication certificate. In certificate-based auth mode, Edge devices present their certificates to VCO during TLS mutual authentication. The *public* certificate is by definition not secret — it can be obtained by intercepting any Edge-to-VCO TLS handshake, from a compromised Edge device, from backup artifacts, or from any network position that observes Edge traffic. This is a low bar.
Conditions required:
  • VCO is configured in Certificate Acquire or Certificate Required mode
  • Attacker has access to the public certificate of at least one registered Edge
Where this breaks in practice:
  • Deployments using pre-shared key (PSK) authentication are not vulnerable
  • If no Edge public certificate is obtainable, the chain breaks — but the 'public' nature of the artifact makes this unlikely in practice
Detection/coverage: Certificate extraction from TLS intercept is passive and difficult to detect on the VCO side.
STEP 03

Send crafted input to VCO web interface

Using the Edge's public certificate for authentication context, the attacker sends specially crafted HTTP requests to the VCO web interface that exploit the improper input validation flaw. No VCO operator or tenant credentials are required. The malicious input bypasses authorization controls and grants access to privileged internal functions on the VCO host. Arista has not disclosed the specific input vector, and no public PoC exists, but the attack is confirmed weaponized in the wild.
Conditions required:
  • Network access to VCO web interface
  • Valid Edge public certificate in hand
  • VCO running a vulnerable version
Where this breaks in practice:
  • Arista withheld technical details, limiting copycat exploitation
  • No public PoC or Metasploit module exists yet (Rapid7 issue #21940 is detection-only)
  • Web application firewalls inspecting VCO traffic may catch anomalous payloads
Detection/coverage: Monitor nginx access logs for the x-vc-opt HTTP header. Watch for unusual URL paths, encoded characters, or high request rates per Arista's guidance.
STEP 04

Achieve RCE and install persistence on VCO host

Successful exploitation grants the attacker code execution on the VCO host. Observed post-exploitation activity includes dropping backdoor files (/usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond) and creating a systemd persistence service (/etc/systemd/system/vc-sysmon.service). The attacker establishes C2 communication to known IPs 142.93.149.77 and 104.248.126.159.
Conditions required:
  • Successful exploitation of step 3
Where this breaks in practice:
  • Host-based intrusion detection or file integrity monitoring on the VCO appliance may catch the backdoor installation
  • Outbound firewall rules blocking non-essential egress from VCO would disrupt C2
Detection/coverage: File integrity monitoring for IOC paths. MD5 dc78e206eaeadec59fc5801fe4556bd0 for vc-sysmond. Network monitoring for connections to known C2 IPs.
STEP 05

Pivot to managed Edge devices fleet-wide

With full control of the VCO management plane, the attacker can push malicious configuration or firmware to every Edge device managed by the orchestrator. This grants network-level access to every branch site, enabling traffic interception, lateral movement into branch LANs, and disruption of WAN connectivity across the entire organization. The blast radius scales with the number of managed Edges — potentially hundreds or thousands of sites.
Conditions required:
  • Persistent access to compromised VCO
Where this breaks in practice:
  • Edge devices with firmware integrity validation may reject tampered updates
  • Defenders monitoring Edge configuration drift would notice unauthorized changes
Detection/coverage: VCO audit logs (if not tampered) would show unauthorized configuration pushes. Edge devices reporting unexpected configuration changes to secondary monitoring.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed active. Arista stated on disclosure day (2026-09-22): *"This issue was discovered externally and is known to be actively exploited."* IOCs include backdoor daemons, C2 IPs, and a persistence systemd service. Not yet a named campaign.
Proof-of-conceptNo public PoC. Arista intentionally withheld technical mechanics. A Metasploit module request (issue #21940) was filed on 2026-09-22 for detection-only; exploit module deferred pending disclosure. The attack is weaponized privately.
EPSS score0.00424 (0.42%, ~top 15% of all CVEs). Low model confidence likely due to the CVE being <48 hours old at scoring time. Expect rapid increase as exploitation telemetry feeds into the model.
KEV statusNot listed as of 2026-09-23. Given vendor-confirmed active exploitation, KEV addition is imminent. Note: the related VCO flaw CVE-2026-16812 was added to KEV in July 2026 with a federal deadline of 2026-07-30.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H10.0. CVSSv4.0: 9.5. Network-accessible, no privileges, no interaction, scope change (VCO compromise extends to all managed Edges). The vector accurately reflects the unauthenticated remote attack with cross-scope impact.
Affected versionsVCO on-prem 5.2.x ≤ 5.2.3.15, 6.1.x ≤ 6.1.3.7, 6.4.x ≤ 6.4.2.7, 7.0.x ≤ 7.0.0.2. Only Certificate Acquire or Certificate Required auth modes. PSK mode is not affected. Hosted/Dedicated VCO already patched.
Fixed versions5.2.3.16 and 6.4.2.8 released 2026-09-22. Patches for 6.1.x and 7.0.x trains are still pendingno fix available for those release trains as of 2026-09-23.
Internet exposureVCO is internet-facing by design — Edge devices must reach it for zero-touch provisioning. Per everyWAN analysis: *"VCO is exposed by default. There is no configuration that can prevent the exposure."* Specific Shodan/Censys instance counts not published, but the architectural requirement means every on-prem VCO has a public-facing surface.
Disclosure timeline2026-09-22: Arista publishes Security Advisory 0183, confirms active exploitation, releases partial patches. This is the second critical VCO zero-day in 2026 after CVE-2026-16812 (command injection, July 2026).
Researcher / discovererNot attributed. Arista states the issue *"was discovered externally"* but does not credit a researcher or organization. The IOCs suggest the flaw was found via incident response to an active compromise.
04 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.4/10)

Why this verdict

  • Active exploitation confirmed on day zero. Arista's advisory explicitly states the vulnerability was discovered externally and is actively exploited. IOCs (backdoor daemons, C2 IPs, persistence services) indicate sophisticated post-exploitation already occurring in the wild. This eliminates any theoretical discount for exploitability.
  • Internet-facing by design — no network friction. VCO must be publicly reachable for Edge device provisioning. Unlike most management planes that *can* be segmented behind a VPN, VCO's Edge activation channel is architecturally exposed. The CVSS AV:N assumption holds without caveat for every on-prem deployment.
  • Certificate-auth mode narrows the vulnerable population (−0.6 from vendor score). Only deployments using Certificate Acquire or Certificate Required modes are affected. PSK-mode deployments are safe. However, certificate-auth is the vendor-recommended enterprise configuration for production SD-WAN. While we lack exact adoption percentages, the security-conscious enterprise segment most likely to run on-prem VCO is also the segment most likely to use cert-auth. This narrows but does not dramatically reduce the at-risk population.
  • Public certificate requirement is low friction. The attacker needs the *public* portion of an Edge certificate — not the private key. Public certificates are exchanged in TLS handshakes and are observable from any network vantage point that sees Edge-to-VCO traffic. This is not a meaningful barrier for a motivated attacker.
  • Role multiplier: VCO is a canonical high-value network infrastructure component. VeloCloud Orchestrator is the centralized management plane for the entire SD-WAN. 100% of on-prem VCO instances occupy this role by definition — there is no low-value deployment of a WAN controller. Compromising VCO grants control over every managed Edge device (potentially hundreds of branch routers), enabling fleet-scale network compromise, traffic interception at all branch sites, and lateral movement into branch LANs. The blast radius is fleet-scale. Per the deployment-role blast radius rule, the verdict floor is CRITICAL because the affected component canonically occupies the high-value role (≥10% threshold trivially met at 100%) and the chain outcome is fleet compromise.
  • No public PoC tempers mass exploitation risk slightly. Arista withheld technical details, and no public exploit code exists. The Metasploit community has filed a detection-only module request. This limits copycat attacks in the near term, but the active exploitation proves the vulnerability is already weaponized by at least one threat actor.

Why not higher?

The vendor already assigned the maximum possible score of 10.0. Our reassessment at 9.4 represents a marginal downgrade, not an upgrade. The certificate-auth-mode prerequisite is a real configuration-dependent narrowing that the CVSS base score's AC:L does not account for — some on-prem VCO deployments using PSK mode are simply not vulnerable. This prevents us from matching the vendor's 10.0.

Why not lower?

Dropping below CRITICAL would require evidence that the certificate-auth-mode requirement excludes the overwhelming majority of on-prem VCO deployments, and it does not — cert-auth is the recommended enterprise configuration. VCO is internet-facing by design, the attack is unauthenticated, exploitation is confirmed active, and the blast radius is fleet-scale network compromise. Every friction point in the chain (public cert obtainability, no PoC) is either low-barrier or already overcome by real-world attackers. The deployment-role floor alone mandates CRITICAL.

05 · Compensating Control

What to do — in priority order.

  1. Restrict VCO web interface access to trusted admin networks immediately — Deploy network ACLs or firewall rules to limit access to the VCO management interface to known administrator IP ranges. The Edge activation channel must remain open, but the admin console can be segmented. This is your most impactful mitigation and should be deployed within 3 days per the noisgate mitigation SLA for CRITICAL findings.
  2. Hunt for published IOCs on all VCO hosts now — Search for /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond, /etc/systemd/system/vc-sysmon.service (MD5 dc78e206eaeadec59fc5801fe4556bd0). Check nginx logs for the x-vc-opt header. Block C2 IPs 142.93.149.77 and 104.248.126.159 at the perimeter. Do this immediately — if IOCs are present, trigger your IR playbook.
  3. Block known C2 IPs at perimeter firewalls — Add 142.93.149.77 and 104.248.126.159 to block lists on all egress firewalls and proxy servers. Also block outbound connections from VCO hosts to any destination not required for Edge management operations. Deploy within 24 hours.
  4. Apply available patches (5.2.3.16, 6.4.2.8) immediately — If running the 5.2.x or 6.4.x trains, patches are available now. Apply within the 3-day noisgate mitigation SLA. If running 6.1.x or 7.0.x where patches are pending, the compensating network controls above are your only option until Arista ships fixes.
  5. Monitor VCO audit logs and Edge configuration drift — Enable enhanced logging on VCO and set up alerts for unauthorized configuration changes pushed to Edge devices. A compromised VCO may push malicious policies fleet-wide. Configuration drift detection is your canary for post-exploitation pivoting.
  6. Rotate all VCO operator and tenant credentials post-patch — After patching or confirming no compromise, rotate all administrator credentials, API tokens, and Edge certificates. An attacker with prior VCO access may have harvested credentials for persistence beyond the backdoor files.
What doesn't work
  • Switching to PSK authentication mode — while this removes the vulnerability, it degrades your SD-WAN security posture significantly. PSK is not recommended for production enterprise deployments and introduces its own risks (shared secret management, no per-device identity). This is a last resort, not a compensating control.
  • WAF in front of VCO — a generic WAF will not understand the VCO-specific protocol semantics and is unlikely to catch the crafted input without custom rules. The attack surface is the Edge-to-VCO communication channel, which uses application-specific protocols that a WAF cannot meaningfully inspect without VeloCloud-specific signatures.
  • Disabling the VCO web interface entirely — this breaks Edge device management and provisioning. VCO's web interface is the operational control plane; disabling it is equivalent to taking your SD-WAN offline.
06 · Verification

Crowdsourced verification payload.

Run this script on each VCO on-premises host as root. It checks the VCO version against known vulnerable ranges and inspects the Edge authentication mode configuration. Example: sudo bash vco_check.sh. Requires root access to read VCO configuration files.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-93952 VeloCloud Orchestrator on-prem vulnerability checker
# Run on the VCO host as root.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 2=VULNERABLE, 0=PATCHED, 1=UNKNOWN

set -euo pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

echo "=== CVE-2026-93952 VeloCloud Orchestrator Check ==="
echo "Date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

# --- Step 1: Check for IOCs first (compromise indicators) ---
echo "[*] Checking for known IOCs..."
ioc_found=0
for f in /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond /etc/systemd/system/vc-sysmon.service; do
  if [ -f "$f" ]; then
    echo -e "${RED}[!] IOC FOUND: $f exists!${NC}"
    ioc_found=1
  fi
done

if [ -f /usr/local/sbin/vc-sysmond ]; then
  actual_md5=$(md5sum /usr/local/sbin/vc-sysmond 2>/dev/null | awk '{print $1}')
  if [ "$actual_md5" = "dc78e206eaeadec59fc5801fe4556bd0" ]; then
    echo -e "${RED}[!] IOC CONFIRMED: vc-sysmond MD5 matches known malicious hash!${NC}"
  fi
fi

if [ $ioc_found -eq 1 ]; then
  echo -e "${RED}[!!!] ACTIVE COMPROMISE DETECTED — initiate incident response immediately.${NC}"
fi

# --- Step 2: Determine VCO version ---
echo ""
echo "[*] Detecting VCO version..."
VCO_VERSION=""

# Try common version file locations
for vfile in /opt/vc/VERSION /opt/velocloud/VERSION /etc/velocloud/version; do
  if [ -f "$vfile" ]; then
    VCO_VERSION=$(cat "$vfile" | grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)
    break
  fi
done

# Fallback: try vco-version or similar CLI
if [ -z "$VCO_VERSION" ]; then
  VCO_VERSION=$(command -v vco-version >/dev/null 2>&1 && vco-version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi

if [ -z "$VCO_VERSION" ]; then
  echo -e "${YELLOW}[?] Could not determine VCO version automatically.${NC}"
  echo "UNKNOWN"
  exit 1
fi

echo "[*] Detected VCO version: $VCO_VERSION"

# --- Step 3: Parse version and check against vulnerable ranges ---
IFS='.' read -r major minor patch build <<< "$VCO_VERSION"
train="${major}.${minor}"

vulnerable=0
case "$train" in
  5.2)
    if [ "$patch" -lt 3 ] || ([ "$patch" -eq 3 ] && [ "$build" -le 15 ]); then
      vulnerable=1
    fi
    ;;
  6.1)
    if [ "$patch" -lt 3 ] || ([ "$patch" -eq 3 ] && [ "$build" -le 7 ]); then
      vulnerable=1
      echo -e "${YELLOW}[!] WARNING: 6.1.x patch is NOT YET AVAILABLE from Arista.${NC}"
    fi
    ;;
  6.4)
    if [ "$patch" -lt 2 ] || ([ "$patch" -eq 2 ] && [ "$build" -le 7 ]); then
      vulnerable=1
    fi
    ;;
  7.0)
    if [ "$patch" -lt 0 ] || ([ "$patch" -eq 0 ] && [ "$build" -le 2 ]); then
      vulnerable=1
      echo -e "${YELLOW}[!] WARNING: 7.0.x patch is NOT YET AVAILABLE from Arista.${NC}"
    fi
    ;;
  *)
    echo -e "${YELLOW}[?] Unrecognized release train: $train${NC}"
    echo "UNKNOWN"
    exit 1
    ;;
esac

# --- Step 4: Check authentication mode ---
echo ""
echo "[*] Checking Edge authentication mode..."
cert_mode="unknown"
# Check VCO properties for certificate auth setting
for cfg in /opt/vc/portal/config/config.json /opt/velocloud/portal/config.json; do
  if [ -f "$cfg" ]; then
    if grep -qiE '"edgeAuth".*"cert"' "$cfg" 2>/dev/null; then
      cert_mode="certificate"
    elif grep -qiE '"edgeAuth".*"psk"' "$cfg" 2>/dev/null; then
      cert_mode="psk"
    fi
    break
  fi
done

if [ "$cert_mode" = "psk" ]; then
  echo -e "${GREEN}[*] Edge auth mode: PSK (pre-shared key) — NOT VULNERABLE to this CVE.${NC}"
  echo "PATCHED"
  exit 0
elif [ "$cert_mode" = "certificate" ]; then
  echo -e "${YELLOW}[*] Edge auth mode: Certificate-based — EXPOSED to this CVE if version is vulnerable.${NC}"
else
  echo -e "${YELLOW}[?] Could not determine Edge auth mode. Assume certificate-based for safety.${NC}"
fi

# --- Step 5: Final verdict ---
echo ""
if [ $vulnerable -eq 1 ]; then
  echo -e "${RED}=== VULNERABLE ===${NC}"
  echo -e "${RED}VCO $VCO_VERSION is in the affected range for CVE-2026-93952.${NC}"
  echo -e "Apply patch immediately. Fixed versions: 5.2.3.16 (5.2 train), 6.4.2.8 (6.4 train)."
  echo -e "6.1.x and 7.0.x patches are PENDING from Arista."
  echo "VULNERABLE"
  exit 2
else
  echo -e "${GREEN}=== PATCHED ===${NC}"
  echo -e "${GREEN}VCO $VCO_VERSION is at or above the fixed version.${NC}"
  echo "PATCHED"
  exit 0
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.