Back to Intelligence

CVE-2026-73749: Critical RCE Cluster in HPE Aruba AOS-CX Switches — Detection and Remediation Guide

SA
Security Arsenal Team
September 4, 2026
10 min read

HPE has released security updates addressing a cluster of nearly two dozen vulnerabilities in AOS-CX, the network operating system powering HPE Aruba Networking CX switches. The issues are tracked collectively under CVE-2026-73749 and carry a CVSS score of 9.8 (Critical), indicating remotely exploitable code execution conditions with low attacker complexity and no authentication barrier in at least some of the affected code paths.

This is the class of vulnerability that keeps network defenders up at night. Switches running AOS-CX sit at the core and access layers of enterprise networks — they are trusted, they are always on, they touch every VLAN, and they are almost never instrumented with EDR. A 9.8-rated RCE on the switching fabric is not a server patch problem; it is a potential foothold for traffic interception, lateral movement, VLAN hopping, and persistence in a location where most SOCs have no visibility beyond syslog.

If you operate HPE Aruba CX-series switches anywhere in your environment — campus access, distribution, or data center — treat this as a priority-one patching event and assume adversaries are already diffing the patched and unpatched firmware.

Technical Analysis

Affected Products

The vulnerabilities affect devices running HPE Aruba Networking AOS-CX, the operating system used across the CX switch portfolio (including the CX 6000, 8000, 9000, and 10000 series families commonly deployed in enterprise campus and data center environments). Organizations should consult the official HPE Aruba networking security advisory for the exact affected train/fixed-version matrix for their deployed hardware, as remediation versions vary by switch model and software branch.

  • CVE: CVE-2026-73749
  • CVSS: 9.8 (Critical) — consistent with network-reachable, unauthenticated remote code execution
  • Scope: Nearly two dozen distinct issues addressed under a single collective tracking identifier in this update cycle
  • Vendor advisory: HPE Aruba Networking Security Advisories portal (arubanetworks.com / HPE Networking support portal)

How the Vulnerability Class Works — Defender's View

Bundled multi-issue CVEs on network operating systems typically cluster around the device's management and control plane attack surface:

  1. Management plane exposure — the web UI, REST API (AOS-CX exposes a full REST interface), and in some cases protocol parsers reachable from data plane interfaces. A 9.8 score strongly suggests a pre-authentication code path reachable over the network.
  2. Exploitation requirements — an attacker needs network reachability to the affected service. This is why the exposure question matters more than the CVSS score: is your switch management plane isolated on a dedicated management VRF/VLAN, or is it reachable from user VLANs and — worst case — the internet?
  3. Post-exploitation impact — code execution on a switch yields credential harvesting from authentication flows (TACACS+/RADIUS proxied traffic, 802.1X), traffic mirroring, ACL manipulation, and a stealthy persistence point that survives most incident response playbooks because responders rarely reimage network devices.

Exploitation Status

As of publication, there are no confirmed reports of in-the-wild exploitation of CVE-2026-73749, and the CVE has not been listed in the CISA Known Exploited Vulnerabilities catalog. However, critical network-device CVEs with public advisories are routinely weaponized within days to weeks once patches are reverse-engineered. The window between "patched and quiet" and "mass scanning" is short for 9.8 network-device bugs. Do not wait for a KEV listing to act — by then, internet-facing management interfaces will already be compromised.

Detection & Response

Detection for network-device compromise is a telemetry problem: the switch itself can't run your EDR, so you hunt in (a) syslog forwarded from AOS-CX devices, (b) firewall/NDR telemetry for the switch management subnet, and (c) the jump hosts and admin workstations that legitimately touch the switches. The rules below focus on those three planes.

SIGMA Rules

YAML
---
title: Unexpected Connection to Network Device Management Interfaces
id: 3f8a1c92-7b4e-4d61-a932-cve202673749a1
status: experimental
description: Detects SSH or HTTPS/REST connections to switch management interfaces originating from hosts outside the approved management/jump-box population. Update the management subnet CIDR and jump-host exclusion list for your environment.
references:
  - https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/
  - https://attack.mitre.org/techniques/T1021/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.lateral_movement
  - attack.t1021.004
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationIp|cidr: '10.99.0.0/24'   # REPLACE: switch management VLAN
    DestinationPort:
      - 22
      - 443
      - 8080
  filter_jumpboxes:
    SourceIp:
      - '10.50.10.11'   # REPLACE: approved jump hosts / NMS
      - '10.50.10.12'
  condition: selection and not filter_jumpboxes
falsepositives:
  - Network monitoring platforms polling switches (add to exclusion)
  - Configuration management tools (Ansible, NetBox sync jobs)
level: high
---
title: Outbound Internet Connection from Switch Management Subnet
id: 8d2e6f41-3a97-4c58-b714-cve202673749b2
status: experimental
description: Detects outbound connections from the network device management subnet to non-RFC1918 destinations. Switches should only talk to approved NMS, AAA, syslog, NTP, and firmware update endpoints. An outbound session from a switch to the internet is a strong post-exploitation indicator (C2 or reverse shell).
references:
  - https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071
logsource:
  category: firewall
  product: network
detection:
  selection:
    src_ip|cidr: '10.99.0.0/24'   # REPLACE: switch management VLAN
    dst_ip|cidr:
      - '0.0.0.0/0'
  filter_private:
    dst_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_private
falsepositives:
  - Centralized firmware/updates if switches fetch directly from vendor CDN (allowlist vendor endpoints instead)
  - Cloud-managed Aruba Central connectivity (allowlist Central endpoints specifically)
level: high

KQL (Microsoft Sentinel / Defender)

These hunts assume AOS-CX syslog is forwarded to Sentinel (Syslog or CommonSecurityLog via a Linux collector) and that firewall traffic for the management subnet lands in CommonSecurityLog. Tune the switch IP list and the known-admin source list before deployment.

KQL — Microsoft Sentinel / Defender
// Hunt 1: AOS-CX syslog indicators of account creation, config change, or auth anomalies
let SwitchSyslog = Syslog
    | where Computer in_ (dynamic(["switch01","switch02"]))  // or filter by Facility/Severity
    | where TimeGenerated > ago(7d);
SwitchSyslog
| where SyslogMessage has_any (
    "user add", "user-account", "USER_ACCOUNT", "account created",
    "config-changed", "configuration changed", "startup-config",
    "authentication failure", "LOGIN_FAILED",
    "core dump", "crash", "segmentation", "daemon died")
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc;
// Hunt 2: New or unusual source IPs touching switch management services (via firewall CEF)
let KnownAdmins = dynamic(["10.50.10.11","10.50.10.12"]);   // REPLACE: jump hosts / NMS
let SwitchSubnet = "10.99.0.";                                // REPLACE: mgmt VLAN prefix
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationIP startswith SwitchSubnet
| where DestinationPort in (22, 443, 8080, 830)
| where SourceIP !in (KnownAdmins)
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by Connections desc;
// Hunt 3: Outbound connections FROM switches (C2 / reverse shell indicator)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP startswith SwitchSubnet
| where DestinationIP !startswith "10." and DestinationIP !startswith "192.168." and DestinationIP !startswith "172.16."
| summarize count() by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by count_ desc;

Velociraptor VQL

Velociraptor won't run on the switches, but it should run on your admin jump boxes and network engineering workstations — the systems an attacker must compromise or impersonate to reach the management plane. This artifact hunts for unexpected processes holding connections to switch management ports, catching rogue SSH clients, tunneling tools, and malware sessions on management hosts.

VQL — Velociraptor
-- Hunt for unexpected processes with connections to switch management ports
LET ApprovedSSH <= ('ssh.exe', 'putty.exe', 'mRemoteNG.exe', 'SecureCRT.exe', 'ansible', 'python.exe')
SELECT Pid, Name, CommandLine, Username, Family, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort,
       CreateTime
FROM netstat()
WHERE (RemotePort in (22, 443, 8080, 830) OR Family =~ 'AF_INET')
  AND Status =~ 'ESTAB'
  AND RemotePort in (22, 8080, 830)
  AND NOT Name in ApprovedSSH
ORDER BY CreateTime DESC

Remediation / Verification Script

Use this Bash script from a management host to inventory AOS-CX versions across your fleet and flag devices that still need the CVE-2026-73749 fix applied. It also audits the two most common exposure mistakes: management reachability from non-management sources and the REST API state.

Bash / Shell
#!/bin/bash
# AOS-CX CVE-2026-73749 inventory & exposure audit
# Requires: SSH key auth to switches, 'jq' optional
SWITCH_LIST="/opt/netops/switches.txt"   # one switch mgmt IP per line
SSH_USER="netops-audit"
REPORT="/var/log/aoscx_audit_$(date +%F).csv"

echo "switch_ip,aoscx_version,rest_api_state,reachable,notes" > "$REPORT"

while read -r SW; do
  [ -z "$SW" ] && continue
  # Pull running AOS-CX version
  VER=$(ssh -o BatchMode=yes -o ConnectTimeout=8 ${SSH_USER}@${SW} \
        "show version" 2>/dev/null | grep -i "AOS-CX" | head -1 | tr -d '\r')

  if [ -z "$VER" ]; then
    echo "${SW},UNKNOWN,UNKNOWN,NO,ssh_failed_or_timeout" >> "$REPORT"
    continue
  fi

  # Check REST API operational state (reduce attack surface if unused)
  REST=$(ssh -o BatchMode=yes ${SSH_USER}@${SW} \
        "show https-server status" 2>/dev/null | grep -i "rest" | tr -d '\r')

  echo "${SW},${VER},${REST:-n/a},YES,review_against_HPE_advisory" >> "$REPORT"
done < "$SWITCH_LIST"

echo "[+] Inventory written to $REPORT"
echo "[!] ACTION: Compare each version against the fixed-release matrix in the HPE Aruba advisory for CVE-2026-73749"
echo "[!] ACTION: Any switch with REST/HTTPS enabled that does not need it: disable via 'no https-server rest' context"

# Exposure check: can user VLAN hosts reach switch mgmt port 443/22?
echo "[i] From a user-VLAN test host, run: nmap -p 22,443,8080 <switch-mgmt-IP> — any OPEN result means your management plane is not isolated. Fix ACLs/VRF now."

Remediation

  1. Patch immediately. Apply the fixed AOS-CX releases identified in the official HPE Aruba Networking security advisory for CVE-2026-73749. Download firmware only from the HPE Networking Support Portal and validate image signatures/checksums before installation. Reference: https://www.securityweek.com/hpe-patches-critical-rce-vulnerabilities-in-aos-cx/ and the HPE Aruba Networking Security Advisories page.
  2. Isolate the management plane today, patch or not. Move switch management interfaces into a dedicated management VRF/VLAN reachable only from named jump hosts and NMS systems. Enforce this with ACLs on every routed path. This single control converts a 9.8 remote bug into a near-unexploitable one for most adversaries.
  3. Reduce exposed services. Disable the REST API and web UI (https-server) on any switch where programmatic management isn't in use. Disable Telnet and legacy SNMPv1/v2c read-write strings.
  4. Centralize and protect logging. Forward AOS-CX syslog to your SIEM with a reliable transport and alert on the patterns in the KQL hunts above — especially account creation, configuration changes, daemon crashes, and authentication failures. RCE exploitation attempts against embedded services frequently produce crash/core-dump noise before succeeding.
  5. Hunt before you patch, and after. Run the outbound-connection hunt (Hunt 3) against the last 30 days of firewall telemetry. If a switch has been initiating internet sessions, treat it as potentially compromised: patch, then review its full configuration (show running-config) against golden config, rotate all credentials stored on or transiting the device (local users, RADIUS/TACACS+ shared secrets, SNMP), and consider reimaging if anomalies persist.
  6. Inventory completeness. You cannot patch what you haven't mapped. Confirm your CMDB reflects every AOS-CX device including access-layer closets — these get forgotten in every patching cycle and are exactly where a 9.8 sits longest.
  7. Watch for follow-on advisories. Nearly two dozen issues shipped in this bundle; expect HPE to publish per-issue detail and expect researchers to publish diffs. Subscribe to the HPE Aruba security bulletin feed and monitor CISA KEV for CVE-2026-73749 additions.

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.