Arista VeloCloud Orchestrator Zero-Day Under Active Exploitation: On-Prem VCO Detection and Remediation Guide

Arista Networks has released emergency security updates for a zero-day vulnerability in VeloCloud Orchestrator (VCO) On-Prem deployments that threat actors are already exploiting in real-world attacks. If your organization operates a self-hosted VCO instance to manage your SD-WAN fabric, you should treat this as an urgent, patch-today event — and then hunt for evidence of prior compromise, because patching does not remove an attacker who already got in.

SD-WAN orchestrators sit at an exceptionally privileged position in the enterprise network. They push configurations to every edge device, hold credentials and tunnel material for site-to-site connectivity, and often have reach into both the WAN underlay and the management plane. A compromised orchestrator is not just a compromised server — it is a potential springboard into every branch, every edge gateway, and every network segment the fabric touches. That is why nation-state and financially motivated actors alike have made edge and network management infrastructure a priority target over the last several years, and why this vulnerability demands immediate attention.

Technical Analysis

What is affected

• Product: Arista VeloCloud Orchestrator (VCO), On-Premises deployments (the self-hosted appliance/virtual machine variant)
• Not affected / lower risk: Arista's cloud-hosted (SaaS) Orchestrator instances, which are patched by the vendor — but customers should verify their tenant status via the Arista support portal
• Component: The vulnerability resides in the VCO management stack. Based on the advisory and the exploitation pattern reported, the issue affects the externally reachable management interface, which is typically exposed for operator access and, in some (misconfigured) deployments, exposed directly to the internet

Arista's advisory indicates the flaw can be exploited to compromise the orchestrator host itself. Because Arista has confirmed active exploitation in the wild prior to patch availability, this qualifies as a true zero-day event — defenders had no head start, and internet-facing on-prem VCO instances should be presumed potentially compromised until proven otherwise.

How the attack works (defender's view)

While Arista has (appropriately) withheld granular exploit details to slow weaponization, the observable attack chain against network appliance zero-days of this class follows a consistent pattern that defenders can instrument for:

1. Initial access: Crafted requests to the VCO management web interface, bypassing authentication or abusing a logic flaw in request handling
2. Code execution: The VCO appliance is a Linux-based system running a Java/Tomcat application stack behind an nginx reverse proxy. Successful exploitation typically manifests as the web-tier process (Java/Tomcat or nginx worker) spawning unexpected child processes — shells, interpreters, curl/wget for payload staging
3. Persistence: Attackers frequently write webshells into the web application's document root or drop systemd units/cron entries for durable access
4. Follow-on actions: Credential harvesting from VCO's configuration database, reconnaissance of managed edges, and outbound C2 from the appliance to attacker infrastructure

The exploitation requirements matter for triage: if the management interface was reachable from untrusted networks, assume exposure. If it was segmented to a management VLAN with tight ACLs, your risk profile drops substantially — but does not go to zero, since an attacker already inside your network could have reached it.

Exploitation status

• Status: Confirmed active exploitation in the wild (zero-day at time of patch release)
• PoC: No public proof-of-concept at time of writing, but in-the-wild exploitation means the barrier to entry for additional actors will fall quickly
• CISA KEV: Monitor the CISA Known Exploited Vulnerabilities catalog — actively exploited appliance flaws of this class are routinely added, which triggers binding remediation deadlines for federal agencies and should be treated as a deadline by everyone else

Detection & Response

The highest-fidelity detection logic for this threat class centers on the web-tier process spawning shells or tools, webshell artifacts in the application tree, and unexpected egress from the appliance. The following content assumes you are forwarding VCO appliance syslog to your SIEM and, ideally, running an EDR/osquery/Velociraptor capability on the underlying host where support agreements permit.

Sigma Rules

---
title: VeloCloud Orchestrator Web Process Spawning Shell or Interpreter
id: 3f8a2b71-6c4d-4e9f-b1a2-9d7c5e3f8012
status: experimental
description: Detects the VCO web-tier (Java/Tomcat/nginx) spawning shells, interpreters, or download tools, consistent with exploitation of a management interface vulnerability leading to command execution.
references:
  - https://www.bleepingcomputer.com/news/security/arista-patches-new-velocloud-orchestrator-zero-day-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'java'
      - 'tomcat'
      - 'nginx'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'curl '
      - 'wget '
      - 'python'
      - 'perl '
      - 'nc '
      - 'base64 -d'
  condition: selection_parent and selection_child
falsepositives:
  - VCO health-check or orchestration scripts invoked by the application tier — baseline known-good child processes per deployment
level: high
---
title: Webshell Artifact Written to VCO Web Application Directories
id: 8c1d4e6a-2b7f-4a93-8d5e-4f6b1c9a2034
status: experimental
description: Detects creation of script files (JSP/PHP/sh) in VeloCloud Orchestrator web application directories, a common persistence step following management-interface exploitation.
references:
  - https://www.bleepingcomputer.com/news/security/arista-patches-new-velocloud-orchestrator-zero-day-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/opt/vc/'
      - '/var/www/'
      - 'webapps/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.php'
      - '.sh'
      - '.war'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate VCO software updates and hotfix application — correlate with change windows
level: high
---
title: Outbound Connection From VCO Appliance to Rare External Destination
id: 5e2f7a19-3d8c-4b61-9f4a-7c2e8d1b6056
status: experimental
description: Detects network egress from the VCO host that is inconsistent with expected SD-WAN management, licensing, and update flows, potentially indicating C2 or payload staging after compromise.
references:
  - https://www.bleepingcomputer.com/news/security/arista-patches-new-velocloud-orchestrator-zero-day-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: network_connection
  product: linux
detection:
  selection_process:
    Image|contains:
      - 'java'
      - 'curl'
      - 'wget'
      - 'python'
      - 'perl'
      - 'nc'
  filter_expected:
    DestinationHostname|contains:
      - 'velocloud.net'
      - 'arista.com'
      - 'vmware.com'
  condition: selection_process and not filter_expected
falsepositives:
  - NTP/DNS infrastructure, internal update mirrors — add environment-specific destinations to the filter
level: medium

KQL — Microsoft Sentinel / Defender

This hunt assumes VCO appliance syslog is ingested via the Syslog or CommonSecurityLog (CEF) connector, and process telemetry is available via DeviceProcessEvents if the host is onboarded. It looks for the web-tier-to-shell execution pattern and outbound connections from the appliance to destinations outside the known VeloCloud/Arista service domains.

let vcoHosts = dynamic(["vco", "velocloud", "orchestrator"]);
// Stage 1: web-tier spawning shells or staging tools (Linux audit/syslog process events)
let suspiciousProcs = Syslog
| where TimeGenerated > ago(14d)
| where Computer has_any (vcoHosts)
| where SyslogMessage has_any ("java", "tomcat", "nginx")
    and SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "base64 -d", "python", "nc ")
| project TimeGenerated, Computer, ProcessName, SyslogMessage;
suspiciousProcs
| union (
    // Stage 2: egress from VCO appliance to non-vendor destinations (firewall/CEF feed)
    CommonSecurityLog
    | where TimeGenerated > ago(14d)
    | where DeviceProduct has_any ("firewall", "fw", "proxy") or DeviceVendor =~ "Arista"
    | where SourceHostName has_any (vcoHosts) or SourceIP in (extract_all(@"vco", dynamic(["vco"]), SourceHostName))
    | where not (DestinationHostName has_any ("velocloud.net", "arista.com", "vmware.com") or DestinationIP startswith "10." or DestinationIP startswith "192.168.")
    | summarize Connections=count(), Destinations=make_set(DestinationHostName, 20) by SourceIP, DestinationIP, DestinationPort, bin(TimeGenerated, 1h)
)
| order by TimeGenerated desc

Tune the vcoHosts dynamic array to your actual appliance hostnames before deploying; the union structure lets you review process and network anomalies side by side for correlation.

Velociraptor VQL

For DFIR teams with Velociraptor (or osquery-compatible tooling) deployed to the VCO host — or performing a live forensic collection during triage — this artifact hunts for the two most reliable post-exploitation artifacts: shell processes parented to the web tier, and recently written script files in web application paths.

-- Hunt: VCO post-exploitation — web-tier child shells and webroot script artifacts
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Exe =~ '(?i)(sh|bash|dash|python|perl|curl|wget|nc)$'
   OR CommandLine =~ '(?i)base64\s+-d|/dev/tcp/|/tmp/')
  AND (
    -- Flag shells/tools whose parent is the web/app tier
    Ppid IN (
      SELECT Pid FROM pslist()
      WHERE Name =~ '(?i)(java|tomcat|nginx)'
    )
    OR CommandLine =~ '(?i)(/opt/vc|webapps|/var/www)'
  )

-- Hunt: recently created script/war files in VCO web application paths
SELECT FullPath, Size, Mtime, Ctime, Btime
FROM glob(globs=[
  '/opt/vc/**/*.jsp',
  '/opt/vc/**/*.war',
  '/var/www/**/*.jsp',
  '/**/webapps/**/*.jsp',
  '/**/webapps/**/*.sh'
])
WHERE Mtime > (now() - 1209600)  -- last 14 days
ORDER BY Mtime DESC

Verification and Hardening Script

Run the following on the VCO host (or via your configuration management tooling) to confirm the appliance is running a patched build, check for the most common post-exploitation artifacts, and verify the management interface is not internet-exposed. Adjust paths to match your deployment's install root.

#!/bin/bash
# vco_triage.sh — VeloCloud Orchestrator zero-day triage & verification
# Run as root on the VCO appliance. Review output before taking action.

echo "=== [1] VCO version check ==="
# Confirm against Arista advisory fixed-version list
/opt/vc/bin/vco_version.sh 2>/dev/null || rpm -qa | grep -i velocloud || dpkg -l | grep -i velocloud

echo "=== [2] Web-tier spawning shells (last 24h of process accounting) ==="
ps -eo pid,ppid,comm,args --forest | grep -Ei "java|tomcat|nginx" -A2 | grep -Ei "bash|sh$|curl|wget|python|perl" || echo "No suspicious children found"

echo "=== [3] Recently modified script files in web paths ==="
find /opt/vc /var/www -type f \( -name "*.jsp" -o -name "*.sh" -o -name "*.war" -o -name "*.php" \) -mtime -14 2>/dev/null

echo "=== [4] Unexpected persistence mechanisms ==="
crontab -l 2>/dev/null; ls -la /etc/cron.d/ 2>/dev/null
systemctl list-unit-files --state=enabled | grep -viE "velocloud|vco|sshd|cron|rsyslog|network"

echo "=== [5] Egress connections from web-tier processes ==="
ss -tnp | grep -Ei "java|curl|wget|python" | grep -vE "127.0.0.1|::1"

echo "=== [6] Management interface exposure check ==="
# The VCO management UI should NOT be reachable from untrusted networks.
ip -4 addr show | grep inet
iptables -L INPUT -n -v 2>/dev/null | head -30

echo "=== [7] Authentication log anomalies ==="
grep -Ei "failed|accepted|invalid" /var/log/secure 2>/dev/null | tail -50
journalctl -u sshd --since "14 days ago" 2>/dev/null | grep -Ei "failed|accepted" | tail -30

Remediation

1. Patch immediately. Apply the fixed VCO build per Arista's security advisory — obtain the advisory and upgrade images through the Arista support portal or the VeloCloud support portal using your entitlement. Confirm the exact fixed version against the advisory for your VCO release train before scheduling the upgrade, and validate post-upgrade with the version check in the script above.
2. Assume breach for exposed instances. If your VCO management interface was reachable from the internet or from broad internal segments before patching, initiate an IR scoping exercise: collect the artifacts in Section 5, image the host if indicators surface, and rotate all credentials the orchestrator holds or touches — edge device credentials, API tokens, RADIUS/TACACS secrets, certificates, and any admin accounts with VCO access.
3. Restrict management-plane exposure. The VCO UI and API should live behind a dedicated management network with ACLs or a firewall permitting only known operator subnets and jump hosts. If remote administration is required, put it behind VPN/ZTNA with MFA. Verify no NAT rule or security group exposes TCP/443 on the VCO management address to the internet (check with an external scan, not just config review).
4. Audit managed edges. Because the orchestrator pushes configuration to every gateway and edge, review recent configuration change logs in VCO for unauthorized modifications — new tunnels, modified firewall rules, added admin accounts, or changed DNS/NTP settings — across all managed devices.
5. Enable and centralize logging. Forward VCO appliance syslog, authentication logs, and web-tier access logs to your SIEM with at least 90 days of retention. If you could not answer "what hit my VCO in the last two weeks" today, that gap is itself a finding.
6. Monitor CISA KEV. Given confirmed in-the-wild exploitation, expect a KEV listing; if added, federal remediation deadlines apply to FCEB agencies and the deadline is a sound internal SLA for everyone else.
7. Subscribe to Arista security notifications. Ensure your NOC/SOC distribution list is on Arista's security advisory feed so future VCO advisories reach operators, not just procurement contacts.

Related Resources

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