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.
5 steps from start to impact.
Identify internet-facing VCO instance
- Internet connectivity
- VCO management interface exposed to public internet (default for on-prem deployments)
- 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
Obtain public Edge authentication certificate
- 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
- 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
x-vc-opt HTTP header in requests to VCOExploit input validation flaw to bypass authentication
- Network access to VCO web interface (Step 1)
- Valid public Edge certificate for the target VCO (Step 2)
- 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
x-vc-opt HTTP header; watch for connections from known attacker IPs 142.93.149.77 and 104.248.126.159Achieve privileged VCO host access and deploy persistence
/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.- Successful authentication bypass (Step 3)
- 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
/usr/local/sbin/.vcnode.js and /usr/local/sbin/vc-sysmond; process monitoring for unexpected Node.js or daemon processes; database export anomaliesPivot to managed Edge fleet and exfiltrate data
- Full VCO host compromise (Step 4)
- Managed Edge devices connected to the compromised VCO
- 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
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./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.- 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.
The supporting signals.
| In-the-Wild Status | Confirmed 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-Concept | No 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. |
| EPSS | 1.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 Vector | CVSS: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 Versions | VCO 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 Versions | 5.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 Compromise | Files: /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 Exposure | VCO 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 Timeline | 2026-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 Researcher | Not 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.
- Arista Security Advisory SA-0183 (Vendor Advisory)
- The Hacker News — CVSS 10.0 VeloCloud Flaw Actively Exploited
- xhack.io — Why CISA Wants Forensics, Not Just a Patch
- Rescana — CISA KEV Active Exploitation Alert
- Threat Frontier — VCO Exploited, No Fix for 6.1 and 7.0
- EveryWAN — Your WAN Orchestrator Is on the Internet by Design
- SentinelOne Vulnerability Database — CVE-2026-93952
- OpenCVE — CVE-2026-93952 Details
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.
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
#!/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