HPE Aruba AOS-8 and AOS-10: 72 CVEs, Eight 10.0 Flaws, What to Patch

HPE security bulletin HPESBNW05162, published 22 October 2026, fixes 72 vulnerabilities in the AOS-8 and AOS-10 wireless operating systems that run Aruba Mobility Conductors, Mobility Controllers, Central-managed Gateways and access points. Eight are rated CVSS 10.0. Upgrade to 10.8.1.2, 10.7.2.7, 10.4.1.14, 8.13.3.1 or 8.10.0.24, and restrict management access now.

HPE says it is not aware of public exploit code or public discussion of these flaws, and that most of them came from its own internal security research. That is the good news. The less comfortable part is the shape of the list: 58 of the 72 issues need no credentials at all, 22 of them involve PAPI, the UDP control protocol that access points and controllers use to talk to each other, and the critical group includes authentication bypasses, SQL injection and buffer overflows that end in commands running on the device's underlying operating system. The bulletin itself urges customers to patch "due to the complexity, breadth, and impact" of the issues.

This post is for the people who have to act on it: network engineers, wireless teams, security operations and the managers who own the change window. It covers what the official records say (and where they disagree with each other), every affected and fixed version, a breakdown of all 72 CVEs, which ones to treat first, how to find every AOS device you own and check its version and exposure, how to restrict PAPI and management interfaces while you wait for a window, and what the next bulletin like this should find already in place.

What happened

All times are UTC. Minute-level times come from the CSAF file HPE published with the bulletin, the CVE.org records, the NVD API and the CISA enrichment record. The BleepingComputer time is as shown on its article.

As of the CISA Known Exploited Vulnerabilities catalog version we checked (2026.10.21), none of the 72 CVEs is listed. That catalog predates the bulletin by a day, so the absence tells you nothing yet. Check the live catalog before you treat any of these as unexploited.

What the official records say

There are four official places to read about this bulletin, and they do not all say the same thing. Here is what each one holds, and where they differ.

The HPE bulletin page and the signed text advisory. HPE publishes the bulletin on its support site as document hpesbnw05162en_us, release date and last updated 22 October 2026, document version 1. The page lists the potential security impact as local access restriction bypass plus remote arbitrary code execution, cross-site scripting, memory corruption and buffer overflow. A PGP-signed plain text copy and a CSAF JSON copy are published at csaf.arubanetworking.hpe.com. The text copy is the version to file as evidence, because the signature lets you prove later that you read the original.

The CSAF JSON file. This is the machine-readable version, generated with the Secvisogram tool. It lists all 72 CVEs, each with its own CVSS 3.1 vector, the affected version ranges as product IDs, the fixed versions, the workaround text and the credits. If you run a vulnerability management tool that ingests CSAF, this is the file it should read.

The CVE.org records. HPE published the records itself. As of 23 October they carry the title, the CVSS vector, the affected version ranges and a link to the bulletin, but the description field reads "No description provided" and the product field reads "Unknown product". CISA's enrichment container adds a CWE for some records (CWE-288 for the authentication bypasses CVE-2026-79844 and CVE-2026-79850, CWE-89 for the SQL injection records, CWE-119 for the buffer overflows) and SSVC decision points.

NVD. NVD shows the records as "Received", which means no NVD analysis yet and no NVD-assigned CPE. Tools that rely on NVD CPE matching to flag affected devices may not flag these devices for some time. Use the version ranges in this post or in the CSAF file instead.

Where the sources disagree

Eight 10.0 scores, not nine. Some early summaries counted CVE-2026-79852, an unauthenticated SQL injection in the web management interface, among the maximum severity flaws. The bulletin, the CSAF file and the CVE.org record all score it 9.8 with an unchanged scope. Eight CVEs are rated 10.0: CVE-2026-79844 through CVE-2026-79851. BleepingComputer's "eight" matches the bulletin.

CVE-2026-79845 points at the wrong product in public databases. The bulletin and CSAF file use CVE-2026-79845 for an AOS-10 PAPI authentication bypass rated 10.0. On CVE.org and NVD, as of 23 October, CVE-2026-79845 is a different record entirely: a SQL injection in an unrelated PHP inventory application, published by a different numbering authority on 25 August 2026 and scored 7.3. The two records were reserved within seconds of each other on 25 August. We do not know how the collision happened, and HPE may correct it. Until then, any tool that looks up CVE-2026-79845 in NVD will show the wrong product, the wrong score and the wrong affected versions. Track this one by the bulletin, not by the CVE database.

CVE-2026-79881 has three different scores. The detail section of the bulletin and the CVE.org record give 8.5 with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H. The summary score table on the HPE bulletin page gives 8.3 for the same vector. The CSAF JSON gives 9.6 with an adjacent network vector, CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. By the CVSS 3.1 formula in FIRST's specification, the network vector works out to 8.3, so the 8.5 looks like a typo and the CSAF entry looks like a copy of the neighbouring adjacent-network rows. Whichever is right, it is an unauthenticated route to code execution as a privileged user on AOS-8, and it is fixed by the same upgrade. Do not let a scoring argument delay it.

Exploitation status. Every source agrees: no known exploitation and no public exploit code as of release. CISA's SSVC entry records exploitation as "none" and also marks the critical records "automatable", which is CISA's way of saying that, once someone works out how, the attack could be run at scale without a human in the loop.

Technical details

This section collects the defender-useful specifics from the bulletin, the CSAF file and the CVE.org records. HPE has not published file hashes, indicators of compromise, network signatures, exploit details or interface names beyond what is quoted here, and we do not add any. Every value below was read from a fetched primary source.

Advisory identifiers

Affected and fixed versions

Products in scope, per the bulletin: Mobility Conductors, Mobility Controllers, Mobility Gateways managed by HPE Networking Central, AOS-10 Access Points (AOS-AP) and AOS-8 Instant Access Points (AOS-IAP).

Two things in that table matter for planning.

First, the machine-readable ranges are wider than the headline list. The CSAF file and CVE records fold AOS-10.6 into the 10.7 range, AOS-10.3 into the 10.4 range, and AOS-8.12 into the 8.13 range. Those trains have no fixed release of their own in this bulletin. In May, HPE issued a one-time exception patch for AOS-8.12 (8.12.0.7); this time there is none. If you run 8.12, 10.6, 10.5 or 10.3, your fixed version is on a different train, and the upgrade is a train change, not a patch.

Second, the bulletin says software that has reached End of Maintenance is "presumed to be affected" and not covered, and that HPE has not assessed releases past End of Support at all. Treat AOS-8.11, 8.9 and older, and AOS-10.5 and older, as vulnerable with no fix. The May bulletin listed AOS-8.6 through 8.9, 8.11, AOS-10.3, 10.5 and 10.6, and AOS-6.5.4 as end of maintenance; nothing in the October bulletin suggests that has changed.

Download location, per the bulletin: the HPE Networking Support Portal at networkingsupport.hpe.com.

The eight CVSS 10.0 vulnerabilities

All eight vectors share the same prefix, CVSS:3.1/, and all eight have scope changed (S:C), which is why they reach 10.0 rather than 9.8: the scoring says a compromise of the AOS component reaches beyond it, to the underlying operating system and the network the device controls. Each CVE groups several internal HPE findings. CVE-2026-79851 alone maps to eleven internal references, and CVE-2026-79847 and CVE-2026-79850 to seven each, which suggests these are families of related bugs in the same interfaces rather than single defects.

Three of the critical descriptions carry the qualifier "if certain preconditions outside of the attacker's control are met" (CVE-2026-79844, CVE-2026-79846 and, in the High group, CVE-2026-79891). HPE does not say what the preconditions are. Do not read that phrase as "not exploitable in my network"; read it as "we do not know which configurations are exposed, so patch all of them".

The full set of 72, by the numbers

The counts below come from our parse of the CSAF JSON file, cross-checked against the signed text.

The 9.8 group deserves as much attention as the 10.0 group. It includes CVE-2026-79855, an authentication bypass in the AOS-8 SSH daemon that HPE says leads to administrative privileges and complete compromise; CVE-2026-79857 and CVE-2026-79861, unauthenticated command injection in PAPI on AOS-8 and AOS-10; CVE-2026-79860, a buffer overflow reached by packets "destined to the PAPI" UDP port 8211; and CVE-2026-79853, an unauthenticated information disclosure in AOS-10 that HPE says leads to code execution. The only differences from the 10.0 group are scope, not reachability or impact.

The 9.6 and 9.3 groups are adjacent-network flaws: an attacker has to be on the same layer 2 segment or otherwise logically adjacent. On a wireless network that is not much comfort, because the adjacent network can be the network your users, guests and contractors join. CVE-2026-79876, for example, is an unauthenticated information disclosure in AOS-10 "Wi-Fi frame processing", and CVE-2026-79866 is a path traversal in AOS-8 PAPI that lets an adjacent attacker read, modify and delete files.

The remaining groups are what you would expect of a large clean-up release: authenticated command injection that needs high privileges (CVE-2026-79956, CVE-2026-95704 to CVE-2026-95709, all 7.2), denial of service through PAPI and the web interface (CVE-2026-79885, 79886, 79893, 79894, 79895, 79955), a stored cross-site scripting issue in the web management interface (CVE-2026-95717, 5.5), and a handful of local issues.

Credits

HPE credits most findings to its own internal research. External researchers credited through HPE's bug bounty programme include moonv (CVE-2026-79848, 79849, 79852, 79853, 95704, 95706), zzcentury (CVE-2026-79862, 79863, 95708), m0omo0d (CVE-2026-79872, 79880), LIUPENG (CVE-2026-79956, 95707, 95709, 95717, 95719), Diego Gomez and David Kierznowski (CVE-2026-79887, 79888, 79889), Michael Messner, Benedikt Kuehne and Caio Adler Goncalves Farias (CVE-2026-95705), and PinkDraconian (CVE-2026-95715).

Indicators of compromise

None published. HPE has not released hashes, IP addresses, domains, log signatures or network signatures for any of the 72 CVEs, which is normal for an internally found, unexploited set. If you see an indicator list for this bulletin elsewhere, ask where it came from before you load it into a blocking control.

How it works, in plain language

You do not need exploit detail to make good decisions here. You need to know which doors these bugs sit behind.

The management plane. Every AOS controller, conductor, gateway and Instant AP has an SSH and command line interface, a web management interface and, on AOS-10, APIs used by Central and by automation. Many of the critical bugs live in those interfaces: SQL injection and buffer overflows in web endpoints, an authentication bypass in the SSH daemon, command injection in the CLI. HPE's workaround text is entirely about this plane: restrict the CLI and web interfaces to a dedicated layer 2 segment or VLAN, put layer 3 firewall policy in front of them, and turn on accounting so you can see who did what.

PAPI. PAPI is Aruba's long-standing control protocol between access points and controllers, carried over UDP port 8211. Aruba's own 2016 control plane security advisory describes it as designed for efficiency with "a light form of encryption", and explains that Control Plane Security (CPsec) was introduced in ArubaOS 5.0 to wrap PAPI in an IPsec tunnel authenticated by factory certificates. HPE's support knowledge base describes PAPI as carrying configuration download plus the control channels for adaptive radio management and wireless intrusion detection. Twenty-two of the 72 CVEs touch PAPI, including two of the 10.0s, and several descriptions say the attack works by sending crafted packets to the PAPI UDP port. The practical upshot: a device that accepts PAPI from any address on your network accepts these bugs from any address on your network.

Underlying operating system. Many descriptions end the same way: arbitrary commands or code "as a privileged user on the underlying operating system". A successful attack here is not a configuration change in a web console; it is control of the box that authenticates your Wi-Fi users, holds RADIUS shared secrets and VPN keys, and sees and routes their traffic.

Network versus adjacent. In CVSS terms, a network attack vector means the attacker can be anywhere that can route packets to the interface. Adjacent means they must share a layer 2 or logically adjacent network. For a wireless controller, "adjacent" can include the client VLANs you hand out to anyone with the guest password, which is why HPE rates many adjacent flaws critical.

Who is affected

AOS-CX, the switching operating system, is a separate product with its own bulletins. We covered two of this year's AOS-CX issues in CVE-2026-73749 in the AOS-CX daemon and the CVE-2026-23813 AOS-CX authentication bypass. Nothing in HPESBNW05162 applies to AOS-CX.

What to patch first

Seventy-two CVEs on one fixed build makes the decision simple in one sense: every affected device needs the same upgrade, and there is no cherry-picking individual fixes. What you can choose is order. Here is a sensible one.

1. Anything whose management interfaces are reachable from the internet. Controllers and gateways with the web interface (often HTTPS on port 4343 on AOS-8 controllers; check your configuration), SSH or any API exposed beyond your management network. Patch these first, today if you can, and restrict access before the window.
2. Devices that accept PAPI from untrusted segments. Remote APs and branch gateways that talk to controllers across the internet, and Instant AP clusters on flat networks. Restrict UDP 8211 to known peers before the upgrade.
3. Mobility Conductors. A conductor compromise is a compromise of every managed controller's configuration. They are usually few, so do them early in the plan.
4. Controllers and gateways serving guest or untrusted client VLANs. The adjacent-network critical flaws matter most where strangers share the layer 2 network.
5. Everything else on supported trains.
6. End of maintenance and end of support devices. Schedule the train change or the hardware refresh, and in the meantime isolate them as tightly as the operation allows.

What to do now

The commands below are standard AOS-8 and Instant AP CLI and standard Linux tooling. Command names and output columns vary by release, so confirm them against the CLI reference for your exact version before you script anything.

Step 1: build the inventory

You cannot patch what you have not listed. Start with the management systems, then confirm on the devices.

1. AOS-10. Export the device inventory from HPE Networking Central, including gateways and APs, with firmware version, site and group. AOS-10 firmware is set per group or device in Central, so the export doubles as your upgrade plan.

2. AOS-8 with a Mobility Conductor. On the conductor, list managed devices and their versions:

   (conductor) # show switches
   (conductor) # show version
   

   show switches lists each managed controller with its IP, model and running version on most AOS-8 releases.

3. Standalone AOS-8 controllers. On each one:

   (controller) # show version
   (controller) # show image version
   

   show image version shows what is in each boot partition, which tells you whether a fixed image is already staged.

4. Instant AP clusters. On the virtual controller:

   show version
   show aps
   

5. Write it down. For each device: hostname, model, role, release train, running version, fixed target, end of maintenance status, management IPs, owner and change window.

A quick way to flag affected AOS-8 versions from an exported list, assuming a CSV with hostname and version columns:

# versions.csv: hostname,version  (for example: ctrl-hq-1,8.10.0.21)
awk -F, '
function cmp(a,b,  i,x,y,n){n=split(a,x,".");split(b,y,".");
  for(i=1;i<=4;i++){if((x[i]+0)<(y[i]+0))return -1;if((x[i]+0)>(y[i]+0))return 1}return 0}
NR>1{
  v=$2; split(v,p,"."); train=p[1]"."p[2]; fix=""
  if(train=="10.8") fix="10.8.1.2"; else if(train=="10.7"||train=="10.6") fix="10.7.2.7"
  else if(train=="10.4"||train=="10.3") fix="10.4.1.14"; else if(train=="8.13"||train=="8.12") fix="8.13.3.1"
  else if(train=="8.10") fix="8.10.0.24"
  if(fix=="") print $1, v, "UNSUPPORTED TRAIN: plan train change";
  else if(cmp(v,fix)<0) print $1, v, "AFFECTED: upgrade to", fix, "or later";
  else print $1, v, "ok";
}' versions.csv

For 10.6, 10.3 and 8.12, the script compares against the fixed build on the train the CSAF range places them in; reaching it means a train change.

Step 2: check exposure from the outside in

From an authorised scanning host outside your management network, check which management ports answer on your own device addresses. Only scan addresses you own and have permission to test.

# TCP management services commonly used on AOS devices
nmap -Pn -sT -p 22,80,443,4343 -iL aos-mgmt-ips.txt -oA aos-tcp-exposure

# PAPI on UDP 8211 (UDP results are often "open|filtered"; treat any reply as exposure)
sudo nmap -Pn -sU -p 8211 -iL aos-all-ips.txt -oA aos-papi-exposure

HPE's knowledge base notes that UDP scanners can keep reporting 8211 open even after an ACL drops the traffic, because the scanner reads a missing ICMP reply as possibly open. Confirm filtering with your firewall logs or a packet capture, not only with a scan result.

Then check your perimeter. Search your firewall and cloud security group rules for any inbound permit to controller, conductor or gateway addresses on 22, 80, 443, 4343 or UDP 8211 from anything other than your management network and your known AP and remote AP ranges.

Step 3: restrict access before the window

HPE's workaround is the minimum for every device that cannot be upgraded today:

1. Management on its own segment. Put the CLI and web interfaces on a dedicated management VLAN, and permit SSH and HTTPS to it only from jump hosts and network management systems.
2. Layer 3 policy in front. On the upstream firewall or the device's own control plane ACL, deny management protocols from client VLANs, guest VLANs and the internet.
3. PAPI only from expected peers. Permit UDP 8211 to controllers only from the AP subnets and the peer controllers that need it. For Instant AP clusters, Aruba's control plane guidance recommends limiting PAPI to the subnets where other cluster members live, using explicit firewall rules for UDP 8209 and 8211.
4. Control Plane Security on. Make sure CPsec is enabled on AOS-8 controller deployments, so AP to controller PAPI runs inside the IPsec tunnel rather than in the clear. CPsec does not fix these bugs, but it narrows who can send PAPI to the controller in the first place.
5. Accounting on. Turn on command accounting and logging to a central syslog or TACACS+ server so that every administrative action is recorded off the device.

None of this is a fix. It reduces who can reach the vulnerable code until the upgrade lands.

Step 4: upgrade

Follow HPE's upgrade guide for your release and topology; the order matters in conductor-managed and clustered deployments. The general shape on an AOS-8 controller is:

1. Download the fixed image for your model from networkingsupport.hpe.com and check its published checksum.

2. Back up the configuration and flash:

   (controller) # backup flash
   (controller) # copy flash: flashbackup.tar.gz tftp: <backup-server-ip> ctrl-hq-1-pre-8.10.0.24.tar.gz
   

3. Load the image into the non-boot partition, confirm it with show image version, and reload in the window.

4. Upgrade the conductor before managed devices, and use cluster or AP preloading features where your design supports them, to keep APs online.

5. For Instant AP clusters, upgrade the cluster from the virtual controller or from your management platform, so members stay on one version.

6. For AOS-10, set the target firmware per group in Central and schedule it; check compliance after the window.

Step 5: verify

After each upgrade, run show version again and record the result. Then repeat the Step 2 exposure checks: an upgrade can reset an ACL you added in a hurry, and a rollback can bring back an old image. Mark the device fixed only when the running version is at or above the target and the exposure check is clean.

Step 6: look for anything already wrong

With no published indicators, hunting is about change and anomaly rather than signatures. On each AOS-8 device, before and after the upgrade:

(controller) # show mgmt-user
(controller) # show audit-trail
(controller) # show log security 100
(controller) # show log system 100

Look for management users you did not create, configuration changes outside change windows, logins from addresses outside the management network, and unexplained reboots or process restarts. Compare the running configuration against your last known good backup. On your firewall and flow logs, look for inbound connections to management ports and UDP 8211 from unexpected sources in the weeks before the bulletin. If anything looks wrong, treat the device as compromised: preserve logs, rebuild from a known good image and configuration, and rotate every secret the device held, including RADIUS shared secrets, VPN pre-shared keys, SNMP communities and local admin passwords.

What changed since first reports

The bulletin is at revision 1 and has not changed since release. What moved after release:

• CVE.org records appeared about three hours after the bulletin, without descriptions. NVD received them but has not analysed them.
• CISA's enrichment added SSVC data overnight, marking the critical records automatable with total technical impact, and exploitation none.
• The CVE-2026-79845 collision became visible once both records were public.
• First EPSS scores arrived on 23 October at around 0.4 to 0.5 percent for the critical CVEs we checked. EPSS scores for brand new CVEs with no exploit history are usually low and move quickly when exploit code appears; do not use them to defer the upgrade.
• Media coverage settled on "eight max severity" flaws, which matches the bulletin.

What would have helped

Practices any team can use

A network device inventory that knows versions. Most organisations can list their servers and laptops to the patch level. Far fewer can say, in five minutes, which controllers and gateways run which AOS build. A single list with model, train, version, end of maintenance date, management IP and owner turns a 72-CVE bulletin into a schedule instead of a discovery project.

Management interfaces that were never reachable. HPE's workaround is a description of good practice that should already be in place: a dedicated management network, layer 3 policy in front of it, and accounting. Where that was done before the bulletin, the risk from most of the network-vector criticals drops to "someone already inside the management network", which is a much smaller group.

Protocol allow lists, not just port lists. PAPI on UDP 8211 has been the subject of security guidance since at least 2016. Teams that already limited PAPI to known AP and peer subnets, and kept CPsec on, start this week with far fewer reachable devices.

Support status as a tracked risk. The May bulletin gave AOS-8.12 a one-time exception patch; the October bulletin gives it none. Every train has an end of maintenance date. Track it next to the version and start the train change before the next bulletin, not after.

A tested upgrade path. Controller upgrades go faster when the team has done one recently, knows the order for conductors, clusters and APs, and has a lab or a low-risk site to try first. Treat a routine maintenance upgrade every quarter as practice for the critical one.

Logs off the box. Hunting after a bulletin like this depends on audit trails and authentication logs that outlive a reboot or a reimage. Send them to central storage with enough retention to look back several months.

Read the machine-readable advisory. The CSAF file had the full version ranges, including the 8.12, 10.6 and 10.3 folding, on day one. Tools and people that read only the headline list missed that.

Where Safeguard fits

Safeguard does not patch AOS, does not distribute HPE firmware, cannot see inside a controller image, and nothing in it would have prevented these bugs. AOS is HPE's closed-source operating system, delivered as firmware. The fix comes from HPE, and only HPE's images fix it.

What Safeguard does help with is the software around your network estate and the software you build:

• Inventory and matching for what you build and receive. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output) and matches components against vulnerability databases. The platform shows which projects contain a given component and version. If a supplier gives you an SBOM for an appliance or a management tool, you can scan it and track it alongside your own code.
• Your network automation code. Many teams run Python, Ansible or Go tooling that talks to controllers and Central: inventory exporters, config backup jobs, upgrade orchestration. Those tools pull open source dependencies, and Safeguard scans them, ranks findings with reachability analysis and evaluates policies and gates so known vulnerable versions do not ship.
• Work with approval. The Safeguard CLI's assistant can edit code and run commands with your approval, for example writing the version check from Step 1 against your Central export, or running the exposure checks from Step 2 on an authorised scanning host, with each command shown before it runs. Autonomous remediation opens fix pull requests for your own dependencies, and ships switched off by default.

Where Safeguard does not help: it does not read the version of a running controller, it does not detect exploitation on network devices, it does not replace your firewall, network access control or management platform, and it does not tell you whether an HPE upgrade was applied.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems of open source code. AOS is closed-source vendor firmware, outside that scope; HPE found these flaws mostly through its own research and its bug bounty programme.

Gold Open Source at gold.safeguard.sh is free and needs no login; it shows CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version for a CVE, through the site, a free read API and a CI gate GitHub Action. We have not confirmed that it holds records for these 72 CVEs, so check the site rather than relying on this post. Gold Registry at registry.safeguard.sh provides hardened, signed open source components and container images held to zero exploitable critical or high CVEs; it does not distribute AOS firmware and we make no claim about it here. The habit both are built for applies to the code you run around your network: pull patched, signed components from a curated source and rebuild fast.

Common mistakes

Trusting NVD to flag the devices. The records have no NVD analysis and no CPE yet, and one of them points at the wrong product. A scanner that matches on NVD CPE data will under-report. Match on version ranges from the bulletin.

Patching to the headline version on the wrong train. If you run 8.12, 10.6, 10.5 or 10.3, there is no fixed build on your train. Plan the train change.

Assuming "adjacent" means safe. On a wireless controller, the adjacent network can include every client VLAN. Several adjacent flaws are rated 9.6.

Reading "preconditions outside of the attacker's control" as a pass. HPE has not said what they are. Patch regardless.

Closing the change after the conductor. A conductor upgrade does not upgrade every managed controller or AP. Verify each device's running version.

Forgetting remote APs and branch gateways. Devices that talk to controllers across the internet are the ones most likely to have PAPI or management traffic exposed. They are also the easiest to leave off a change plan.

Relying on a UDP scan alone. UDP 8211 can still look open after a filtering ACL. Check firewall logs or capture traffic to confirm.

Leaving the emergency ACL behind forever, undocumented. Write down every temporary rule you add, so the next engineer knows why it is there and whether it is still needed.

Open questions

• What are the "preconditions outside of the attacker's control" for CVE-2026-79844, CVE-2026-79846 and CVE-2026-79891?
• Which record will HPE and the CVE program use for CVE-2026-79845, and will the HPE flaw get a new ID?
• Which score is right for CVE-2026-79881: 8.3, 8.5 or 9.6?
• Will HPE publish a fixed build for AOS-8.12, or for any end of maintenance train, as it did in May?
• Which specific services or daemons do the "affected interface" descriptions refer to? HPE has not said, which is common before customers patch.
• How quickly will public research on PAPI follow? Past PAPI disclosures have attracted outside research, so assume the window between bulletin and public analysis is short.

FAQ

Is CVE-2026-79844 being exploited?

Not as far as anyone has said publicly. HPE says it is not aware of public discussion or exploit code as of release, CISA's SSVC entry records exploitation as "none", and the CVE is not in the KEV catalog we checked. That can change quickly for network edge devices, so check the live KEV catalog and HPE's bulletin page.

How many of the 72 flaws are critical?

Thirty-four by the CSAF file, thirty-three by the signed text, with the difference being CVE-2026-79881. Eight are rated exactly 10.0: CVE-2026-79844 to CVE-2026-79851.

Is it nine or eight maximum severity flaws?

Eight. CVE-2026-79852 is rated 9.8 in the bulletin, the CSAF file and the CVE record.

Which versions fix everything?

AOS-10.8.1.2, 10.7.2.7 and 10.4.1.14, and AOS-8.13.3.1 and 8.10.0.24, or later builds on those trains. All 72 CVEs are fixed by the same builds.

We run AOS-8.12. What now?

The CSAF and CVE records place 8.12 inside the 8.13 affected range, and the bulletin lists no 8.12 fix. Move to 8.13.3.1 or later. Until then, apply the management and PAPI restrictions in Step 3.

Our AOS-10 devices are managed by Central. Does HPE patch them for us?

The bulletin says to upgrade to the fixed versions; it does not say upgrades are applied automatically. Check the firmware compliance view for each group in Central and schedule the upgrade.

Are Instant On access points or AOS-CX switches affected?

Not by this bulletin. It covers AOS-8 and AOS-10 Mobility Conductors, Controllers, Central-managed Gateways, AOS-10 APs and AOS-8 Instant APs. AOS-CX and Instant On have their own bulletins.

Does enabling CPsec fix the PAPI vulnerabilities?

No. CPsec wraps PAPI in an IPsec tunnel between APs and controllers, which limits who can send PAPI to the controller, but the bugs are in the code that processes the messages. Only the fixed builds fix them.

Why does NVD show CVE-2026-79845 as a PHP application flaw?

Because, as of 23 October, the public CVE record with that ID belongs to a different product, published in August by another numbering authority. The HPE bulletin uses the same ID for an AOS-10 PAPI flaw. Track it by the bulletin until the records are corrected.

What should we tell leadership?

That HPE fixed 72 flaws in the wireless platform, eight at the maximum score, with no known exploitation yet; that every affected device needs the same firmware upgrade; that management access has been restricted as an interim measure; and when each site's upgrade is scheduled.

Fix it without waiting for upstream

The AOS upgrade itself has to come from HPE. Everything else you run around the wireless estate, from the automation that exports inventory and stages upgrades to the services that consume controller data, is software you build from open source, and for that part of the estate you do not have to wait.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none of them shows this HPE bulletin, and none of them upgrades AOS firmware. They show how the same approval-based workflow applies to the inventory, exposure checking and automation work around it.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this bulletin, you would open the CLI on your network automation host and ask it to compare your Central and conductor exports against the fixed versions in this post, approving each command and getting a table of devices to upgrade at the end.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick the repository that holds your firewall or network automation templates, ask for a rule that limits UDP 8211 and the management ports to known subnets, and approve each file edit and test run before anything is pushed for review.

Click through it at your own pace, or open it full screen.

The mobile app demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. Controller upgrades usually run in overnight windows; this is how the on-call engineer approves the pre-change backup check and the post-change exposure scan from a phone while the network team works the upgrade.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. For other network edge issues this year, see CVE-2026-73749 in the AOS-CX daemon, the CVE-2026-23813 AOS-CX authentication bypass, edge device zero-days in October 2026 and our October 2026 roundup. For finding affected systems quickly, see using SBOMs to find affected products fast.

Quick check

Sources

• HPE: Security Bulletin HPESBNW05162 rev.1, Multiple Vulnerabilities in HPE Networking Wireless Operating Systems (AOS-10 and AOS-8)
• HPE Networking: HPESBNW05162 signed text advisory
• HPE Networking: HPESBNW05162 CSAF JSON
• HPE Aruba Networking: HPESBNW05048 signed text advisory (May 2026)
• CVE.org: CVE-2026-79844
• CVE.org: CVE-2026-79845
• CVE.org: CVE-2026-79850
• CVE.org: CVE-2026-79881
• NVD: CVE-2026-79844
• NVD: CVE-2026-79845
• CISA Vulnrichment: CVE-2026-79844 record
• CISA: Known Exploited Vulnerabilities catalog (JSON feed)
• FIRST: EPSS API
• FIRST: CVSS v3.1 Specification Document
• Canadian Centre for Cyber Security: HPE security advisory AV26-457
• HPE Support: UDP ports 8900 and 8211 remain open
• Aruba: Control Plane Security Best Practices, PAPI, CPsec and risk mitigation (May 2016)
• BleepingComputer: HPE patches eight max severity RCE and auth bypass AOS flaws
• BleepingComputer: HPE patches critical ArubaOS-CX remote code execution flaw

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.