CVE-2026-93952: CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited — Detection and Remediation Guide

On September 22, Arista disclosed that attackers are actively exploiting a critical vulnerability in on-premises VeloCloud Orchestrator (VCO) — the centralized management server that provisions, configures, and monitors every Edge device in a VeloCloud SD-WAN deployment. The flaw is tracked as CVE-2026-93952 and carries a CVSS score of 10.0, the maximum possible severity rating.

Let me be direct about why this should be at the top of your queue this week:

• No authentication is required. A remote attacker with no valid credentials can invoke privileged internal functions on the VCO host.
• The blast radius is the entire WAN. VCO is not just another server — it is the control plane for your SD-WAN. Compromise of the orchestrator puts every managed Edge, every site-to-site tunnel, and every routing policy within the attacker's reach.
• Exploitation is confirmed in the wild. This is not a theoretical CVSS 10.0. Arista's advisory states the flaw is being actively exploited.

There is one important scoping factor: only orchestrators configured to authenticate their Edges using certificates are affected. If your deployment uses the default/shared-secret style Edge authentication, you are not in the exposed population — but do not assume your configuration without verifying it (verification steps below).

Technical Analysis

Affected Product and Scope

How the Vulnerability Works (Defender's View)

Based on the advisory, the flaw allows a remote, unauthenticated attacker to access or invoke privileged internal functions on the orchestrator, with resulting impact on the VCO host itself. Several defensive conclusions follow from that description:

1. The exposed attack surface is a network-reachable service on the VCO. An unauthenticated remote attacker must be reaching an HTTP(S) or API endpoint — meaning management-plane exposure (internet-facing or flat-network-reachable VCO interfaces) is the deciding factor in exploitability.
2. The flaw lives in the Edge-authentication code path. Because only certificate-based Edge authentication deployments are affected, the vulnerable component almost certainly sits in the logic that handles Edge certificate presentation, validation, or session establishment. Endpoints involved in Edge registration and certificate handshake handling are the highest-value monitoring targets.
3. "Affect the VCO host" implies code execution or host-level control. Invoke-privileged-function vulnerabilities that impact the underlying host typically translate to command execution in the context of the orchestrator service — frequently a service account with broad filesystem and network access on the VCO appliance.

Why This Is a Tier-1 Target

From 15 years of IR work, I can tell you that SD-WAN orchestrators sit in the same target class as VPN concentrators and firewall management planes: they are edge-adjacent, internet-adjacent, trusted by everything, and rarely monitored as endpoints. An attacker inside your VCO can:

• Push malicious configuration or firmware to every Edge in the fleet
• Redirect or intercept site-to-site traffic by altering routing policy
• Harvest credentials, pre-shared keys, and certificate material used by Edges
• Establish persistent, low-noise access that blends into legitimate management traffic

If you run on-prem VCO, treat this with the same urgency you treated the Ivanti and Fortinet management-plane campaigns of the past two years.

Exploitation Status

• Actively exploited in the wild — confirmed by Arista's September 22 disclosure.
• Check the CISA Known Exploited Vulnerabilities (KEV) catalog for CVE-2026-93952; if listed, federal remediation deadlines apply and the due date should drive your internal SLA.
• No public PoC is required for action here — exploitation is already occurring.

Detection & Response

A candid note before the rules: VCO is an appliance-class Linux host, and most organizations have zero endpoint visibility on it. Your highest-fidelity detection opportunities are (a) VCO syslog/audit logs forwarded to your SIEM, (b) network telemetry around the orchestrator, and (c) behavioral anomalies in processes on the host if you have any EDR/scripting access. The detections below are built to be high-signal, not broad.

Sigma Rules

---
title: VeloCloud Orchestrator Service Spawning Suspicious Child Process
id: 3f8a2c91-7b4d-4e6a-9c21-5d8e2f1a6b30
status: experimental
description: Detects web/application service processes on a VeloCloud Orchestrator host spawning shells or system utilities, consistent with post-exploitation of CVE-2026-93952 where an unauthenticated attacker gains host-level execution via the orchestrator service.
references:
  - https://thehackernews.com/2026/09/new-cvss-100-velocloud-orchestrator.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/23
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/java'
      - '/nginx'
      - '/apache2'
      - '/httpd'
      - '/tomcat'
      - '/node'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate VCO maintenance scripts executed during vendor-approved upgrades
  - Health-check automation invoked by the orchestrator service
level: high
---
title: Outbound Connection From VeloCloud Orchestrator to Untrusted Destination
id: 8c1d4e72-3a9f-4b58-a7d3-2e6c9f0b1457
status: experimental
description: Detects the VCO host initiating outbound connections to non-VeloCloud infrastructure. A compromised orchestrator will frequently beacon, download second-stage tooling, or exfiltrate configuration/certificate material after exploitation of CVE-2026-93952.
references:
  - https://thehackernews.com/2026/09/new-cvss-100-velocloud-orchestrator.html
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/09/23
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.exfiltration
  - attack.t1041
logsource:
  category: firewall
  product: linux
detection:
  selection:
    SourceHost|contains: 'vco'
  filter_known_good:
    DestinationHost|contains:
      - 'velocloud.net'
      - 'arista.com'
      - 'aristanetworks.com'
  condition: selection and not filter_known_good
falsepositives:
  - NTP, DNS, and update servers explicitly configured by your organization — tune the filter to your approved egress list
level: medium

Tuning guidance: Rule one is your workhorse — legitimate VCO service processes almost never spawn interactive shells or download utilities outside of vendor upgrade windows. Rule two requires you to build a sanctioned-egress list for your VCO (VeloCloud cloud services, your NTP/DNS, your update mirror). Once tuned, any residual egress from an orchestrator is worth paging on.

KQL (Microsoft Sentinel)

VCO hosts forward syslog via standard collectors, and firewall/CEF data captures orchestrator traffic. This query hunts for unauthenticated-looking request floods and anomalous process execution reported from VCO hosts:

// Hunt 1: High-volume unauthenticated requests against the VCO management/API plane
// (Edge certificate-handling endpoints) from single sources — potential exploitation probing
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceProduct has_any ("VeloCloud", "VCO") or DestinationHostName has_cs "vco"
| where RequestMethod in ("POST", "GET")
| summarize RequestCount = count(),
            DistinctURIs = dcount(RequestURL),
            URIs = make_set(RequestURL, 25)
    by SourceIP, DestinationHostName, bin(TimeGenerated, 15m)
| where RequestCount > 200 or DistinctURIs > 30
| project TimeGenerated, SourceIP, DestinationHostName, RequestCount, DistinctURIs, URIs
| order by RequestCount desc;

// Hunt 2: Shell or downloader execution on orchestrator hosts via ingested syslog
Syslog
| where TimeGenerated > ago(24h)
| where Computer has_cs "vco" or HostName has_cs "vco"
| where ProcessName has_any ("bash", "sh", "dash", "curl", "wget", "nc", "ncat", "python", "perl")
| project TimeGenerated, Computer, ProcessName, ProcessID, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: Unexpected egress from VCO hosts (CEF/firewall) — post-compromise beaconing
let VCO_Hosts = dynamic(["10.0.0.0/8"]); // Replace with your VCO host IPs/subnet
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where SourceIP has_any (VCO_Hosts)
| where DeviceAction !in ("allow", "Allow") or DestinationIP !startswith "10."
| where DestinationIP !startswith "10." and DestinationIP !startswith "172.16." and DestinationIP !startswith "192.168."
| summarize ConnectionCount = count(), Ports = make_set(DestinationPort)
    by SourceIP, DestinationIP, bin(TimeGenerated, 1h)
| order by ConnectionCount desc;

Velociraptor VQL

If you have Velociraptor (or shell-level collection) on the VCO host, this artifact surfaces the post-exploitation footprint — unexpected listeners, service-spawned shells, and recently dropped executables:

-- CVE-2026-93952 VCO post-exploitation hunt: shells under services, odd listeners, fresh binaries
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (CommandLine =~ 'bash|/bin/sh|curl |wget |nc |ncat |python|perl'
   AND Username =~ 'root|www-data|nginx|tomcat|velocloud')
   OR Exe =~ '/tmp/|/dev/shm/|/var/tmp/'

-- Correlate with listening sockets not expected on an orchestrator
SELECT Pid, Name, Family, Type, Status, Laddr, Raddr
FROM netstat()
WHERE Status =~ 'LISTEN|ESTABLISHED'
  AND NOT Laddr.IP =~ '^(127\.|::1)'

-- Recently modified executables/scripts in writable temp paths (common dropper locations)
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/tmp/*', '/var/tmp/*', '/dev/shm/*'])
WHERE Mtime > now() - 86400 * 7
ORDER BY Mtime DESC

Remediation & Hardening Script (Bash)

Run this on your on-prem VCO host (or via your config management tooling) to verify exposure, audit the Edge authentication mode, and restrict the management plane while you schedule the vendor patch. This does not patch the CVE — it reduces attack surface and produces evidence for your IR review:

#!/bin/bash
# CVE-2026-93952 - VeloCloud Orchestrator exposure audit & interim hardening
# Run as root on the on-prem VCO host. Review output before applying firewall changes.

REPORT="/root/vco_cve-2026-93952_audit_$(date +%Y%m%d_%H%M%S).log"
echo "=== VCO CVE-2026-93952 Audit: $(date) ===" | tee "$REPORT"

# 1. Confirm Edge authentication mode (certificate-based = affected population)
echo -e "\n[*] Checking Edge authentication configuration..." | tee -a "$REPORT"
grep -riE 'cert|certificate' /opt/vc/etc/ 2>/dev/null | grep -iE 'edge.*auth|auth.*edge|client.?cert' | tee -a "$REPORT"
echo "[!] If certificate-based Edge auth is ENABLED, this host is in the affected set." | tee -a "$REPORT"

# 2. Enumerate listening services — identify the exposed management/API plane
echo -e "\n[*] Listening TCP services on this host:" | tee -a "$REPORT"
ss -tulnp | tee -a "$REPORT"

# 3. Check whether management ports are reachable from non-management networks
echo -e "\n[*] Current firewall rules touching VCO service ports (80/443/Edge ports):" | tee -a "$REPORT"
iptables -L INPUT -n -v --line-numbers 2>/dev/null | tee -a "$REPORT"

# 4. INTERIM HARDENING: restrict 443/80 to your management subnet ONLY (uncomment to apply)
# MGMT_SUBNET="10.10.0.0/16"
# iptables -I INPUT -p tcp -m multiport --dports 80,443 -s "$MGMT_SUBNET" -j ACCEPT
# iptables -I INPUT -p tcp -m multiport --dports 80,443 -j DROP
# echo "[!] Applied: management plane restricted to $MGMT_SUBNET" | tee -a "$REPORT"

# 5. Hunt for post-exploitation artifacts: recent files in temp dirs, odd processes
echo -e "\n[*] Files modified in temp paths in the last 7 days:" | tee -a "$REPORT"
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls 2>/dev/null | tee -a "$REPORT"
echo -e "\n[*] Shell/downloader processes (possible post-exploitation):" | tee -a "$REPORT"
ps auxf | grep -E 'bash|/bin/sh|curl|wget|ncat|\bnc\b|python|perl' | grep -v grep | tee -a "$REPORT"

# 6. Capture recent authentication/API access logs for IR review
echo -e "\n[*] Recent access log entries (review for unauthenticated hits to internal endpoints):" | tee -a "$REPORT"
tail -n 500 /var/log/nginx/access.log 2>/dev/null | grep -E ' "4[0-9][0-9]| "5[0-9][0-9]' | tail -n 50 | tee -a "$REPORT"

echo -e "\n[+] Audit complete. Report saved to $REPORT"
echo "[+] NEXT: Apply the Arista patch for CVE-2026-93952 per the vendor advisory IMMEDIATELY."

Remediation

This is a CVSS 10.0 with confirmed active exploitation. The remediation order of operations:

1. Patch — Immediately

• Apply the Arista security update for CVE-2026-93952 on all on-premises VCO instances. Pull the exact fixed version and upgrade instructions directly from the official vendor channels:
  • Arista Security Advisories: https://www.arista.com/en/support/advisories-notices
  • VeloCloud Support / advisory reference from the disclosure: https://thehackernews.com/2026/09/new-cvss-100-velocloud-orchestrator.html
• Do not wait for a maintenance window that is more than days out. If your VCO is internet-reachable, treat this as an emergency change.

2. Verify Whether You're in the Affected Population

• The flaw only impacts orchestrators configured for certificate-based Edge authentication. Confirm your Edge authentication mode in the VCO configuration (Operator Properties / system properties) or via the audit script above.
• Do not interpret "not affected" as "no action needed" — verify, document the finding, and still patch at the next available window. Configuration drift happens.

3. Remove Internet Exposure of the Management Plane (Permanent Control)

• The VCO management and API interfaces should never be reachable from the public internet. Place them behind a management VPN, jump host, or IP allow-list restricted to NOC/SOC management subnets.
• Edge-facing communication ports should be restricted to known Edge source ranges and VeloCloud Gateway infrastructure where feasible.
• Egress-filter the VCO host. An orchestrator has a short, enumerable list of legitimate destinations (VeloCloud cloud services, NTP, DNS, update servers). Everything else should fail closed — this single control breaks most post-exploitation C2.

4. Hunt Before You Patch — Assume Compromise

Because exploitation predates the patch, patching alone does not evict an attacker. Before or immediately after patching:

• Run the VQL/pslist hunts above on the VCO host.
• Review VCO access and audit logs for unauthenticated requests to internal/administrative endpoints, particularly around Edge certificate-handling paths, going back at least 30 days.
• Review Edge configuration change history for unauthorized pushes — altered routes, DNS settings, new administrator or operator accounts, unexpected firmware/version changes.
• If you find evidence of compromise: rotate Edge certificates and any credentials/keys stored on or distributed by the orchestrator, and treat every configuration object the VCO can push as suspect.

5. Monitoring Going Forward

• Forward VCO syslog and web access logs to your SIEM — appliance blind spots are why management-plane compromises dwell for months.
• Deploy the Sigma/KQL detections above, tuned to your sanctioned-egress baseline.
• Track CVE-2026-93952 in the CISA KEV catalog; if added, enforce the associated remediation deadline internally even if you're not bound by BOD 22-01.

Bottom Line

A perfect-score, unauthenticated, actively exploited flaw in the control plane of your WAN is a page-the-on-call event. Verify your Edge authentication mode, patch per Arista's advisory, pull the management plane off any exposed network segment, and hunt for pre-patch compromise. Orchestrators, like VPN concentrators and firewall managers before them, are now firmly in the first wave of targets — your visibility and segmentation strategy needs to reflect that.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub