Vulnerabilities

HPE fixes eight CVSS 10.0 flaws in Aruba wireless controllers

HPE bulletin HPESBNW05162 fixes 72 ArubaOS flaws, eight rated CVSS 10.0. No exploitation yet: what UK teams should patch first.

Network motif graphic with the headline Eight perfect-ten flaws hit Aruba wireless

HPE has fixed 72 vulnerabilities in the ArubaOS software behind its campus wireless controllers, gateways and access points, and eight of them carry the maximum CVSS score of 10.0. Nobody is known to be exploiting them yet, which makes this weekend the best time to patch: once that changes, you will be doing it under pressure.

What happened

On 22 October 2026 Hewlett Packard Enterprise published security bulletin HPESBNW05162. It covers AOS-8 and AOS-10, the two generations of ArubaOS that run Aruba Mobility Conductors, Mobility Controllers, Mobility Gateways and access points, including AOS-8 Instant APs. Canadian and German national agencies issued their own alerts within a day.

Of the 72 flaws, eight are rated 10.0: CVE-2026-79844 to CVE-2026-79851. The records I checked directly in the CVE database carry a near worst-case vector. The flaws are reachable over the network, with low attack complexity, no privileges and no user interaction, and the scope changes so an attacker can reach beyond the vulnerable component. Rescana’s analysis of the bulletin counts 33 of the 72 issues as critical in total. Safeguard.sh and GBHackers both report a further SSH authentication bypass in AOS-8, CVE-2026-79855, and HPE’s CVE record confirms its 9.8 score. It can give an unauthenticated attacker administrative access.

HPE says it knows of no public exploit code or discussion of the flaws, and none of the CVEs was on CISA’s Known Exploited Vulnerabilities catalogue at the time of writing.

The technical picture

The eight 10.0 flaws fall into four groups. On AOS-10, CVE-2026-79844 is an authentication bypass that leads to remote code execution, CVE-2026-79845 is an authentication bypass in PAPI, and CVE-2026-79847 and CVE-2026-79851 are unauthenticated buffer overflows that also lead to code execution. On AOS-8, CVE-2026-79846 covers unauthenticated command injection, CVE-2026-79848 and CVE-2026-79849 are SQL injection bugs that end in code execution, and CVE-2026-79850 is another authentication bypass leading to RCE.

PAPI is Aruba’s proprietary control protocol between access points and controllers, carried on UDP port 8211. According to Safeguard.sh, 22 of the 72 bugs involve PAPI and 58 need no privileges at all. That matters because PAPI is designed to be reachable from wherever your access points sit, which in many estates means broad internal reach, not a locked-down management VLAN.

Two caveats apply. First, HPE’s wording for some flaws, including CVE-2026-79844, says code execution depends on preconditions outside the attacker’s control, and HPE has not said what those are. Second, the records are messy. The CVE-2026-79845 record that the public database returns is not HPE’s. It describes a SQL injection in an unrelated PHP inventory application, assigned by VulDB in August. Rescana also reports conflicting published scores for CVE-2026-79881. Track these issues by the HPE bulletin ID, not scanner output keyed to one CVE.

The fixed releases are AOS-10 10.8.1.2, 10.7.2.7 and 10.4.1.14, and AOS-8 8.13.3.1 and 8.10.0.24. Some CVE records, such as those for CVE-2026-79844 and CVE-2026-79846, list affected ranges that also take in the 10.6, 10.3 and 8.12 trains, which have no fix listed, so devices on those trains will need to move to a supported branch. HPE presumes that end-of-maintenance releases are affected and will not fix them. AOS-CX switches and Instant On kit are not covered by this bulletin.

Checklist of six priority actions for patching HPE Aruba AOS-8 and AOS-10 devices after bulletin HPESBNW05162

Why it matters for UK organisations

Aruba controller-based wireless is a common design for large campus networks in education, healthcare, local government, retail and corporate offices, all sectors well represented in the UK. Wireless controllers are rarely first on a patch list. They sit in the comms room, upgrades interrupt clients across a whole site, and change boards are wary of them. That reluctance is exactly what attackers count on.

The past few years show the pattern. Edge and infrastructure appliances, from VPN concentrators to SD-WAN orchestrators, are a favourite route into UK networks because they are trusted, poorly monitored and seldom run endpoint detection. A wireless controller that an attacker controls is a strong foothold: it sees user traffic and authentication flows, and it often holds RADIUS shared secrets and integrations with identity systems.

With the Cyber Security and Resilience Bill set to bring managed service providers into scope, an MSP running Aruba estates for several clients carries the risk multiplied. One unpatched conductor template could expose every customer it serves.

Expert view

In my experience, wireless infrastructure is one of the least segmented parts of a typical enterprise network. When we test, we often find controller web interfaces and SSH reachable from ordinary user VLANs. Occasionally they are reachable from the guest network too, because someone opened them during an install and nobody closed them. Against bugs like these, that turns a contractor’s laptop or a compromised workstation into a direct path to the controller.

There is no known exploitation yet, but a bulletin with 72 fixes gives reverse engineers plenty to work with. Patch diffing on network appliances has become fast, and CISA’s enrichment marks the critical records I checked as automatable. My working assumption is that a weaponised exploit for at least one of these will surface within weeks, not months.

I would also caution against reading “preconditions outside the attacker’s control” as reassurance. Until HPE explains those conditions, you cannot tell whether your configuration meets them, so assume it does.

What to do now

  1. Inventory first. List every conductor, controller, gateway and AP running AOS-8 or AOS-10, including virtual instances and any devices managed through HPE Aruba Networking Central, and record the exact firmware train of each.
  2. Patch by exposure. Start with anything whose management interface is reachable from the internet, then devices that accept PAPI from untrusted or guest segments, then conductors, then controllers serving guest VLANs. Upgrade to 10.8.1.2, 10.7.2.7, 10.4.1.14, 8.13.3.1 or 8.10.0.24 as appropriate, and confirm cluster redundancy so the work can be done in rolling windows.
  3. Get off unsupported trains. End-of-maintenance releases, and trains with no listed fix, need a migration plan now. This maps directly to the Cyber Essentials security update management control, which requires unsupported software to be removed and high-risk or critical updates (CVSS 7.0 or above) to be applied within 14 days of release.
  4. Lock down management until patched. Following HPE’s interim advice, move CLI and web management onto their own Layer 2 segment or VLAN, and enforce Layer 3 firewall rules so only named admin hosts can reach them. Limit UDP 8211 to known access point and controller addresses (Cyber Essentials firewalls and secure configuration).
  5. Turn on accounting and look back. Send command accounting and authentication logs to a central collector. Review them for unexpected admin logins, new local accounts or configuration changes, and rotate administrative and RADIUS credentials if anything looks wrong.
  6. Fix your tooling. Check that vulnerability scanners are matching on the HPE bulletin, not the mislabelled CVE-2026-79845 record.

Bottom line

Seventy-two fixes is a lot for any platform, and the severity is not inflated: unauthenticated code execution on the box that runs your Wi-Fi is about as bad as it gets for campus infrastructure. With no exploitation reported, you still have time to patch in an orderly way. Organisations that use that time, segment their management plane and retire unsupported firmware will be in a far better place when, as usually happens, exploit code turns up.

Sources