HPE Aruba AOS Critical Flaws. Patch. Restrict. Watch.
HPE has fixed 72 vulnerabilities in Aruba AOS-8 and AOS-10, the software behind Aruba wireless controllers, gateways and access points. Eight are rated 10.0 and most need no login. Clear steps for businesses, internal IT teams and MSPs running Aruba wireless.
At a Glance
Facts from HPE security bulletin HPESBNW05162, published 22 October 2026. No known exploitation, no public exploit code and no IOCs published by HPE. Not in the CISA KEV catalog (checked 23 October 2026, 17:25 BST, catalog version 2026.10.21). Last updated 23 October 2026, 17:30 BST.
Patch available
No known exploitation or public exploit code. HPE urges customers to patch because of the breadth and impact of the flaws.
Eight at CVSS 10.0
Authentication bypass, command injection, SQL injection and buffer overflows, all unauthenticated over the network. Scores across the 72 CVEs range from 10.0 down to 3.3, with a large critical band from 9.3 to 9.8 that includes 9.4 and 9.6 items.
Management plane
PAPI on UDP 8211, the SSH daemon (CVE-2026-79855, AOS-8) and the web management interface are all affected.
HPE publishes HPESBNW05162 with fixes for 72 CVEs across AOS-8 and AOS-10.
No exploitation reported. Not in CISA KEV.
Inventory every Aruba device, patch gateways and controllers first and lock down management access.
Affected products and versions
- Mobility Conductors, Mobility Controllers (hardware and virtual) and Mobility Gateways managed by HPE Networking Central
- AOS-10 access points and AOS-8 Instant access points
- AOS-10: 10.8.1.1, 10.7.2.6 and 10.4.1.13 and below, plus the 10.3.x and 10.6.x trains
- AOS-8: 8.13.3.0 and 8.10.0.23 and below, plus the 8.12.x train
- 10.3.x, 10.6.x and 8.12.x have no fixed release of their own, so the fix is to move to a fixed train
- End of Maintenance releases are presumed affected. End of Support releases were not assessed by HPE, so treat them as potentially impacted
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Patch and restrict
- List every conductor, controller, gateway and access point with its AOS version.
- Upgrade internet-facing and branch gateways and controllers first.
- Restrict CLI and web management to a management VLAN or firewall policy (HPE workaround).
- Our advice: limit UDP 8211 to AP and controller subnets and keep it off the internet and guest Wi-Fi.
Hunt and preserve
- Review admin logins and look for new accounts.
- Compare the running config with your last known good copy.
- Look for UDP 8211 or web UI traffic from outside the management network.
- Check for unexpected crashes, reboots and outbound connections.
Proactive: Patch First, Then Reduce Exposure
Upgrading is the fix. Restricting access buys time but does not remove the flaws.
Build an inventory
Record the model, role and AOS version of every conductor, controller, gateway and access point, for your own estate and each client. On a controller or gateway, the version is shown by:
show versionFor Instant access points, run show version on the virtual controller. For Central-managed gateways, check the version in Central and confirm who applies upgrades.
Upgrade on the right train
Move each device to the fixed release on its own train:
- AOS-10.8.x: 10.8.1.2 or later
- AOS-10.7.x: 10.7.2.7 or later
- AOS-10.4.x: 10.4.1.14 or later
- AOS-8.13.x: 8.13.3.1 or later
- AOS-8.10.x: 8.10.0.24 or later
Patch internet-facing and branch gateways and controllers first, then access points. Devices on 10.3.x, 10.6.x or 8.12.x, or on End of Maintenance or End of Support releases, need to move to one of the fixed trains above. If you suspect compromise, preserve logs and config first (see Reactive).
Lock down management access
HPE's only workaround is to restrict the CLI and web-based management interfaces to a dedicated layer 2 segment or VLAN and/or control them with firewall policies, with accounting and logging of user activity. It reduces risk but is not a fix.
Keep PAPI and management off untrusted networks
Our own advice, beyond HPE's workaround: limit PAPI on UDP 8211 so it only reaches controllers from access point and controller subnets, and make sure UDP 8211, SSH and the web UI are not reachable from the internet, guest Wi-Fi or other untrusted segments. Several flaws only need adjacent network access, so isolate guest Wi-Fi from the management network. A quick external check from outside your network:
nmap -sU -p 8211 <public-ip>
nmap -sT -p 22,80,443,4343 <public-ip>Free Detection Pack
Built by the CybaVerse threat hunt team. Check versions across every controller, gateway and access point you or your clients run, then hunt with KQL or Sigma. Everything is read-only.
check_aos_version.sh / Check-AosVersion.ps1
Read-only checkers that take a pasted show version, a version string or an inventory CSV and return a verdict per device. They never connect to a device or probe PAPI. 10.3.x, 10.6.x, 8.12.x and older trains are reported as likely vulnerable.
./check_aos_version.sh --version "ArubaOS (MODEL: 7210), Version 8.10.0.23"
./check_aos_version.sh --csv inventory.csv
pwsh ./Check-AosVersion.ps1 -CsvPath inventory.csvKQL hunts and Sigma rules
KQL for Microsoft Sentinel and Defender covering admin logins, new accounts, config changes, reboots and crashes, PAPI, SSH and web UI traffic from outside the management network, and outbound connections from controllers. Four matching Sigma rules are included.
Verdicts
- PATCHEDAt or above the fixed release on a listed train.
- LIKELY VULNERABLEBelow the fix, or on 10.3.x, 10.6.x, 8.12.x or an older train. Upgrade to a fixed train.
- UNKNOWNA newer train HPE has not assessed, or unreadable input.
- ERRORThe check failed, so the result is unknown.
Exit codes
| Code | Meaning |
|---|---|
| 0 | All PATCHED |
| 1 | Any LIKELY VULNERABLE |
| 2 | Any UNKNOWN, none vulnerable |
| 3 | ERROR |
MSPs and internal IT teams can use the exit code in RMM or deployment tooling to flag devices at scale.
Know the limits
- The KQL has not been run on a live tenant. Validate table and field names against your own connector first.
- The IP addresses and subnets in the queries and rules (management subnets, controller IPs) are placeholders. Replace them with your own.
- HPE published no IOCs, so the pack contains none. The log keywords are generic and need tuning against your controller logs.
- A clean result does not rule out compromise.
Reactive: How to Hunt
HPE has published no IOCs and no exploitation has been seen, so hunt for behaviour instead. CybaOps can run these hunts across your estate or your clients'.
Unexpected admin logins and new accounts
Review management logins for unknown source addresses, odd hours or failed logins followed by a success, and look for admin accounts nobody created.
show mgmt-user
show audit-trail
show log security 100Unticketed configuration changes
Compare the running configuration with your last known good backup and match every change to a change ticket.
Management traffic from the wrong place
In firewall and NetFlow logs, look for traffic to UDP 8211, SSH or the web UI on controllers and gateways from anywhere outside the management network, including guest Wi-Fi.
Crashes, reboots and outbound connections
Unexpected process crashes or reboots can follow buffer overflow attempts. Controllers and gateways should only talk to known services, so investigate any new outbound connection from them.
show switches
show crashinfo
show log system 100If you find signs of compromise
- Isolate the management network and block external access to the device.
- Export logs, the running config and crash information before changing anything.
- Reimage onto a fixed release rather than upgrading in place.
- Rotate admin passwords, RADIUS shared secrets and any other keys stored on the device.
- Check for lateral movement from the controller or gateway into the wider network.
HPE Aruba AOS FAQ
Short answers based on HPE bulletin HPESBNW05162 as of 22 October 2026.
Which versions are affected?
AOS-10.8.1.1, 10.7.2.6 and 10.4.1.13 and below, the 10.3.x and 10.6.x trains, AOS-8.13.3.0 and 8.10.0.23 and below, and the 8.12.x train, on Mobility Conductors, Mobility Controllers, Mobility Gateways managed by Central, AOS-10 access points and AOS-8 Instant access points. End of Maintenance releases are presumed affected and End of Support releases were not assessed, so treat them as potentially impacted.
Which versions fix it?
AOS-10.8.1.2, 10.7.2.7 or 10.4.1.14 and above, and AOS-8.13.3.1 or 8.10.0.24 and above. Match each device to its own release train. Devices on 10.3.x, 10.6.x or 8.12.x must move to a fixed train.
Is it being exploited?
Not as far as is known. HPE knows of no public discussion or exploit code and has published no IOCs. None of the CVEs is in the CISA KEV catalog as checked on 23 October 2026. With 72 flaws and eight rated 10.0, that can change quickly, so patch now.
Can I mitigate without patching?
Only partly. HPE's only workaround is restricting the CLI and web management interfaces to a dedicated VLAN or behind firewall policy, with logging. Our own advice is also to limit PAPI on UDP 8211 to access point and controller subnets and keep it off the internet and guest networks. Several flaws need only adjacent network access, so guest Wi-Fi counts as untrusted.
Why does this matter for MSPs?
One controller or conductor usually manages the wireless for a whole site or client. Taking it over gives an attacker a privileged foothold inside the network, close to every connected user and device.
Detect and Remediate Aruba Exposure Across Your Estate
CybaOps monitors your network infrastructure, servers and management platforms, whether that's your own business or your clients'. Our SOC runs these threat hunts, alerts on suspicious management activity and drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.