HPE ArubaOS Critical Patch Drop: 72 Flaws Including 8 Max-Severity RCE and Auth Bypass Bugs — Detection and Remediation Guide

Hewlett Packard Enterprise has released a significant security update for the Aruba Operating System (ArubaOS), addressing 72 vulnerabilities in a single advisory cycle — including eight maximum-severity flaws spanning authentication bypass and remote code execution. If you operate Aruba wireless controllers, mobility conductors, or access points running affected AOS trains, this is not a routine patch cycle. Edge and network infrastructure devices sit at the trust boundary of your environment; an unauthenticated RCE on a mobility controller is a direct path to traffic interception, lateral movement, and persistent footholds that most EDR stacks will never see.

I've led IR engagements where compromised network infrastructure was the initial access vector — and the common thread in every one of them was that the device hadn't been patched in 18+ months and wasn't forwarding logs anywhere. Don't let that be your Aruba estate.

Technical Analysis

Affected Products

The update applies to the ArubaOS (AOS) codebase that powers Aruba's enterprise mobility portfolio, including:

• Aruba Mobility Controllers (70xx/72xx/90xx/92xx series)
• Aruba Mobility Conductor (hardware and virtual)
• Aruba Access Points managed under affected controller architectures
• AOS-based SD-WAN/gateway deployments running vulnerable trains

Both the AOS 8.x and AOS 10.x code trains are historically in scope for advisories of this size. Your first action is to enumerate every controller and conductor in the environment, capture the running version (show version), and map it against the fixed versions listed in HPE's security bulletin.

Vulnerability Classes

Per the disclosure, the 72 flaws break down into the categories that matter most to network defenders:

• Authentication bypass (critical): Flaws allowing an attacker to circumvent authentication controls on management interfaces — the web UI, REST API, or CLI login plane. On a controller, this means full administrative control without credentials.
• Remote code execution (critical): Exploitable code execution in management-plane or control-plane services reachable over the network. On network appliances these frequently yield root-level shell on the underlying Linux-based OS.
• Lower-severity issues rounding out the remainder of the 72 — typically privilege escalation, information disclosure, and denial-of-service conditions.

Note on CVEs: The public summary of this release does not enumerate individual CVE identifiers. HPE publishes the full CVE-to-fixed-version mapping in its security advisory portal. Do not rely on secondary reporting for the mapping — pull the bulletin directly from HPE and map each CVE to the fixed AOS version for your specific train. Applying this discipline matters: AOS 8.x and 10.x fixes often ship on different cadences.

Why This Attack Surface Is High-Value

From a red team perspective, mobility controllers are a premium target:

1. They terminate wireless trust. Compromise the controller and you can manipulate SSIDs, captive portals, RADIUS integrations, and client traffic flows.
2. They bridge network segments. Controllers sit between wireless clients, wired infrastructure, and frequently management VLANs.
3. They are forensically opaque. No EDR agent, limited local logging, and volatile memory forensics that most IR teams aren't equipped for. Post-exploitation activity on a controller is nearly invisible unless you're collecting syslog off-box.
4. Auth bypass + RCE chaining on an internet-adjacent or guest-network-adjacent management interface is exactly the pattern we've watched exploited at scale against other network appliance vendors in recent years.

Exploitation Status

At the time of this writing, the flaws appear to be patched prior to confirmed public exploitation — this is a coordinated vendor disclosure, not an active-exploitation emergency bulletin. That said, the history of critical network-appliance CVEs is unambiguous: PoC development and mass scanning typically follow within days to weeks of patch release, as researchers diff the patched and unpatched firmware. Treat the window between now and your completed patch deployment as contested.

Detection & Response

Network appliances don't run your EDR, so detection here lives in three places: off-box syslog from the Aruba devices, network-layer telemetry, and the endpoints/adjacent systems an attacker touches after compromising a controller. All rules below assume you're forwarding ArubaOS syslog (and controller auth logs) to your SIEM — if you're not, that is remediation step zero.

Sigma Rules

---
title: ArubaOS Authentication Anomaly - Admin Login From Unusual Source
id: 3f8a2c91-7d4e-4b1a-9c55-a1b2c3d4e5f6
status: experimental
description: Detects successful administrator authentication to ArubaOS controllers originating from source IPs outside the expected management network, consistent with exploitation of authentication bypass flaws against management interfaces.
references:
  - https://www.bleepingcomputer.com/news/security/hpe-patches-eight-max-severity-rce-and-auth-bypass-aos-flaws/
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.initial_access
  - attack.t1078
  - attack.t1190
logsource:
  product: aruba
  service: syslog
detection:
  selection_auth_success:
    - 'message|contains':
        - 'login successful'
        - 'authentication successful'
        - 'USER_AUTHENTICATED'
  filter_mgmt_subnet:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '192.168.0.0/16'
      - '172.16.0.0/12'
  condition: selection_auth_success and not filter_mgmt_subnet
falsepositives:
  - Administrators working remotely via VPN appearing with public or NAT addresses - tune src_ip ranges to your actual management and VPN subnets
level: high
---
title: ArubaOS Local Account Creation or Privilege Change
id: 9d1e4b37-2a6c-48f5-b833-f7e8d9c0a1b2
status: experimental
description: Detects creation of new local management accounts or privilege modifications on ArubaOS controllers, a common persistence mechanism following exploitation of network device RCE or auth bypass vulnerabilities.
references:
  - https://www.bleepingcomputer.com/news/security/hpe-patches-eight-max-severity-rce-and-auth-bypass-aos-flaws/
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  product: aruba
  service: syslog
detection:
  selection:
    message|contains:
      - 'mgmt-user'
      - 'user added'
      - 'account created'
      - 'privilege modified'
      - 'local-userdb add'
  condition: selection
falsepositives:
  - Legitimate onboarding of network administrators - correlate with change tickets and restrict alerting to accounts not in an approved baseline
level: high
---
title: ArubaOS Unexpected Configuration Change Outside Maintenance Window
id: 5c7a9f12-8b3d-4e61-a944-c2d3e4f5a6b7
status: experimental
description: Detects configuration write/commit events on ArubaOS controllers, which should be rare, change-controlled actions. Unexpected config changes can indicate post-exploitation manipulation of NAT rules, ACLs, RADIUS settings, or tunnel configurations.
references:
  - https://www.bleepingcomputer.com/news/security/hpe-patches-eight-max-severity-rce-and-auth-bypass-aos-flaws/
  - https://attack.mitre.org/techniques/T1602/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.defense_evasion
  - attack.t1602
logsource:
  product: aruba
  service: syslog
detection:
  selection:
    message|contains:
      - 'write memory'
      - 'configuration changed'
      - 'CONFIG_CHANGE'
      - 'commit'
  condition: selection
falsepositives:
  - Scheduled network engineering changes - suppress during approved change windows and alert on all other occurrences
level: medium

Analyst note: The filter_mgmt_subnet in the first rule is a placeholder — replace it with your actual management/VPN source ranges before deploying. The value of that rule is entirely dependent on accurate scoping; deployed untuned, it's noise.

KQL — Microsoft Sentinel / Defender

Assuming ArubaOS syslog is ingested into Sentinel via a Linux syslog collector (CEF or Syslog table), this query hunts for post-exploitation behavioral patterns: admin logins from new sources, account creation, and configuration changes clustered together — the signature of hands-on-keyboard activity on a compromised controller.

// Hunt: Suspicious ArubaOS management-plane activity
// Requires Aruba controllers forwarding syslog to Sentinel (Syslog or CommonSecurityLog)
let Lookback = 14d;
let ArubaEvents = Syslog
    | where TimeGenerated > ago(Lookback)
    | where Computer has_any ("aruba", "controller", "conductor")
       or SyslogMessage has_any ("mgmt-user", "write memory", "login successful");
let AdminLogins = ArubaEvents
    | where SyslogMessage has_any ("login successful", "authentication successful", "USER_AUTHENTICATED")
    | extend SrcIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 0, SyslogMessage)
    | summarize LoginCount = count(), LoginSources = make_set(SrcIP) by Computer;
let ConfigChanges = ArubaEvents
    | where SyslogMessage has_any ("write memory", "configuration changed", "CONFIG_CHANGE")
    | summarize ConfigChangeCount = count() by Computer;
let AccountChanges = ArubaEvents
    | where SyslogMessage has_any ("mgmt-user", "user added", "account created", "privilege modified")
    | summarize AccountChangeCount = count(), SampleMessages = make_set(SyslogMessage, 5) by Computer;
AdminLogins
| join kind=inner ConfigChanges on Computer
| join kind=inner AccountChanges on Computer
| project Computer, LoginCount, LoginSources, ConfigChangeCount, AccountChangeCount, SampleMessages
| order by AccountChangeCount desc

A controller showing logins + account creation + config writes within the same window, from sources you don't recognize, is a triage-now event. Also run the companion check below to baseline which controllers are even logging — silence from a device that should be talking is itself a finding:

// Coverage check: Which Aruba devices stopped logging or never started?
Syslog
| where TimeGenerated > ago(30d)
| where Computer has_any ("aruba", "controller", "conductor")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), EventCount = count() by Computer
| extend DaysSinceLastLog = datetime_diff("day", now(), LastSeen)
| order by DaysSinceLastLog desc

Velociraptor VQL

Controllers themselves can't run Velociraptor, but post-exploitation of a network device almost always involves an attacker pivoting to reachable endpoints. This artifact hunts Windows endpoints for interactive shells and tunneling tools spawned with command lines referencing Aruba/controller infrastructure or unusual outbound connections to controller management ports — useful for scoping lateral movement after a suspected device compromise:

-- Hunt for processes communicating with Aruba management interfaces
-- or spawning shells/tunnels referencing network device infrastructure
SELECT Pid,
       Name,
       CommandLine,
       Exe,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(aruba|mobility.?master|conductor)'
   OR CommandLine =~ '(?i)(ssh.*-L|ssh.*-D|ssh.*-R|chisel|ligolo|plink.*-P\s+(22|4343))'
   OR CommandLine =~ '(?i):(22|4343|8443)'

Pair that with a netstat check for established sessions to controller management ports (SSH/22, HTTPS management/4343) from non-admin workstations:

-- Established connections to typical Aruba management ports from endpoints
SELECT Pid,
       Name,
       CommandLine,
       Family,
       Status,
       Laddr.IP AS LocalIP,
       Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP,
       Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
  AND RemotePort in (22, 4343, 8443)
  AND NOT Raddr.IP =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'

Any endpoint with an established session to a controller management port that isn't a known network engineering jump host warrants immediate triage.

Verification & Hardening Script

Use this Bash script from a management host with SSH access to your Aruba estate to inventory running AOS versions across controllers and flag devices still on potentially vulnerable trains. Feed it a list of controller IPs/hostnames:

#!/bin/bash
# ArubaOS version inventory and exposure check
# Usage: ./aruba_version_audit.sh controllers.txt
# Requires: sshpass or key-based auth to a read-only audit account on each controller

CONTROLLER_LIST="$1"
AUDIT_USER="readonly_audit"
OUTPUT="aruba_version_audit_$(date +%Y%m%d).csv"

echo "controller,reachable,model,aos_version" > "$OUTPUT"

while read -r ctrl; do
    [ -z "$ctrl" ] && continue
    echo "[*] Querying $ctrl ..."

    # Pull version banner via CLI
    RAW=$(ssh -o ConnectTimeout=10 -o StrictHostKeyChecking=accept-new \
        "${AUDIT_USER}@${ctrl}" "show version" 2>/dev/null)

    if [ -z "$RAW" ]; then
        echo "${ctrl},UNREACHABLE,unknown,unknown" >> "$OUTPUT"
        continue
    fi

    MODEL=$(echo "$RAW" | grep -iE 'aruba(os)? [0-9]' | head -1 | tr ',' ' ')
    VERSION=$(echo "$RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)

    echo "${ctrl},OK,${MODEL:-unknown},${VERSION:-unknown}" >> "$OUTPUT"
done < "$CONTROLLER_LIST"

echo "[*] Audit complete: $OUTPUT"
echo "[!] ACTION: Cross-reference every version in this CSV against the fixed"
echo "    versions in the HPE security bulletin for this advisory. Any version"
echo "    below the fixed release for its train is EXPOSED to the 8 critical"
echo "    auth bypass / RCE flaws until patched."

# Quick exposure summary
echo ""
echo "=== Devices needing review ==="
awk -F',' 'NR>1 && $2=="OK" {print $1" -> "$4}' "$OUTPUT"

This is deliberately read-only — inventory first, then patch through your normal change process (with urgency). On the controllers themselves, also verify management-plane exposure:

# On each controller: confirm management interfaces are NOT reachable from
# guest/internet-facing VLANs, and confirm logging is forwarding off-box
# Run via SSH session:
#   show ip interface brief
#   show logging
#   show mgmt-user
# Review: any mgmt-user accounts you don't recognize = potential persistence

Remediation

1. Pull the official HPE advisory now. Go to HPE's security bulletin portal (support.hpe.com → Security Bulletins) and retrieve the ArubaOS advisory covering this 72-CVE release. Map each CVE to the fixed version for your specific AOS train (8.x vs 10.x) — the fixed versions differ per train and per platform family.

2. Inventory before you patch. Run the audit script above (or your NCM tooling — rConfig, Oxidized, SolarWinds NCM) to get an authoritative list of every controller, conductor, and their running versions. Shadow IT controllers exist in more environments than you'd think.

3. Patch on an emergency change cadence. Eight max-severity auth bypass and RCE flaws on network edge infrastructure justifies expedited change approval. Sequence: lab/standby controller → production conductors → production controllers → AP-side dependencies. Take config backups and snapshots (for virtual conductors) before each upgrade.

4. Restrict management-plane exposure immediately (compensating control). While patching is scheduled: ensure controller management interfaces (web UI, SSH, REST API) are reachable only from a dedicated management VLAN or hardened jump hosts. If any controller management interface is reachable from guest wireless, the internet, or broad internal segments, that's your highest-risk asset — isolate it today.

5. Enable and verify off-box logging. Every controller should forward syslog to your SIEM at minimum severity informational, covering auth events, config changes, and user database modifications. A compromised controller's local logs cannot be trusted.

6. Audit local accounts. show mgmt-user on every controller. Any account not in your approved baseline is a persistence indicator — disable it and open an IR case, don't just delete it.

7. Hunt retroactively. Run the KQL and VQL hunts above over the last 30–90 days, not just going forward. Auth bypass flaws are frequently exploited quietly; patching closes the door but doesn't tell you whether someone already walked through it.

8. Watch for follow-on advisories. Firmware diffing after a 72-CVE drop typically surfaces public PoCs within weeks. Subscribe to HPE security notifications and monitor CISA KEV — if any of these CVEs land there, federal agencies get binding remediation deadlines and private-sector orgs should treat them the same way.

The strategic lesson here is one I repeat to every CISO I advise: network infrastructure is part of your attack surface management program, not an exempt category. If your vulnerability scanners and patch cadences cover Windows and Linux but treat controllers, switches, and APs as 'set and forget,' you have a structural blind spot exactly where attackers are increasingly looking.

Related Resources

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