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.
5 steps from start to impact.
Identify internet-facing VCO instance
- VCO on-prem instance is deployed
- VCO web interface is reachable from the internet (true by design)
- 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
Obtain Edge public authentication certificate
- VCO is configured in
Certificate AcquireorCertificate Requiredmode - Attacker has access to the public certificate of at least one registered Edge
- 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
Send crafted input to VCO web interface
- Network access to VCO web interface
- Valid Edge public certificate in hand
- VCO running a vulnerable version
- 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
x-vc-opt HTTP header. Watch for unusual URL paths, encoded characters, or high request rates per Arista's guidance.Achieve RCE and install persistence on VCO host
/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.- Successful exploitation of step 3
- 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
dc78e206eaeadec59fc5801fe4556bd0 for vc-sysmond. Network monitoring for connections to known C2 IPs.Pivot to managed Edge devices fleet-wide
- Persistent access to compromised VCO
- Edge devices with firmware integrity validation may reject tampered updates
- Defenders monitoring Edge configuration drift would notice unauthorized changes
The supporting signals.
| In-the-wild exploitation | Confirmed 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-concept | No 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 score | 0.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 status | Not 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 vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H → 10.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 versions | VCO 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 versions | 5.2.3.16 and 6.4.2.8 released 2026-09-22. Patches for 6.1.x and 7.0.x trains are still pending — no fix available for those release trains as of 2026-09-23. |
| Internet exposure | VCO 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 timeline | 2026-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 / discoverer | Not 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. |
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 AcquireorCertificate Requiredmodes 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.
What to do — in priority order.
- 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.
- 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(MD5dc78e206eaeadec59fc5801fe4556bd0). Check nginx logs for thex-vc-optheader. Block C2 IPs142.93.149.77and104.248.126.159at the perimeter. Do this immediately — if IOCs are present, trigger your IR playbook. - Block known C2 IPs at perimeter firewalls — Add
142.93.149.77and104.248.126.159to 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. - 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.
- 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.
- 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.
- 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.
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.
#!/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- Arista Security Advisory 0183
- The Hacker News — CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited
- SecurityOnline — Exploited VeloCloud Vulnerability CVE-2026-93952
- PrivacyNeedle — Critical VeloCloud Orchestrator Vulnerability Actively Exploited
- everyWAN — VeloCloud Orchestrator Exposed by Design
- Rapid7 Metasploit — Module Request Issue #21940
- RedPacket Security — CVE Alert CVE-2026-93952
- OffSeq Threat Radar — CVE-2026-93952
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.