CVE-2026-7473 IBM QRadar · QRadar

Detect Arista EOS Incomplete Comparison Authentication Bypass (CVE-2026-7473) in IBM QRadar

Detects exploitation attempts targeting CVE-2026-7473, an incomplete comparison vulnerability (CWE-1023) in Arista Extensible Operating System (EOS). This flaw allows attackers to bypass authentication or authorization checks due to missing comparison factors, potentially enabling unauthorized access to network device management interfaces. The vulnerability is actively exploited in the wild (CISA KEV). Detection focuses on anomalous management-plane access patterns, unexpected SSH/API sessions, and configuration changes on Arista EOS devices.

MITRE ATT&CK

Tactic
Initial Access Persistence Defense Evasion

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS event_time,
  sourceip,
  destinationip,
  destinationport,
  username,
  QIDNAME(qid) AS event_name,
  category,
  logsourcename(logsourceid) AS log_source,
  UTF8(payload) AS raw_payload,
  magnitude
FROM events
WHERE
  logsourcetypename(devicetype) ILIKE '%arista%'
  OR LOWER(UTF8(payload)) LIKE '%arista%'
  OR LOWER(UTF8(payload)) LIKE '%eos%'
AND (
  LOWER(UTF8(payload)) LIKE '%login%'
  OR LOWER(UTF8(payload)) LIKE '%authentication%'
  OR LOWER(UTF8(payload)) LIKE '%eapi%'
  OR LOWER(UTF8(payload)) LIKE '%privilege%'
  OR LOWER(UTF8(payload)) LIKE '%unauthorized%'
  OR LOWER(UTF8(payload)) LIKE '%config%change%'
  OR destinationport IN (22, 443, 8080, 8443)
)
AND starttime > NOW() - 7 DAYS
GROUP BY sourceip, username, destinationip
HAVING COUNT(*) > 5
ORDER BY magnitude DESC, event_time DESC
LIMIT 500
critical severity medium confidence

Queries QRadar for authentication and management access events from Arista EOS devices, grouping by source IP and username to surface repeated access patterns. Targets syslog and flow records matching Arista device identifiers with elevated event counts indicative of CVE-2026-7473 exploitation.

Data Sources

QRadar network flowsArista EOS syslog via QRadar log sourceSNMP traps

Required Tables

events

False Positives & Tuning

  • Legitimate high-frequency polling from network management systems generating repetitive authentication events
  • Automated backup scripts accessing multiple Arista devices within the detection window
  • TACACS+ authentication server forwarding legitimate repeated requests from valid network engineers
  • Security information management platforms aggregating Arista logs and generating correlated events

Other platforms for CVE-2026-7473

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Arista EOS eAPI Unauthenticated or Bypass Access Attempt

    Expected signal: Arista EOS syslog should generate authentication attempt events for each curl and SSH request, including source IP, timestamp, username, and success/failure status. eAPI HTTP access log (if enabled) should show POST requests to /command-api with HTTP 200 or 401 response codes.

  2. Test 2Unauthorized Arista EOS Configuration Change via eAPI

    Expected signal: Arista EOS syslog should record the configuration change with the username, timestamp, and commands executed. AAA accounting log should capture `configure` mode entry and the `username` command. The `show logging` output on the device should reflect the configuration event.

  3. Test 3Network Scanning of Arista EOS Management Ports

    Expected signal: Network flow records and firewall logs should show TCP SYN packets from the scanning host to ports 22, 443, 8080, and 8443 across multiple destination IPs. Arista EOS devices that received connection attempts should log SSH and HTTPS connection attempts in their management plane logs.

  4. Test 4Python Netmiko Automation Tool Authentication Probe Against Arista EOS

    Expected signal: Arista EOS SSH service will log the connection attempt including source IP, username, and authentication result. If CrowdStrike is deployed on the host running the script, process telemetry will show python3 making outbound TCP connections to port 22 of the target device.

Last updated: 2026-06-19 Research depth: standard
References (3)

Response Playbook

Triage

  1. Identify all Arista EOS devices in scope by querying your CMDB or network inventory for devices running Extensible Operating System. Cross-reference against the advisory at https://www.arista.com/en/support/advisories-notices/security-advisory/24005-security-advisory-0137 to determine if affected versions are deployed.
  2. Review Arista EOS device authentication logs (`show aaa accounting` and syslog) for unexpected login events, especially from source IPs not matching known management subnets or jump servers. Look for successful logins with incomplete or anomalous credential patterns.
  3. Check the eAPI (management API) access logs on affected devices for unauthorized REST or JSON-RPC calls. Run `show management api http-commands` and review access logs for unusual endpoints or request patterns from unexpected clients.
  4. Correlate the timestamp of any suspicious authentication events against change management records. Unauthorized logins outside of approved change windows are high-confidence indicators of exploitation.
  5. Determine if the vulnerability is exploitable from the network by reviewing whether management interfaces (SSH, eAPI) are exposed to untrusted networks. Run `show management ssh` and `show management api http-commands` to assess exposure.

Containment

  1. Immediately restrict management access to Arista EOS devices by applying ACLs that limit SSH and eAPI access to authorized management subnets only. Apply using `management ssh` and `management api http-commands` with access-group restrictions. Coordinate with network team before applying to avoid lockout.
  2. If exploitation is confirmed or strongly suspected, isolate the affected Arista device from the network by disabling uplink interfaces or placing it in a quarantine VLAN. Use out-of-band management (console port or dedicated management network) for continued access during investigation.
  3. Rotate all credentials for accounts that authenticated to the affected device during the suspicious window. Revoke and regenerate API tokens and SSH keys associated with eAPI or management access.
  4. Apply the vendor patch or mitigation per Arista Security Advisory 0137. If a patch is not immediately available, implement the vendor-recommended workarounds such as disabling eAPI or restricting management plane access.

Evidence Collection

  1. Collect full syslog output from the affected Arista EOS device covering the incident window: `show logging last 10000` and export to a secure log repository. Preserve the raw syslog file before any device reload or configuration change.
  2. Export the running and startup configuration snapshots using `show running-config` and `show startup-config`, and diff them to identify unauthorized configuration changes introduced during or after the exploitation window.
  3. Capture network flow data (NetFlow/sFlow) from upstream routers or switches for all traffic to and from the management interfaces of the affected Arista device during the incident window to reconstruct attacker actions.
  4. Document all successful and failed authentication events with timestamps, source IPs, usernames, and method (SSH key vs. password) from TACACS+, RADIUS, or local accounting logs.

Escalation Criteria

  • !Escalate to Incident Response team if evidence shows successful unauthorized configuration changes, including new user accounts, modified ACLs, added SSH keys, or route manipulation, as this indicates confirmed post-exploitation.
  • !Escalate immediately if the affected Arista device is a core routing or switching device in a critical network segment (data center spine, WAN edge, firewall adjacency), as exploitation could enable large-scale lateral movement or traffic interception.
  • !Escalate to vendor support and consider contacting Arista PSIRT if exploitation artifacts cannot be explained by the known vulnerability mechanism, as this may indicate a novel attack chain or additional unpatched vulnerability.

Investigation Guide

Related Techniques

[object Object][object Object][object Object][object Object]

Forensic Artifacts

  • >Arista EOS syslog entries at /var/log/messages or forwarded via syslog containing authentication events, privilege escalation notices, and eAPI access records
  • >EOS AAA accounting records accessible via `show aaa accounting` capturing command history with timestamps and source IPs for authenticated sessions
  • >eAPI HTTP access logs if enabled, showing JSON-RPC request bodies, source IPs, and response codes for management API calls
  • >Running configuration diff captured at time of incident versus last known-good configuration backup, revealing unauthorized changes
  • >Network flow records (sFlow/NetFlow) to and from EOS management interfaces (TCP/22, TCP/443, TCP/8080) for the incident window

Tuning Guidance

Baseline normal management plane activity for each Arista EOS device before deploying this detection. Key tuning parameters are the event_count threshold (default 5 per 10 minutes) and unique_users threshold (default 2). In environments with large Network Operations Centers or heavy automation, raise these thresholds or add allowlist entries for known management subnets and automation service accounts. For environments where eAPI is disabled or SSH is restricted to a jump server, the false positive rate will be very low and thresholds can be tightened. Exclude known NMS source IPs (SolarWinds, PRTG, Zabbix poller addresses) from alerts. Correlate with change management data to suppress alerts during approved maintenance windows. If TACACS+ or RADIUS is in use, ingest AAA accounting logs directly for higher-fidelity detection.

Hunting Queries

Threat hunt for Arista EOS devices exhibiting elevated authentication event volumes or connections from many unique source IPs over the past 30 days, which may indicate scanning, brute force, or exploitation activity preceding or following CVE-2026-7473 exploitation

Hunting — KQL
kql 
CommonSecurityLog
| where DeviceVendor =~ "Arista" or DeviceProduct has "EOS"
| where TimeGenerated > ago(30d)
| where Message has_any ("login", "ssh", "eapi", "api", "authentication", "privilege", "enable", "config")
| summarize LoginAttempts = count(), UniqueSourceIPs = dcount(SourceIP), Actions = make_set(Activity) by DeviceName, bin(TimeGenerated, 1h)
| where LoginAttempts > 20 or UniqueSourceIPs > 5
| order by LoginAttempts desc
Hunting — SPL
spl 
index=network (sourcetype="arista:eos:syslog" OR vendor=Arista)
| eval hour=strftime(_time, "%Y-%m-%d %H")
| stats count as total_events, dc(src_ip) as unique_srcs, values(action) as actions by host, hour
| where total_events > 20 OR unique_srcs > 5
| sort - total_events

Hunt for unauthorized user account creation, privilege escalation to enable level 15, or AAA/credential modifications on Arista EOS devices within the past 14 days, consistent with post-exploitation persistence after CVE-2026-7473 authentication bypass

Hunting — KQL
kql 
CommonSecurityLog
| where DeviceVendor =~ "Arista"
| where TimeGenerated > ago(14d)
| where Message has_any ("new user", "user added", "aaa", "role", "privilege 15", "secret", "password")
| project TimeGenerated, DeviceName, Message, SourceIP, DestinationIP, Activity
| order by TimeGenerated desc
Hunting — SPL
spl 
index=network (sourcetype="arista:eos:syslog" OR vendor=Arista) earliest=-14d
| search message IN ("*new user*", "*user added*", "*privilege 15*", "*secret*", "*aaa*", "*role*")
| table _time, host, src_ip, message
| sort - _time

Atomic Red Team Tests

Test 1 Arista EOS eAPI Unauthenticated or Bypass Access Attempt
linux

Simulates an attacker probing the Arista EOS eAPI endpoint with malformed or incomplete credentials to test for the incomplete comparison bypass condition described in CVE-2026-7473. Uses curl to send JSON-RPC requests to the eAPI with missing or empty authentication fields.

Command

bash 
# LAB ONLY - target must be an isolated lab Arista EOS device
TARGET_IP="192.168.1.1"
# Test 1: Empty password (incomplete comparison probe)
curl -sk -X POST https://${TARGET_IP}/command-api \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,"cmds":["show version"],"format":"json"},"id":1}' \
  --user 'admin:'
# Test 2: No authentication header
curl -sk -X POST https://${TARGET_IP}/command-api \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,"cmds":["show version"],"format":"json"},"id":1}'
# Test 3: SSH with empty password attempt
ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -p 22 admin@${TARGET_IP} 'show version' <<< ''

Cleanup

bash 
No cleanup required on attacker host. On lab Arista device, review `show aaa accounting` and `show logging` to confirm telemetry was generated. Rotate any credentials used during testing.

Expected Telemetry

Arista EOS syslog should generate authentication attempt events for each curl and SSH request, including source IP, timestamp, username, and success/failure status. eAPI HTTP access log (if enabled) should show POST requests to /command-api with HTTP 200 or 401 response codes.

Expected Detection

KQL and SPL queries should trigger on the rapid succession of authentication attempts from the same source IP within the detection window. Chronicle YARAL rule should fire after more than 5 connection events from the test IP within 10 minutes.

Test 2 Unauthorized Arista EOS Configuration Change via eAPI
linux

Simulates post-exploitation configuration tampering on an Arista EOS device after authentication bypass. An attacker with management access could add backdoor accounts or modify ACLs. This test creates a temporary test user via eAPI to verify detection of unauthorized configuration changes.

Command

bash 
# LAB ONLY - use isolated lab Arista device with known credentials for simulation
TARGET_IP="192.168.1.1"
USER="admin"
PASS="lab_password"
# Simulate attacker adding a backdoor user account via eAPI
curl -sk -X POST https://${TARGET_IP}/command-api \
  -H 'Content-Type: application/json' \
  --user "${USER}:${PASS}" \
  -d '{
    "jsonrpc":"2.0",
    "method":"runCmds",
    "params":{
      "version":1,
      "cmds":[
        "enable",
        "configure",
        "username testbackdoor privilege 15 secret testpass123",
        "end",
        "show running-config | grep testbackdoor"
      ],
      "format":"json"
    },
    "id":1
  }'

Cleanup

bash 
Remove the test backdoor account immediately after the test:
curl -sk -X POST https://${TARGET_IP}/command-api -H 'Content-Type: application/json' --user "${USER}:${PASS}" -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,"cmds":["enable","configure","no username testbackdoor","end","write memory"],"format":"json"},"id":1}'

Expected Telemetry

Arista EOS syslog should record the configuration change with the username, timestamp, and commands executed. AAA accounting log should capture `configure` mode entry and the `username` command. The `show logging` output on the device should reflect the configuration event.

Expected Detection

Hunting queries filtering for 'new user', 'user added', or 'privilege 15' in Arista syslog should surface this event. Playbook escalation criteria for unauthorized configuration changes should be triggered.

Test 3 Network Scanning of Arista EOS Management Ports
linux

Simulates an attacker performing reconnaissance against Arista EOS management interfaces (SSH port 22 and eAPI ports 443/8080) to identify exposed devices before exploitation. This represents the initial scanning phase that precedes CVE-2026-7473 exploitation.

Command

bash 
# LAB ONLY - scan only authorized lab network segments
TARGET_SUBNET="192.168.1.0/24"
# Port scan for Arista management ports
nmap -sS -p 22,80,443,8080,8443 --open -T3 \
  --script ssh-hostkey,ssl-cert \
  -oX /tmp/arista_scan_results.xml \
  ${TARGET_SUBNET}
# Follow up with banner grab on discovered hosts
nmap -sV -p 22,443,8080 --script banner \
  $(grep 'addr=' /tmp/arista_scan_results.xml | grep -oP '(?<=addr=")[^"]+' | head -20 | tr '\n' ' ')

Cleanup

bash 
rm -f /tmp/arista_scan_results.xml

Expected Telemetry

Network flow records and firewall logs should show TCP SYN packets from the scanning host to ports 22, 443, 8080, and 8443 across multiple destination IPs. Arista EOS devices that received connection attempts should log SSH and HTTPS connection attempts in their management plane logs.

Expected Detection

IDS/IPS systems should generate port scan alerts for the systematic scanning pattern. SIEM correlation rules looking for single-source multi-destination connections to management ports should fire. CrowdStrike Falcon query will surface endpoint-side scanning tools if nmap is executed on a protected host.

Test 4 Python Netmiko Automation Tool Authentication Probe Against Arista EOS
linux

Simulates an attacker using the Netmiko Python library (a common network automation tool) to programmatically probe Arista EOS SSH authentication, potentially exploiting the incomplete comparison flaw in CVE-2026-7473 by testing edge-case credential combinations.

Command

bash 
# LAB ONLY
# Install netmiko if not present
pip3 install netmiko 2>/dev/null
# Python script to test authentication with empty/null credentials
python3 - <<'EOF'
from netmiko import ConnectHandler
import logging
logging.basicConfig(level=logging.DEBUG)

target = {
    'device_type': 'arista_eos',
    'host': '192.168.1.1',
    'username': 'admin',
    'password': '',
    'timeout': 5,
}
try:
    conn = ConnectHandler(**target)
    output = conn.send_command('show version')
    print(f'[!] CONNECTED - Possible bypass: {output[:200]}')
    conn.disconnect()
except Exception as e:
    print(f'Connection failed (expected): {e}')
EOF

Cleanup

bash 
No persistent changes made. The Python script only attempts authentication and does not modify any device configuration.

Expected Telemetry

Arista EOS SSH service will log the connection attempt including source IP, username, and authentication result. If CrowdStrike is deployed on the host running the script, process telemetry will show python3 making outbound TCP connections to port 22 of the target device.

Expected Detection

CrowdStrike CQL query will detect python3 making connections to port 22 with command lines matching netmiko patterns. KQL and SPL queries will surface the authentication attempt in Arista syslog. The empty password attempt may trigger the incomplete comparison vulnerability and generate an anomalous success event that would be high-confidence indicator.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0003PersistenceTA0005Defense Evasion

Related Techniques

T1190Exploit Public-Facing ApplicationT1078Valid AccountsT1556Modify Authentication ProcessT1021.004SSH

Same Tactic: Initial Access

Popular Detections