← Back to Feed CACHED · 2026-10-24 04:07:19 · CACHE_KEY CVE-2026-93952
CVE-2026-93952 · CWE-20 · Disclosed 2026-09-22

Arista VeloCloud Orchestrator pre-auth privileged access via certificate-based authentication bypass

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

Someone found the master key to your branch-office kingdom and the front door was open by design

CVE-2026-93952 is an improper input validation flaw (CWE-20) in the certificate-based authentication pathway of Arista VeloCloud Orchestrator (VCO) on-prem. An attacker who can reach the VCO web interface and possesses only the public portion of a VeloCloud Edge device's authentication certificate can bypass authentication entirely and access privileged internal orchestrator functionality — no tenant or operator credentials required. The flaw affects VCO 5.2.0 through 5.2.3.15, 6.1.0 through 6.1.3.7, 6.4.0 through 6.4.2.7, and 7.0.0 through 7.0.0.2. Patches exist only for the 5.2 and 6.4 trains; 6.1.x and 7.0.x have no fix at the time of writing. Hosted/Dedicated VCO instances were silently patched before disclosure.

Arista's vendor score of CVSS 10.0 is essentially correct and, if anything, slightly generous only because the vector encodes PR:N while the real chain needs a public Edge certificate and certificate-based auth to be configured. In practice these are minimal friction: VCO is internet-exposed by design for zero-touch provisioning, certificate-based auth is the recommended and predominant Edge→VCO configuration, and the public half of a certificate is dramatically easier to obtain than a private key (network interception, compromised edge, or simply TLS handshake observation). CISA added this to KEV on September 22, 2026 with a 3-day federal remediation deadline and — critically — triggered the BOD 26-04 forensic triage requirement, meaning agencies must hunt for compromise indicators *before* patching. The vendor advisory itself publishes attacker IPs and backdoor file hashes, signaling confirmed intrusions in the wild. A minor CVSS reduction to 9.6 acknowledges the certificate prerequisite; the operational severity remains maximum.

"Pre-auth control-plane takeover of your entire SD-WAN fabric — actively exploited, patch now."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify internet-facing VCO instance

The attacker scans for VeloCloud Orchestrator management interfaces, which are internet-reachable by design for zero-touch Edge provisioning. VCO exposes a web UI on standard HTTPS ports. Shodan, Censys, and FOFA fingerprinting of the VCO login page or TLS certificate attributes readily identifies targets. No authentication or special tooling is required at this stage.
Conditions required:
  • Internet connectivity
  • VCO management interface exposed to public internet (default for on-prem deployments)
Where this breaks in practice:
  • Organizations that have placed VCO behind a VPN or IP-allowlisted firewall are not reachable — but this breaks zero-touch provisioning, so it is uncommon
Detection/coverage: Shodan/Censys exposure audits; external attack surface management (ASM) tools will flag the VCO login page
STEP 02

Obtain public Edge authentication certificate

The attacker acquires the public portion of a VeloCloud Edge device's authentication certificate. This is the *public* half only — not the private key. Public certificates are transmitted in the clear during TLS handshakes and can be intercepted from network traffic, extracted from a previously compromised or decommissioned Edge appliance, or potentially harvested from certificate transparency (CT) logs if publicly issued. The barrier here is meaningfully lower than stealing a private key.
Conditions required:
  • Certificate-based Edge→VCO authentication must be configured on the target VCO
  • Access to the public portion of any Edge certificate associated with the target VCO
Where this breaks in practice:
  • Organizations using pre-shared key (PSK) authentication instead of certificate-based auth are not affected
  • Obtaining the public cert requires *some* prior reconnaissance — a compromised Edge, packet capture on an Edge-facing network segment, or CT log mining
Detection/coverage: Anomalous certificate presentation patterns in VCO nginx access logs; monitoring for the x-vc-opt HTTP header in requests to VCO
STEP 03

Exploit input validation flaw to bypass authentication

Using the obtained public certificate, the attacker crafts specially formed HTTP requests to the VCO web interface that exploit the improper input validation in the certificate-based authentication pathway. This bypasses all tenant and operator credential checks and grants the attacker access to privileged internal orchestrator functions. No weaponized public PoC exists, but in-the-wild exploitation is confirmed by Arista and CISA.
Conditions required:
  • Network access to VCO web interface (Step 1)
  • Valid public Edge certificate for the target VCO (Step 2)
Where this breaks in practice:
  • No public PoC lowers the pool of potential attackers to those who have independently discovered the flaw or obtained exploit code from underground markets
  • Exploitation details are not publicly documented, raising the skill floor
Detection/coverage: Monitor VCO nginx logs for unusual URL path components, encoded characters, and the x-vc-opt HTTP header; watch for connections from known attacker IPs 142.93.149.77 and 104.248.126.159
STEP 04

Achieve privileged VCO host access and deploy persistence

With privileged internal access, the attacker escalates to full control of the VCO host. Observed post-exploitation activity includes deployment of backdoor files at /usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond (MD5: dc78e206eaeadec59fc5801fe4556bd0). The attacker now controls the SD-WAN control plane and can modify tenant configurations, extract managed data, push configuration changes to all managed Edge devices, or pivot laterally across the entire SD-WAN fabric.
Conditions required:
  • Successful authentication bypass (Step 3)
Where this breaks in practice:
  • EDR or host-based integrity monitoring on the VCO appliance would detect the backdoor file drops — but many organizations treat VCO as an appliance and do not deploy endpoint agents on it
Detection/coverage: File integrity monitoring (FIM) for /usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond; process monitoring for unexpected Node.js or daemon processes; database export anomalies
STEP 05

Pivot to managed Edge fleet and exfiltrate data

From the compromised VCO, the attacker has administrative control over every managed VeloCloud Edge device. This enables pushing malicious configuration changes to branch routers, intercepting or redirecting WAN traffic, extracting credentials and network topology data, and establishing persistent access across the entire SD-WAN fabric. The blast radius extends from a single orchestrator to every site the VCO manages — potentially hundreds or thousands of branch locations.
Conditions required:
  • Full VCO host compromise (Step 4)
  • Managed Edge devices connected to the compromised VCO
Where this breaks in practice:
  • Network segmentation between VCO management plane and Edge data plane may limit some lateral movement scenarios
  • Edge devices with local integrity checks may resist unauthorized configuration pushes
Detection/coverage: Audit VCO for unexpected configuration changes, credential rotations, device inventory modifications, or unauthorized administrative workflows; monitor Edge devices for unexpected configuration updates
03 · Compensating Control

1
CRITICAL 9.6→HIGH 7.5
SEVERITY REDUCED
Restrict VCO web interface to trusted admin networks immediately — Apply IP allowlists or firewall rules to limit VCO management interface access to known administrative IP ranges. This is Arista's own stated mitigation. It breaks zero-touch provisioning for new Edge devices, but that is an acceptable trade-off during a confirmed active exploitation campaign. Deploy within the noisgate CRITICAL mitigation SLA of 3 days — ideally within hours given KEV status and active exploitation.
2
CRITICAL 9.6→CRITICAL 9.2
Block known attacker infrastructure at network perimeter — Block inbound and outbound traffic to/from 142.93.149.77 and 104.248.126.159 at your perimeter firewall. Also block the x-vc-opt HTTP header in WAF/reverse proxy if one fronts VCO. This addresses the known campaign but does not prevent exploitation from other attacker infrastructure. Deploy immediately.
3
CRITICAL 9.6→CRITICAL 9.6
Hunt for IoCs on all VCO hosts before patching — Per BOD 26-04 forensic triage requirements, check all VCO hosts for /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond, MD5 dc78e206eaeadec59fc5801fe4556bd0, and the x-vc-opt header in nginx access logs. Preserve evidence before applying patches. If any IoC is found, escalate to full incident response — patching alone is insufficient on a compromised host. Execute within 24 hours.
4
CRITICAL 9.6→IGNORE 0.0
SEVERITY REDUCED
Apply vendor patches on 5.2.x and 6.4.x trains — Upgrade to VCO 5.2.3.16+ or 6.4.2.8+ respectively. This is the definitive fix for these trains. For organizations on 6.1.x or 7.0.x where no patch exists, combine network restriction (item 1) with vendor engagement for an emergency fix or train migration. Deploy within the noisgate CRITICAL remediation SLA of 90 days, but given active exploitation and KEV listing, target patch deployment within days, not weeks.
5
CRITICAL 9.6→MEDIUM 5.0
SEVERITY REDUCED
Rotate all VCO and Edge credentials post-patch — After patching or confirming no compromise, rotate all VCO operator/tenant credentials, Edge authentication certificates, and any API keys managed through the orchestrator. A compromised VCO provides access to all managed credentials, so post-compromise hygiene is essential even if no IoCs are found. Complete within 7 days of patching.
What doesn't work
  • WAF generic rule sets — The exploitation uses the certificate-based authentication pathway, not a standard web application attack pattern. Generic OWASP rule sets will not detect or block the crafted requests unless you write a custom rule targeting the specific authentication bypass vector, which is not publicly documented.
  • Disabling the VCO web UI entirely — The web interface is required for both Edge management and operator administration. Disabling it renders the SD-WAN unmanageable.
  • Network segmentation between VCO and Edges — VCO must communicate with Edges to function. You cannot firewall VCO away from its managed fleet without breaking the product. The attack enters via the web interface, not via Edge-to-VCO management channels.
  • Switching from certificate-based to PSK authentication — While this would remove the attack surface, changing the Edge authentication mode on a production SD-WAN fabric is a major operational change that could disrupt all Edge connectivity. This is not a realistic emergency mitigation for most deployments.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild StatusConfirmed active exploitation. Added to CISA KEV on 2026-09-22 with a 3-day federal remediation deadline (2026-09-25). BOD 26-04 forensic triage flag is set — agencies must hunt for indicators *before* patching. Arista advisory states the issue was 'discovered externally' and is 'known to be actively exploited.' Known ransomware campaign use: Unknown.
Proof-of-ConceptNo public PoC available. No exploit code found on pocindex.io, GitHub, ExploitDB, or Metasploit as of 2026-10-24. The absence of a public PoC combined with confirmed wild exploitation suggests a privately held exploit, likely in the hands of a targeted threat actor or exploit broker.
EPSS1.06% (relatively low probability score despite confirmed exploitation — a reminder that EPSS is a statistical model, not a substitute for KEV status and active exploitation intelligence)
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — Network-attackable, low complexity, no privileges, no user interaction, scope change (extends beyond the vulnerable component to managed Edges). CVSSv4.0: 9.5. The S:C is particularly meaningful here: VCO compromise cascades to the entire managed Edge fleet.
Affected VersionsVCO 5.2.0–5.2.3.15, 6.1.0–6.1.3.7, 6.4.0–6.4.2.7, 7.0.0–7.0.0.2. Hosted/Dedicated VCO instances were impacted but patched silently before disclosure.
Fixed Versions5.2.3.16+ and 6.4.2.8+ are available now. 6.1.x and 7.0.x trains have no fix at the time of writing — Arista says fixes 'will be added over time' with no committed timeline. Organizations on 6.1.x or 7.0.x are exposed with no vendor patch available.
Indicators of CompromiseFiles: /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond (MD5: dc78e206eaeadec59fc5801fe4556bd0). HTTP header: x-vc-opt in nginx logs. Attacker IPs: 142.93.149.77, 104.248.126.159 (DigitalOcean). Check logs retroactively to early September 2026.
Internet ExposureVCO is internet-exposed by design for zero-touch Edge provisioning. The management web interface must be reachable from branch sites over public internet. Restricting it breaks zero-touch provisioning workflows. Exact Shodan/Censys counts not publicly reported, but VeloCloud holds a leading SD-WAN market share and VCO on-prem instances are deployed across thousands of enterprises.
Disclosure Timeline2026-09-22: Arista advisory SA-0183 published and CISA KEV entry added simultaneously. 2026-09-25: Federal remediation deadline. This was disclosed as a zero-day — exploitation preceded the advisory.
Reporting ResearcherNot attributed. Arista states the issue was 'discovered externally' with no named researcher or organization credited. The external discovery combined with active exploitation and specific IoCs suggests the vulnerability was identified through incident response to an ongoing campaign.

Sources.

  1. Arista Security Advisory SA-0183 (Vendor Advisory)
  2. The Hacker News — CVSS 10.0 VeloCloud Flaw Actively Exploited
  3. xhack.io — Why CISA Wants Forensics, Not Just a Patch
  4. Rescana — CISA KEV Active Exploitation Alert
  5. Threat Frontier — VCO Exploited, No Fix for 6.1 and 7.0
  6. EveryWAN — Your WAN Orchestrator Is on the Internet by Design
  7. SentinelOne Vulnerability Database — CVE-2026-93952
  8. OpenCVE — CVE-2026-93952 Details
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.6/10)

Why this verdict

  • Pre-auth remote exploitation confirmed in the wild: The chain requires no VCO credentials — only the public portion of an Edge certificate and network access. Both attacker IPs and deployed backdoor hashes are published, confirming real-world compromise. This is not theoretical.
  • Internet-exposed by design eliminates the network-access friction: Unlike most enterprise appliances that *can* be firewalled, VCO *must* be internet-reachable for zero-touch provisioning. The AV:N condition is met by default for essentially all on-prem deployments. Typical firewall-based friction does not apply.
  • Certificate prerequisite provides only marginal friction: The attacker needs only the *public* portion of an Edge certificate — not the private key. Public certificates are exchanged in cleartext during TLS handshakes and can be obtained through passive network observation, CT logs, or a previously compromised Edge device. This is a speed bump, not a wall — enough to justify reducing from 10.0 to 9.6 but no further.
  • Role multiplier: VeloCloud Orchestrator is *by definition* a high-value network control-plane component. 100% of VCO on-prem instances occupy the 'network edge appliance / SD-WAN control plane' role. A compromised VCO provides administrative control over every managed Edge device — potentially hundreds or thousands of branch routers per instance. The blast radius is fleet-scale: configuration push to all branches, WAN traffic interception/redirection, credential extraction, and persistent lateral access across the entire SD-WAN fabric. This places the verdict floor at CRITICAL per the deployment-role blast-radius rule.
  • No patch for two active trains: Organizations on VCO 6.1.x and 7.0.x have no vendor fix available. They can only mitigate via network access restriction, which degrades core SD-WAN functionality. This elevates operational urgency beyond what the CVSS score alone captures.
  • Minor downgrade from 10.0 to 9.6: The certificate-based authentication prerequisite (must be configured) and the need to obtain a public Edge certificate introduce small but real friction that slightly narrows the universally-exploitable population compared to a true zero-prerequisite CVSS 10.0. This is a technical adjustment, not an operational one — the verdict remains CRITICAL.

Why not higher?

A score above 9.6 would require true zero-prerequisite exploitation — no conditions beyond raw network access. Here, certificate-based Edge→VCO authentication must be configured (it is common but not universal), and the attacker must obtain the public portion of an Edge certificate (feasible but not automatic). These two prerequisites prevent a clean 10.0, though they are admittedly thin barriers given the in-the-wild exploitation track record.

Why not lower?

Downgrading below CRITICAL would require significant friction or a narrow blast radius, neither of which applies. VCO is internet-facing by default, the certificate prerequisite is low-friction, exploitation is confirmed in the wild with deployed backdoors, the CISA KEV 3-day deadline and forensic triage mandate reflect maximum urgency, and the blast radius is fleet-scale by definition — a single VCO controls every branch Edge in the deployment. The deployment-role floor is CRITICAL and nothing in the friction analysis breaks it.

06 · Verification

Crowdsourced verification payload.

Run this script on each VCO host as root (or via sudo). It checks the installed VCO version against known-vulnerable ranges and hunts for published IoCs. Invoke with: sudo bash vco_check.sh

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

set -euo pipefail

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

COMPROMISED=0
VULNERABLE=0

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

# --- IoC Hunt ---
echo "[1/3] Hunting for known indicators of compromise..."

IOC_FILES=(
  "/usr/local/sbin/.vcnode.js"
  "/usr/local/sbin/vc-sysmond"
)

MAL_MD5="dc78e206eaeadec59fc5801fe4556bd0"

for f in "${IOC_FILES[@]}"; do
  if [ -f "$f" ]; then
    echo -e "${RED}[!] COMPROMISED: Backdoor file found: $f${NC}"
    FILE_MD5=$(md5sum "$f" 2>/dev/null | awk '{print $1}' || echo "unknown")
    echo "    MD5: $FILE_MD5"
    if [ "$FILE_MD5" = "$MAL_MD5" ]; then
      echo -e "${RED}    [!] MD5 matches known malicious hash${NC}"
    fi
    COMPROMISED=1
  fi
done

# Check nginx logs for x-vc-opt header
NGINX_LOGS=$(find /var/log/nginx/ -name '*.log*' 2>/dev/null || true)
if [ -n "$NGINX_LOGS" ]; then
  if grep -rl 'x-vc-opt' /var/log/nginx/ 2>/dev/null; then
    echo -e "${RED}[!] COMPROMISED: x-vc-opt header found in nginx logs${NC}"
    COMPROMISED=1
  else
    echo "    No x-vc-opt header found in nginx logs (good)"
  fi
else
  echo "    No nginx logs found to inspect"
fi

# Check for known attacker IPs in logs
ATTACKER_IPS=("142.93.149.77" "104.248.126.159")
for ip in "${ATTACKER_IPS[@]}"; do
  if grep -rl "$ip" /var/log/nginx/ 2>/dev/null; then
    echo -e "${RED}[!] COMPROMISED: Known attacker IP $ip found in nginx logs${NC}"
    COMPROMISED=1
  fi
done

if [ "$COMPROMISED" -eq 1 ]; then
  echo ""
  echo -e "${RED}*** COMPROMISE INDICATORS DETECTED ***${NC}"
  echo "STOP: Preserve evidence. Do NOT patch yet. Initiate incident response."
  echo "Result: COMPROMISED"
  exit 2
fi

echo "    No IoCs detected (check is non-exhaustive)"
echo ""

# --- Version Check ---
echo "[2/3] Checking VCO version..."

# VCO version is typically in /etc/vco-version or via the API
VCO_VERSION=""
if [ -f /etc/vco-version ]; then
  VCO_VERSION=$(cat /etc/vco-version | head -1 | tr -d '[:space:]')
elif [ -f /opt/vc/vco/version.txt ]; then
  VCO_VERSION=$(cat /opt/vc/vco/version.txt | head -1 | tr -d '[:space:]')
elif command -v vco-version &>/dev/null; then
  VCO_VERSION=$(vco-version 2>/dev/null | head -1 | tr -d '[:space:]')
fi

if [ -z "$VCO_VERSION" ]; then
  echo -e "${YELLOW}    Could not determine VCO version automatically${NC}"
  echo "    Check manually: cat /etc/vco-version or VCO admin UI"
  echo ""
  echo "    Known vulnerable: 5.2.0-5.2.3.15, 6.1.0-6.1.3.7, 6.4.0-6.4.2.7, 7.0.0-7.0.0.2"
  echo "    Fixed: 5.2.3.16+, 6.4.2.8+ (6.1.x and 7.0.x: NO FIX AVAILABLE)"
  echo "Result: UNKNOWN"
  exit 3
fi

echo "    Detected VCO version: $VCO_VERSION"

# Parse major.minor.patch.build
IFS='.' read -ra VER <<< "$VCO_VERSION"
MAJOR=${VER[0]:-0}
MINOR=${VER[1]:-0}
PATCH=${VER[2]:-0}
BUILD=${VER[3]:-0}

check_vulnerable() {
  # 5.2.x train: vulnerable if <= 5.2.3.15
  if [ "$MAJOR" -eq 5 ] && [ "$MINOR" -eq 2 ]; then
    if [ "$PATCH" -lt 3 ] || ([ "$PATCH" -eq 3 ] && [ "$BUILD" -le 15 ]); then
      return 0  # vulnerable
    fi
    return 1  # patched
  fi
  # 6.1.x train: vulnerable, NO FIX
  if [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 1 ]; then
    return 0  # vulnerable, no fix available
  fi
  # 6.4.x train: vulnerable if <= 6.4.2.7
  if [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 4 ]; then
    if [ "$PATCH" -lt 2 ] || ([ "$PATCH" -eq 2 ] && [ "$BUILD" -le 7 ]); then
      return 0  # vulnerable
    fi
    return 1  # patched
  fi
  # 7.0.x train: vulnerable, NO FIX
  if [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]; then
    return 0  # vulnerable, no fix available
  fi
  return 1  # unknown/other train, assume not vulnerable
}

if check_vulnerable; then
  VULNERABLE=1
  echo -e "${RED}    Version $VCO_VERSION is VULNERABLE to CVE-2026-93952${NC}"
  if ([ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 1 ]) || ([ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]); then
    echo -e "${RED}    WARNING: No patch available for this train. Apply network mitigations immediately.${NC}"
  fi
else
  echo -e "${GREEN}    Version $VCO_VERSION appears PATCHED${NC}"
fi

echo ""

# --- Certificate Auth Check ---
echo "[3/3] Checking if certificate-based Edge authentication is configured..."
echo "    (Manual check required: verify Edge authentication mode in VCO admin UI)"
echo "    If PSK-only authentication is in use, the attack surface for this CVE is absent."
echo ""

# --- Final Verdict ---
echo "========================================"
if [ "$VULNERABLE" -eq 1 ]; then
  echo -e "${RED}Result: VULNERABLE${NC}"
  echo "Action: Apply patch (5.2.3.16+ or 6.4.2.8+) or restrict VCO web interface access immediately."
  exit 1
else
  echo -e "${GREEN}Result: PATCHED${NC}"
  exit 0
fi