Arista has issued an urgent advisory directing customers to immediately patch a critical-severity vulnerability in its VCO component. Per reporting from SecurityWeek, remote attackers can trigger the flaw to access privileged internal functionality — and the vulnerability is being exploited in the wild as a zero-day.
Let me be direct about what this means for defenders: network infrastructure devices are the crown jewels of any environment. They sit at trust boundaries, handle all traffic, are rarely monitored with the same rigor as endpoints, and almost never have EDR coverage. When a vendor uses language like "urges immediate patching" alongside confirmed exploitation, that is the strongest signal you will get short of a CISA emergency directive. If you run affected Arista gear, this is a drop-everything event.
Technical Analysis
What We Know
- Affected component: Arista's VCO component. Organizations must consult Arista's official security advisory (available via the Arista support portal and advisories page) to confirm whether their deployed versions and configurations are in scope.
- Severity: Critical, per the vendor.
- Attack vector: Remote. An attacker can trigger the flaw over the network without prior access to the device.
- Impact: Access to privileged internal functionality — in practical terms, this class of bug on a network device typically translates to administrative control, configuration manipulation, traffic interception or redirection, and a durable foothold for lateral movement.
- Exploitation status: Actively exploited in the wild as a zero-day prior to patch availability. This is not theoretical. Expect that exploitation details will proliferate rapidly now that the patch and advisory are public — the window between "patch released" and "mass scanning/exploitation" for network edge devices has shrunk to days, sometimes hours, in recent campaigns.
Why Network Device Compromises Are Especially Dangerous
From 15 years of IR work, I can tell you the pattern is consistent: once an adversary owns a switch, router, or controller, they gain capabilities that endpoint-focused security stacks simply cannot see:
- Persistence below the security tooling layer. There is no CrowdStrike or Defender agent on your network fabric. Implants on network devices survive endpoint reimaging entirely.
- Traffic manipulation. A compromised device can mirror, redirect, or tamper with traffic — including authentication flows — enabling credential theft at scale.
- Lateral movement launchpad. Management interfaces of network devices typically have trusted access to other infrastructure. Attackers pivot from device to device and then into server and user VLANs.
- Forensic blindness. Most organizations do not centralize network device syslog, do not baseline device configurations, and cannot answer basic questions like "when did this local account get created?" during an investigation.
Assume that any unpatched, internet-reachable or broadly reachable VCO instance has been probed, and if indicators of compromise are present, treat the device and any credentials it touches as compromised.
Detection & Response
Detection for network device exploitation is imperfect — the device itself is the compromised asset, so your best telemetry sources are upstream syslog forwarding, firewall/NetFlow data on management-plane traffic, and configuration change auditing. The following detections focus on the post-exploitation behaviors that matter: unexpected management-plane access, new privileged accounts, and unauthorized configuration changes.
Sigma Rules
---
title: Arista Device New Local Account or Privilege Change via Syslog
id: 3f8a2b71-6c4d-4e59-9a10-8b7c5d2e1f09
status: experimental
description: Detects syslog messages from Arista network devices indicating creation of local user accounts or privilege-level changes, a common post-exploitation persistence action following management-plane compromise such as the exploited VCO zero-day.
references:
- https://www.securityweek.com/arista-urges-immediate-patching-of-exploited-vco-zero-day/
- https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1136.001
logsource:
product: linux
service: syslog
detection:
selection_device:
Host|contains:
- 'arista'
- 'eos'
- 'sw-'
- 'leaf'
- 'spine'
selection_event:
Message|contains:
- 'USER_ADD'
- 'user added'
- 'created user'
- 'privilege 15'
- 'username '
- 'ROLE_ADD'
- 'privilege level'
condition: selection_device and selection_event
falsepositives:
- Legitimate administration via automation (Ansible, CVP) - correlate with change tickets
level: high
---
title: Configuration Change on Network Device Outside Change Window
id: 9c1d4e62-2f7a-4b38-a645-0e9f3a1b7c24
status: experimental
description: Detects configuration modification syslog events from network devices. Exploitation of the Arista VCO flaw grants privileged internal functionality; adversaries typically modify running configuration, ACLs, or AAA settings to maintain access.
references:
- https://www.securityweek.com/arista-urges-immediate-patching-of-exploited-vco-zero-day/
- https://attack.mitre.org/techniques/T1562/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1562
logsource:
product: linux
service: syslog
detection:
selection:
Message|contains:
- 'CONFIG_CHANGE'
- 'configuration committed'
- 'running-config'
- 'startup-config'
- 'CLI session'
- 'AAA'
- 'tacacs'
- 'radius'
- 'no logging'
- 'logging buffered'
- 'ip access-list'
condition: selection
falsepositives:
- Scheduled configuration management by network engineering - alert on events outside approved change windows
level: medium
---
title: Management Plane Access to Network Device from Non-Management Host
id: 5e7b9f03-1a48-4c92-bd31-6f2a8c4d9e15
status: experimental
description: Detects connections to network device management services (SSH, eAPI/HTTPS) originating from endpoints outside the designated management subnet or jump hosts. Relevant to exploitation attempts against exposed Arista VCO functionality.
references:
- https://www.securityweek.com/arista-urges-immediate-patching-of-exploited-vco-zero-day/
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1190
logsource:
category: firewall
detection:
selection:
dst_port:
- 22
- 443
- 6060
- 6030
dst_ip|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
filter_management:
src_ip|cidr:
- '10.10.99.0/24'
condition: selection and not filter_management
falsepositives:
- Legitimate administration from unmanaged subnets - tune filter_management to your actual management VLAN/jump hosts
level: high
Important tuning note: the third rule's filter_management CIDR is a placeholder. Replace it with your actual management VLAN and jump-host ranges before deployment, or it will alert on everything and get disabled within a week.
KQL — Microsoft Sentinel Hunt
If you forward Arista EOS syslog to Sentinel (via a Linux syslog collector or CEF), this query surfaces the highest-value post-exploitation signals: account creation, config changes, and management sessions from unusual sources.
// Hunt: Suspicious activity on Arista network devices - VCO zero-day post-exploitation
// Requires Arista EOS syslog forwarded to Sentinel via Syslog or CommonSecurityLog (CEF)
let lookback = 14d;
let AristaSyslog =
Syslog
| where TimeGenerated > ago(lookback)
| where Computer has_any ("arista", "eos", "sw-", "leaf", "spine")
or SyslogMessage has_any ("%SYS-", "ACL-", "AGENT-", "Config");
let SuspiciousEvents =
AristaSyslog
| where SyslogMessage has_any (
"USER_ADD", "user added", "privilege 15", "username ",
"CONFIG_CHANGE", "running-config", "startup-config",
"no logging", "tacacs", "radius",
"Login success", "SSH login", "eAPI")
| extend EventType = case(
SyslogMessage has_any ("USER_ADD", "user added", "username "), "Account Creation",
SyslogMessage has_any ("CONFIG_CHANGE", "running-config", "startup-config"), "Config Change",
SyslogMessage has_any ("no logging"), "Logging Tampering",
SyslogMessage has_any ("Login success", "SSH login", "eAPI"), "Management Session",
"Other")
| project TimeGenerated, Computer, EventType, SyslogMessage, ProcessName;
SuspiciousEvents
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by Computer, EventType
| order by LastSeen desc;
// Pivot: management-plane connections to Arista devices from non-management sources (via firewall CEF logs)
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where DestinationPort in (22, 443, 6060, 6030)
| where DeviceAction == "permit" or DeviceAction == "allow"
// TODO: restrict DestinationIP to your Arista device management IPs and exclude your management VLAN
| summarize ConnectionCount = count(), Sources = make_set(SourceIP, 20) by DestinationIP, DestinationPort
| order by ConnectionCount desc;
Velociraptor VQL — Hunt Admin Workstations
Velociraptor cannot run on the network devices themselves, but it can hunt the management workstations and jump hosts attackers target when pivoting to network infrastructure. This artifact identifies non-standard processes holding connections to device management ports — a classic sign of an attacker operating from a compromised admin endpoint rather than a sanctioned jump box.
-- Hunt: Non-standard processes with connections to network device management ports
-- Context: Arista VCO exploitation / management-plane pivoting
-- Expected clients: ssh.exe, putty.exe, SecureCRT, browser processes (for eAPI/HTTPS)
LET AllowedClients = ('ssh.exe', 'putty.exe', 'plink.exe', 'SecureCRT.exe', 'msedge.exe', 'chrome.exe', 'firefox.exe')
SELECT Pid,
Name AS ProcessName,
Exe AS ProcessPath,
Username,
CommandLine,
netstat.RemoteIP AS RemoteIP,
netstat.RemotePort AS RemotePort,
netstat.Status AS ConnState
FROM pslist()
JOIN (SELECT Pid AS NPid, RemoteIP, RemotePort, Status FROM netstat()
WHERE RemotePort IN (22, 443, 6060, 6030)
AND Status = 'ESTABLISHED'
AND RemoteIP =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)') AS netstat
ON pslist().Pid = netstat.NPid
WHERE NOT ProcessName IN AllowedClients
Verification & Hardening Script (Bash)
This script runs from a management host against your Arista EOS devices via CLI (SSH). It inventories versions, lists local accounts (look for ones you don't recognize), dumps recent configuration-change and login history, and applies a restrictive management ACL as an interim compensating control if you cannot patch immediately. Review before running — this touches production config.
#!/bin/bash
# Arista VCO zero-day - verification and interim hardening
# Run from a trusted management host. Requires SSH access to EOS devices.
# USAGE: ./arista_vco_check.sh devices.txt
# devices.txt = one device IP/hostname per line
DEVICE_LIST="$1"
ADMIN_USER="netops_admin" # change to your admin account
while read -r DEV; do
echo "=================================================="
echo "[*] Auditing $DEV"
# 1. Capture software version - compare against Arista advisory fixed versions
ssh "${ADMIN_USER}@${DEV}" "show version" | tee "${DEV}_version.txt"
# 2. List local users - flag any account not in your approved inventory
echo "[+] Local user accounts:"
ssh "${ADMIN_USER}@${DEV}" "show running-config section username" | tee "${DEV}_users.txt"
# 3. Recent configuration changes and accounting history
echo "[+] Recent command/accounting log (last 50):"
ssh "${ADMIN_USER}@${DEV}" "show accounting log | tail -n 50" | tee "${DEV}_acct.txt"
# 4. Active management sessions - look for unexpected source IPs
echo "[+] Active management sessions:"
ssh "${ADMIN_USER}@${DEV}" "show users"
# 5. Check for unexpected scheduled tasks / event handlers (persistence)
echo "[+] Event handlers and scheduled scripts:"
ssh "${ADMIN_USER}@${DEV}" "show running-config section event-handler"
ssh "${ADMIN_USER}@${DEV}" "show schedule summary"
done < "$DEVICE_LIST"
echo "=================================================="
echo "[!] INTERIM HARDENING (uncomment after review):"
cat <<'EOF'
# Restrict management-plane access to your management VLAN only.
# Adjust ACL entries to YOUR environment before applying:
#
# configure
# ip access-list standard MGMT-PLANE-PROTECT
# 10 permit host 10.10.99.10 # jump host 1
# 20 permit host 10.10.99.11 # jump host 2
# 30 permit 10.10.99.0/24 # management VLAN
# 40 deny any log
# management ssh
# ip access-group MGMT-PLANE-PROTECT in
# management api http-commands
# ip access-group MGMT-PLANE-PROTECT in
# end
# write memory
EOF
Remediation
-
Patch immediately. Obtain the fixed software release for your affected platform directly from Arista's support portal and apply it per the vendor advisory. Review Arista's security advisories at https://www.arista.com/en/support/advisories-notices and the original reporting at SecurityWeek for advisory references and affected version detail. Because exploitation is confirmed in the wild, treat this with the same urgency as a CISA KEV-listed flaw — check whether it has been added to the CISA Known Exploited Vulnerabilities catalog, which would impose a binding remediation deadline on federal agencies and a de-facto deadline on everyone else.
-
Isolate the management plane. Until patched, restrict access to device management interfaces (SSH, eAPI/HTTPS, VCO interfaces) to a dedicated management VLAN reachable only from hardened jump hosts. If any management interface is reachable from the internet or general user VLANs, that is your exposure — eliminate it now.
-
Hunt before you patch. Patching does not evict an attacker. Before upgrading, capture the audit data in the script above: local accounts, active sessions, config diff against a known-good baseline, event handlers, and scheduled tasks. Network devices are too frequently patched over the top of an existing implant.
-
Credential rotation. If a device shows any sign of unauthorized access — or if it was reachable from untrusted networks while vulnerable — rotate all credentials the device holds or touches: local accounts, TACACS+/RADIUS shared secrets, SNMP communities/strings, API tokens, and any service accounts used for automation (Ansible, CVP integration).
-
Centralize and retain device logging. Forward EOS syslog to your SIEM with at least 90 days of hot retention. Enable AAA command accounting so every CLI command is attributed to an authenticated user. This is the telemetry that makes the detections above possible.
-
Validate configuration integrity. Compare running-config against startup-config and against your configuration management baseline (you should be backing up device configs to RANCID/Oxidized, Git, or similar). Investigate any unauthorized delta as a potential compromise.
-
Tabletop the scenario. If your IR plan does not include a "network infrastructure compromise" playbook — who has credentials, how you collect forensics from EOS, how you rebuild device trust — use this event as the forcing function to write one.
The uncomfortable truth about this class of vulnerability is that most organizations will patch and move on without ever determining whether they were compromised during the exposure window. Given confirmed active exploitation, do the hunt first. The patch closes the door; it doesn't tell you who already walked through it.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.