Arista VeloCloud Orchestrator Zero-Day Actively Exploited: Detection, Hunting, and Remediation Guide for On-Prem VCO Deployments

Arista Networks has released emergency security patches for a previously unpatched vulnerability in its VeloCloud Orchestrator (VCO) On-Premises deployments — and this is not a theoretical exercise. According to reporting from BleepingComputer, the flaw was being actively exploited in the wild at the time the fix shipped. If you operate an on-prem VeloCloud Orchestrator to manage your SD-WAN fabric, treat this as an incident-response-grade event, not a routine patch cycle item.

Orchestrators are the crown jewels of any SD-WAN architecture. VCO holds your edge device inventory, network segmentation policy, certificates, BGP/OSPF configuration, and the management plane trust relationships for every gateway and edge in the fleet. A compromise here is not a single-host event — it is potential control of the entire WAN overlay. We have seen this movie before with other network management platforms: attackers who land on the orchestrator can push malicious configuration, harvest credentials, establish persistent access across distributed sites, and pivot into environments that are otherwise well segmented. That is exactly why edge and management-plane appliances have become the preferred initial-access target for both criminal and state-aligned operators.

Technical Analysis

What is affected

• Product: Arista VeloCloud Orchestrator (VCO), On-Premises deployments (self-hosted VCO instances — this is distinct from the Arista-hosted cloud orchestrator, where patching is handled by the vendor).
• Exposure profile: VCO instances reachable from untrusted networks, particularly those with the management UI or API exposed beyond a dedicated management segment, carry the highest risk. However, exploitation into the management plane from a compromised edge or gateway is also a realistic path in flat management networks.
• Exploitation status: Confirmed active exploitation. This was a zero-day — attackers were using it before a vendor fix existed. Per Arista's advisory, on-prem customers must apply the patch themselves; hosted orchestrator customers are covered by Arista's cloud operations.

Note: At the time of this writing, the vendor advisory and initial reporting describe the vulnerability without a publicly assigned CVE in the source material. Track Arista's security advisory page for the formal identifier and affected version matrix as it is published, and map it against your VCO build string (System Properties / About page in the orchestrator UI) before declaring yourself clean.

Why the management plane is the real target

From a defender's perspective, assume the following post-exploitation behavior on a compromised VCO host — this is what we hunt for regardless of the specific exploit primitive:

1. Web-tier initial access → command execution in the context of the orchestrator's application services (Java/Tomcat-based processes on the VCO Linux appliance).
2. Webshell or payload staging → unexpected files written under web/application directories, or child processes (shells, interpreters, downloaders) spawned by the application service account.
3. Credential and config theft → reads of orchestrator configuration, database dumps, or certificate stores that would enable edge impersonation or management-plane persistence.
4. Egress C2 → outbound connections from the orchestrator host to infrastructure that is not Arista cloud services, your NTP/DNS, or your patch repositories. A VCO host has a very predictable network profile — deviations are high-signal.

That last point is your biggest defensive advantage: a healthy orchestrator talks to a small, enumerable set of destinations. Baseline it, and anomaly detection becomes cheap.

Detection & Response

The detections below target post-exploitation behavior on and around the VCO appliance — application processes spawning shells, webshell-style file writes, and unexpected egress — because those observables survive even when the exact exploit primitive changes. If your VCO forwards syslog (configure it to — System Properties > Syslog), ingest it into Sentinel via CEF/Syslog. If you have EDR or an agent on the VCO host, the Sigma and VQL content applies directly.

Sigma Rules

---
title: VeloCloud Orchestrator Application Process Spawning Shell or Interpreter
id: 3f8a2c91-7b4e-4d12-9a5f-6c1e2b8d9034
status: experimental
description: Detects shells, script interpreters, or download utilities spawned by Java/Tomcat or web server processes on a Linux host, consistent with webshell or post-exploitation activity against a VeloCloud Orchestrator appliance.
references:
  - https://www.bleepingcomputer.com/news/security/arista-patches-actively-exploited-velocloud-orchestrator-zero-day/
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/java'
      - '/java.exe'
      - '/catalina.sh'
      - '/nginx'
      - '/httpd'
      - '/apache2'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Orchestrator maintenance scripts invoked by the application during upgrades or diagnostics - validate against change windows
level: high
---
title: Suspicious File Write to VeloCloud Orchestrator Web or Application Directories
id: 8c4d1e57-2a9b-4f36-b7e1-9d3a5c0f6128
status: experimental
description: Detects creation of script or executable files under VeloCloud Orchestrator installation and web-serving paths, indicative of webshell deployment following exploitation of the orchestrator application.
references:
  - https://www.bleepingcomputer.com/news/security/arista-patches-actively-exploited-velocloud-orchestrator-zero-day/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.t1190
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/opt/vco/'
      - '/opt/velocloud/'
      - '/var/www/'
      - '/usr/share/nginx/'
      - '/webapps/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.php'
      - '.sh'
      - '.py'
      - '.war'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate VCO software upgrades and hotfix deployments - correlate with vendor patch activity and maintenance windows
level: high

KQL (Microsoft Sentinel / Defender)

This hunt assumes you are forwarding VCO appliance syslog into Sentinel (CEF or Syslog table) and/or have network telemetry for the orchestrator host. It looks for unexpected outbound destinations from the VCO — the highest-signal, lowest-noise indicator available for an appliance with a predictable network profile.

// Hunt: Unexpected egress from VeloCloud Orchestrator host(s)
// Step 1 - define your VCO hosts and their known-good destinations (Arista cloud, NTP, DNS, repo, SIEM)
let VCOHosts = dynamic(["vco01.corp.local", "10.20.30.40"]);       // <-- replace with your orchestrator hostnames/IPs
let KnownGoodDests = dynamic(["13.107.0.0/16"]);                   // <-- replace with Arista cloud ranges, your DNS/NTP/SIEM
let KnownBadPorts = dynamic(["22", "4444", "8080", "8443", "1337", "6667"]);
union isfuzzy=true
    (CommonSecurityLog
    | where SourceIP in~ (VCOHosts) or SourceHostName in~ (VCOHosts)
    | where DeviceAction !in~ ("deny", "drop")
    | where not(DestinationIP has_any (KnownGoodDests))
    | where ipv4_is_private(DestinationIP) == false
    | project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, SentBytes, ReceivedBytes),
    (Syslog
    | where HostName in~ (VCOHosts)
    | where SyslogMessage has_any ("curl", "wget", "bash -i", "/dev/tcp", "nc ", "chmod +x", "base64 -d")
    | project TimeGenerated, HostName, ProcessName, SyslogMessage)
| order by TimeGenerated desc

If you run Defender for Endpoint on Linux management hosts or have network device logs, also hunt for process ancestry:

// Hunt: Web/app service spawning shells or downloaders (any Linux server telemetry in MDE)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("java", "nginx", "httpd", "apache2")
| where FileName has_any ("bash", "sh", "python", "perl", "curl", "wget", "nc", "ncat")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName, InitiatingProcessCommandLine
| order by TimeGenerated desc

Velociraptor VQL

If you can deploy Velociraptor (or run a collection via a management jump box) against the VCO host or adjacent Linux infrastructure, this artifact hunts the two most durable artifacts: suspicious child processes of the application tier and recently written script/executable files under orchestrator paths.

-- Hunt: Post-exploitation artifacts on VeloCloud Orchestrator host
-- 1) Shells/interpreters/downloaders spawned by the Java/web application tier
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(bash|/bin/sh|python|perl|curl|wget|nc |ncat|base64 -d)'
  AND (Name =~ '(?i)java|nginx|httpd|apache'
       OR CommandLine =~ '/opt/vco/|/opt/velocloud/')

-- 2) Recently created script/executable files under orchestrator and web paths
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/opt/vco/**/*.jsp', '/opt/vco/**/*.sh', '/opt/vco/**/*.py',
                 '/opt/velocloud/**/*.jsp', '/var/www/**/*.sh', '/var/www/**/*.jsp',
                 '/usr/share/nginx/**/*.sh', '**/webapps/**/*.jsp'])
WHERE Mtime > now() - 1209600  -- last 14 days
ORDER BY Mtime DESC

-- 3) Unexpected established outbound connections from the host
SELECT Pid, Name, Status, Family, LocalAddress, LocalPort, RemoteAddress, RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
  AND NOT RemoteAddress =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[0-1])\\.|127\\.)'

Verification & Hardening Script

Run on the VCO appliance (or your Linux management hosts) to inventory the current state, enumerate the network baseline, and pull quick triage artifacts before and after patching:

#!/bin/bash
# VeloCloud Orchestrator - pre/post patch triage and baseline (run as root or via sudo)
OUT=/var/log/vco_triage_$(date +%Y%m%d_%H%M%S); mkdir -p "$OUT"

# 1) Record current VCO version/build for advisory comparison
echo "=== VCO version info ===" | tee "$OUT/version.txt"
cat /opt/vco/etc/version 2>/dev/null | tee -a "$OUT/version.txt"
hostnamectl | tee -a "$OUT/version.txt"

# 2) Established outbound connections (baseline for egress anomaly hunting)
ss -tunp state established > "$OUT/established_conns.txt"

# 3) Recently modified files under orchestrator/web paths (last 14 days)
find /opt/vco /opt/velocloud /var/www /usr/share/nginx -type f -mtime -14 \
  \( -name '*.jsp' -o -name '*.sh' -o -name '*.py' -o -name '*.war' \) \
  -exec ls -la {} \; > "$OUT/recent_webapp_files.txt" 2>/dev/null

# 4) Non-standard local accounts and recent sudo/auth activity
awk -F: '$3 >= 1000 || $3 == 0 {print}' /etc/passwd > "$OUT/local_accounts.txt"
grep -E 'session opened|COMMAND=' /var/log/auth.log 2>/dev/null | tail -n 200 > "$OUT/auth_recent.txt"

# 5) Crontab/systemd persistence review
crontab -l > "$OUT/root_crontab.txt" 2>/dev/null
ls -la /etc/cron.d/ > "$OUT/cron_d.txt"
systemctl list-unit-files --state=enabled > "$OUT/enabled_units.txt"

echo "Triage bundle written to $OUT - review before and after applying the Arista patch."

Remediation

1. Patch immediately. Apply the security update Arista released for affected on-prem VeloCloud Orchestrator versions per the official advisory: consult Arista's security advisories portal (https://www.arista.com/en/support/advisories-notices) and the BleepingComputer report for the fixed build numbers. Do not wait for a scheduled maintenance window — this is confirmed in-the-wild exploitation of an internet-relevant management plane. Arista-hosted (cloud) orchestrator customers are patched by the vendor; on-prem is on you.
2. Verify the patch landed. Confirm the post-patch build string in the orchestrator UI and against the advisory's fixed-version list. Re-run the triage script above after patching and diff against your pre-patch baseline.
3. Assume breach until proven otherwise. Because exploitation predated the patch, patching alone does not evict an attacker. Review the orchestrator host for webshells, rogue local accounts, persistence (cron/systemd), and the egress anomalies described above. Check the VCO audit logs for unauthorized administrative logins, unexpected configuration pushes to edges/gateways, new or modified operator accounts, and API token creation.
4. Rotate credentials and certificates. If any compromise indicator is found — or if your VCO was internet-exposed and unpatched during the exploitation window — rotate operator credentials, API keys/tokens, and evaluate re-issuing edge/gateway certificates and any secrets stored in orchestrator profiles.
5. Restrict management-plane exposure (permanent). The orchestrator UI and API must never be reachable from the general internet. Place VCO behind a dedicated management VRF/VLAN, enforce allowlist-based ACLs at the perimeter, require VPN/jump-host access with MFA for operator sessions, and permit outbound traffic from the VCO host only to explicitly required Arista/cloud destinations.
6. Enable and centralize logging. Configure VCO syslog forwarding to your SIEM (CEF format for Sentinel ingestion), retain orchestrator audit logs off-box, and ensure edge/gateway logs are collected so configuration-change timelines can be reconstructed.
7. Monitor for KEV listing and advisory updates. Actively exploited vulnerabilities of this class are routinely added to CISA's Known Exploited Vulnerabilities catalog with a mandated remediation deadline for federal agencies — and that deadline is a useful forcing function for private-sector SLAs too. Track the Arista advisory for the formal CVE assignment and any expanded affected-version guidance.

Bottom Line

Management-plane appliances — SD-WAN orchestrators, firewalls, VPN concentrators — are where attackers are concentrating effort in 2025–2026 because one successful exploit yields disproportionate control. An unauthenticated or low-complexity flaw in VCO, exploited before a patch existed, is a worst-case scenario for on-prem operators. Patch now, hunt for the post-exploitation behaviors above rather than waiting for IOCs specific to this campaign, and use this event to justify the segmentation and egress-control work on your management plane that has probably been sitting in a backlog.

Related Resources

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