Wireless infrastructure is often described as a perimeter, but the devices that run it also sit on networks. CVE-2026-79870 makes that distinction important. The flaw is an authentication bypass in the AOS-8 PAPI protocol, and HPE describes exploitation by an unauthenticated adjacent attacker. The attacker does not need a valid account or user interaction, but must be able to reach the relevant network path.
Vulnerability overview
HPE published the issue in advisory HPESBNW05162. The CVE record assigns CWE-287 and a CVSS 3.1 score of 9.6. The vector is CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. It represents low attack complexity, no required privileges, no user interaction and a scope change.
AOS-8 versions 8.10.0.0 through 8.10.0.23 and 8.13.0.0 through 8.13.3.0 are affected. HPE lists fixes at 8.10.0.24 and 8.13.3.1 or later in the respective branch.
Mechanism and exploitation conditions
PAPI carries management traffic between access points and controllers. CVE-2026-79870 lets an unauthenticated user on an adjacent network circumvent the protocol's authentication checks. HPE states that successful exploitation can provide administrative access. The advisory does not disclose the packet structure or the exact coding error.
For operations teams, adjacency is the condition that deserves careful mapping. A guest wireless network, a branch user VLAN, a contractor endpoint or a compromised server may have a path that the security team does not think of as a management network. The flaw does not require internet exposure to matter. It requires a route from an attacker-controlled system to the affected PAPI service.
Impact
The immediate asset is the wireless control plane. An attacker with administrative access may change configurations, access or manipulate sensitive data, and disrupt network operations. Controllers and gateways can affect multiple access points, so a small configuration change can have a broad operational result.
The CVSS vector gives high confidentiality, integrity and availability impact. That combination supports urgent patching even though HPE reported no known public exploit code at release. The lack of a public exploit does not remove the value of a management-plane breach, particularly in networks where wireless access supports business or safety functions.
Affected products and scope
The vendor advisory covers multiple AOS-8 and AOS-10 products, but CVE-2026-79870 is specific to the AOS-8 PAPI protocol. Inventory should capture the exact AOS branch and build for controllers, gateways and access points. It should also record whether devices are managed locally or through a central platform and which networks can initiate PAPI sessions.
Review the placement of management interfaces. A device can be correctly patched and still have an unnecessarily broad management path. Conversely, a product fingerprint does not establish the software version. Both the asset record and the network path need evidence.
Exposure context
The selected ZoomEye Search, app="ArubaOS", returned 210 product-fingerprint matches. The CVE Filter vul.cve="CVE-2026-79870" returned 0. Exposure is 210 because the Search count is larger.
This is a broad ArubaOS product observation. It does not show which devices run AOS-8, whether PAPI is enabled, or whether any matched system is vulnerable. It is more useful as a reminder that ArubaOS devices are externally observable than as a count of confirmed victims.
Remediation and mitigations
Upgrade to the appropriate fixed AOS-8 release. HPE also recommends restricting CLI and web-based management interfaces to a dedicated VLAN or Layer 2 segment, with firewall controls at Layer 3 and above. Extend that control model to PAPI and document any required exceptions.
Test access-point onboarding, controller failover and centralized management before completing a fleet-wide change. After the patch, compare running configuration with a trusted baseline and review administrative activity for unexplained changes. If a management path cannot be closed immediately, isolate it with network policy and monitor it more closely.
The response should answer three operational questions: which AOS-8 devices can be reached from an untrusted adjacent network, which PAPI dependencies justify that reachability, and what evidence proves the correct release is running now.