If you run HPE Aruba wireless networking gear, upgrade AOS-8 or AOS-10 to a fixed release now. HPE’s security bulletin HPESBNW05162, published on October 22, 2026, patches 72 vulnerabilities in the wireless operating systems that run Aruba Mobility Conductors, Mobility Controllers, Mobility Gateways, and access points. Eight of those flaws carry the maximum CVSS score of 10.0, and several can be reached by an unauthenticated attacker over the network. This is not a routine patch bundle to schedule for next quarter. The controllers and gateways at the centre of a wireless network hold an unusually privileged position: they decide who joins the network, how traffic is routed, and which policies apply. A compromise there can become a foothold for traffic interception, credential theft, and movement deeper into the network.
HPE said at publication that it was not aware of public exploit code or public discussion of these flaws, and no exploitation in the wild had been reported. That is genuinely good news, but it is not a reason to wait. Once a bulletin lists 72 flaws with version ranges and fixed builds, attackers have a clear map of what to test against unpatched systems. The window between disclosure and weaponisation is often short, and wireless infrastructure is frequently patched last because teams worry about disrupting connectivity. Plan the upgrade as a controlled change, but treat it as urgent.
What HPE actually patched
HPESBNW05162 is a single coordinated rollup covering both wireless trains: AOS-8 and AOS-10. The affected products are Mobility Conductors, Mobility Controllers, Mobility Gateways managed by HPE Networking Central, AOS-10 access points, and AOS-8 Instant access points. HPE adds that any compatible hardware, Mobility solution, access point, or virtual machine running an affected version is in scope. Do not confuse this bulletin with AOS-CX, HPE’s switch operating system, which is a separate product line and is not covered here.
Across the 72 flaws, the issue types are familiar to anyone who follows network security: authentication bypasses, command injection, SQL injection, buffer overflows, memory corruption, path traversal, information disclosure, cross-site scripting, file manipulation, and denial of service. The common thread in the most serious cases is the outcome. HPE repeatedly warns that successful exploitation lets an attacker execute arbitrary code as a privileged user on the underlying operating system of the device. That is the difference between a bug that crashes a service and a bug that hands over the box.
The eight flaws rated CVSS 10.0
A CVSS score of 10.0 is the top of the scale. It means the flaw is network-reachable, needs no authentication and no user interaction, and has a severe impact on confidentiality, integrity, or availability. HPE rates eight flaws in this bulletin at 10.0, numbered CVE-2026-79844 through CVE-2026-79851. Four affect AOS-10 and four affect AOS-8.
CVE-2026-79844: AOS-10 authentication bypass
This flaw lets an unauthenticated attacker run arbitrary commands on the underlying host if certain preconditions outside the attacker’s control are met. That caveat matters: it is not a guaranteed one-step takeover in every deployment. But an authentication bypass that can end in command execution is still at the top of the patch queue, because the preconditions may well be present in a given environment and an attacker only needs to find one that is.
CVE-2026-79845: AOS-10 PAPI authentication bypass
PAPI is the protocol Aruba controllers and access points use to talk to each other, carried over UDP port 8211. This flaw lets an attacker circumvent existing authentication controls in the PAPI service and gain administrator access, change configurations, and access or manipulate sensitive information. Even where it does not directly give command execution, administrator access to a wireless controller is close enough: configuration changes alone can weaken security policies, expose traffic, or open new paths into the network.
CVE-2026-79846: AOS-8 command injection
A command injection flaw lets an attacker smuggle operating system commands into input the device fails to handle safely. In this case, the result is commands running on the host. Command injection on a network device is particularly dangerous because the device itself is trusted by the rest of the network, and its traffic is rarely inspected as closely as traffic from a laptop or server.
CVE-2026-79847 and CVE-2026-79851: AOS-10 buffer overflows
Both of these flaws are buffer overflows that enable unauthenticated remote code execution. A buffer overflow corrupts memory by writing more data than a program expects, and when that corruption can be controlled, it becomes a way to run attacker code. These two are the clearest examples in the bulletin of why the 10.0 rating is justified: no login, no click, just a network packet and a vulnerable device.
CVE-2026-79848 and CVE-2026-79849: AOS-8 SQL injection leading to code execution
SQL injection is usually associated with stealing or altering database records. These two AOS-8 flaws go further: the injection can extend beyond the database and end in command execution on the operating system. That escalation from data access to host control is what pushes an SQL injection flaw into maximum-severity territory.
CVE-2026-79850: AOS-8 authentication bypass to root
This is arguably the starkest entry in the list. An unauthenticated attacker can bypass authentication on AOS-8 and execute commands as root on the underlying operating system. Root is the highest privilege level available. There is no higher rung to climb after that. If this flaw applies to your deployment, it alone justifies an emergency change window.
Beyond the eight maximum-severity flaws, the bulletin includes other high-severity issues worth noting in triage. CVE-2026-79855, for example, is an AOS-8 SSH authentication bypass that can grant unauthenticated administrative access, and CVE-2026-79860 can be triggered by sending specially crafted packets to UDP port 8211 on affected AOS-8 systems. Do not stop at the eight 10.0 flaws when you assess exposure. The full set of 72 is the patch target.
Which versions are affected and which to install
Check every Aruba wireless device you own, including units in branch offices, warehouses, clinics, schools, and sites you inherited from a previous team. Controllers and gateways are the priority, but access points running affected versions are in scope too. Use your controller inventory, HPE Networking Central, or a network scan to build the list, and do not assume a device is safe because it is small or rarely touched. Forgotten access points are a classic blind spot.
The affected version ranges reported for this bulletin are:
- AOS-10.8.0.0 through 10.8.1.1
- AOS-10.6.0.0 through 10.7.2.6
- AOS-10.3.0.0 through 10.4.1.13
- AOS-8.12.0.0 through 8.13.3.0
- AOS-8.10.0.0 through 8.10.0.23
Upgrade to a fixed release on your train, or later:
- AOS-10: 10.8.1.2, 10.7.2.7, or 10.4.1.14
- AOS-8: 8.13.3.1 or 8.10.0.24
Match the fixed build to the release train you are already running rather than jumping trains mid-incident, unless HPE guidance for your hardware says otherwise. Test the upgrade in a lab or on a non-critical site first if you can, but do not let perfect testing become an excuse for indefinite delay. A staged rollout across sites, starting with internet-facing and guest-accessible deployments, is a reasonable middle path. Devices on end-of-maintenance releases should be presumed affected and need a separate migration decision: there is no fixed build on a dead train.
What to do if you cannot patch today
Sometimes a patch cannot go in immediately. A hospital, a warehouse, or a school may not have a maintenance window until the weekend, or a change freeze may be in force. HPE’s own mitigation guidance for this bulletin is to restrict the command-line and web-based management interfaces to a dedicated layer 2 segment or VLAN, and to control them with layer 3 firewall policies. HPE also advises logging user activity. Treat those steps as exposure reduction, not as a substitute for patching. With dozens of unauthenticated flaws in play, segmentation alone does not close the risk.
In practice, that means several concrete steps while you wait for a window. First, make sure management interfaces are not reachable from guest Wi-Fi, user VLANs, or the internet. Guest networks are a particular concern here because several flaws are reachable from an adjacent network, which is exactly where a guest device sits. Second, restrict PAPI traffic on UDP port 8211 to trusted devices only, since PAPI is central to several of the most serious flaws. Third, review logs for unexpected administrator logins, configuration changes, and new accounts. Fourth, disable any management access you do not need, and confirm that default or shared credentials are not still in use. If you find signs of compromise, preserve logs, isolate the device, and follow your incident response process rather than simply patching over the evidence.
After patching, verify rather than assume. Confirm the new version on each controller, gateway, and access point, re-check that management interfaces are still restricted, and review logs again for activity during the window. A patch applied to the controller but not to a cluster of access points leaves the deployment half done. Update your asset inventory at the same time, so the next bulletin does not start with another hunt for forgotten devices.
Why wireless infrastructure deserves the same urgency as servers
Wireless controllers rarely get the attention that Windows or server patching receives, yet every laptop, phone, and tablet in a building reaches its resources through them. A compromised controller or access point can become a foothold for traffic interception and lateral movement, and because network devices are trusted infrastructure, malicious activity from them can be hard to spot. Network and endpoint teams should coordinate on this one: the wireless team owns the upgrade, and the security team can help watch for unusual activity afterwards.
The timing also matters. This bulletin landed alongside a wave of other October disclosures, including the Collabora Online flaw affecting Nextcloud servers and the Arista VeloCloud zero-day, both of which drew CISA attention. Patch fatigue is real, but it is not a strategy. Triage by exposure, not by inbox order: internet-facing and guest-reachable wireless gear first, then internal controllers, then the long tail of access points. And if your organisation is still working through the October Patch Tuesday workload, add this bulletin to the same change cycle rather than parking it for a separate round.
The bottom line is simple. HPE has published the fixes, the fixed versions are clear, and the worst flaws need no credentials. Upgrade AOS-10 to 10.8.1.2, 10.7.2.7, or 10.4.1.14, and AOS-8 to 8.13.3.1 or 8.10.0.24. Until the upgrade is complete, keep management interfaces isolated, restrict PAPI traffic, and watch the logs. A wireless network is only as strong as the controller running it.
Frequently asked questions
What is the HPE Aruba AOS vulnerability bulletin HPESBNW05162?
It is HPE’s October 22, 2026 security bulletin for the AOS-8 and AOS-10 wireless operating systems. It patches 72 vulnerabilities in Aruba Mobility Conductors, Mobility Controllers, Mobility Gateways, and access points, including eight flaws rated CVSS 10.0.
Which devices are affected by the HPE Aruba AOS flaws?
Mobility Conductors, Mobility Controllers, Mobility Gateways managed by HPE Networking Central, AOS-10 access points, and AOS-8 Instant access points running affected versions. Any compatible hardware or virtual machine on an affected version is in scope. AOS-CX switches are not covered by this bulletin.
What are the fixed versions for AOS-8 and AOS-10?
For AOS-10, upgrade to 10.8.1.2, 10.7.2.7, or 10.4.1.14, depending on your release train. For AOS-8, upgrade to 8.13.3.1 or 8.10.0.24, or a later fixed release.
Are the HPE Aruba AOS flaws being exploited in the wild?
HPE said at publication that it was not aware of public exploit code or public discussion of these flaws, and no exploitation had been reported. That status can change quickly after disclosure, so it should not be treated as a reason to delay patching.
What should I do if I cannot patch my Aruba devices immediately?
Restrict the command-line and web-based management interfaces to a dedicated VLAN or segment, control them with firewall policies, restrict PAPI traffic on UDP port 8211 to trusted devices, keep management interfaces off guest networks and the internet, and review logs for unexpected administrator activity until the upgrade is complete.