CVE-2026-79856 tests whether an organization can connect a wireless asset to its owner, exact AOS-8 branch, management reachability and patch record. The response fails operationally when a controller, gateway or access point has no reliable version or no accountable team.
Vulnerability overview
CVE-2026-79856 is a buffer overflow in the PAPI protocol of HPE Networking ArubaOS (AOS-8). HPE rates it 9.8 Critical under CVSS 3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The assessment records no required privileges and no user interaction, while confidentiality, integrity and availability impact are all high. HPE published the defect in advisory HPESBNW05162 on October 22, 2026.
Mechanism and exploitation conditions
HPE describes a buffer overflow in PAPI, Aruba's access point management protocol. The overflow can let an unauthenticated remote attacker circumvent existing authentication controls. Successful exploitation can provide administrative access, allow changes to system configuration and permit access to or manipulation of sensitive data. The advisory does not provide a packet layout, the exact packet-processing function or a public proof of concept. Defenders should preserve that technical limit and avoid claiming that a port scan alone proves exploitability.
Impact
The immediate security concern is control of the AOS-8 management plane. An attacker who crosses the authentication boundary could change how the wireless infrastructure enforces policy, trusts clients or exposes operational data. Configuration changes can outlive the initial intrusion and affect connected systems. The CVSS vector also scores high availability impact, so disruption is a plausible outcome. These are possible consequences of successful exploitation; HPE's release advisory does not confirm that any customer was attacked.
Affected products and scope
HPE assigns CVE-2026-79856 to the AOS-8 branches 8.13.0.0 through 8.13.3.0 and 8.10.0.0 through 8.10.0.23. The fixed releases are 8.13.3.1 and 8.10.0.24 or later versions in the applicable supported branch. HPE's advisory covers Mobility Conductors, Mobility Controllers, Mobility Gateways and AOS-8 Instant Access Points. AOS-10 is outside this CVE's listed affected product scope.
Keep inventory identifiers consistent across teams
A ZoomEye product fingerprint can show that an ArubaOS asset exists. It cannot establish whether the device runs AOS-8 or AOS-10, which branch it uses or whether its build falls inside the affected range. Those questions require device or management-platform data. The inventory should preserve that distinction so a broad exposure count is not presented as a vulnerable asset count.
Use the same asset identifier in inventory, patch planning, firewall review and incident response. Include the technical owner, escalation path, management network and last verified release. A record refreshed only during an annual audit cannot support a decision across two AOS-8 branches and two fixed releases.
Exposure context
ZoomEye provides inventory context, not a vulnerability verdict. A successful Search for app="ArubaOS" returned 210 product-fingerprint matches. The selected Filter vul.cve="CVE-2026-79856" returned 0. Exposure is the larger selected count, 210, and is not a sum. The Search can include ArubaOS systems on unaffected branches or versions, and the zero Filter result does not prove that no vulnerable device exists.
Remediation and mitigations
HPE directs customers to upgrade AOS-8 8.13.x deployments to 8.13.3.1 or later and AOS-8 8.10.x deployments to 8.10.0.24 or later. Until the update is applied, HPE recommends restricting the CLI and web-based management interfaces to a dedicated Layer 2 segment or VLAN and controlling access with firewall policy at Layer 3 and above. HPE also recommends accounting controls for tracking and logging user activity and resource use. The vendor reported no known public discussion or exploit code as of the advisory release date.
Measure the gaps after the patch
Report devices with confirmed release, complete ownership and documented management paths separately from devices with missing data. Give every exception an owner and deadline. Review whether the branch mapping was easy to apply and whether post-change verification worked at fleet scale. The result should be a repeatable evidence trail that can support the next network advisory.