CVE-2026-79857 is a command-injection bug in the PAPI protocol of ArubaOS 8 (AOS-8), HPE Aruba Networking’s software for wireless controllers, virtual controllers, Mobility Conductors and controller-managed access points. PAPI is not a user-facing Wi-Fi feature: it is part of the management plumbing that lets access points and controllers exchange configuration and radio-control information.
The dangerous part is the lack of an authentication requirement. An attacker who can send specially crafted packets to the affected UDP service can cause arbitrary commands to run as a privileged user on the underlying operating system. In practical terms, this is remote code execution on infrastructure that administers wireless access points, without first obtaining a controller login or persuading an administrator to do anything.
PAPI turns packet handling into privileged execution
The advisory does not identify the vulnerable PAPI message type, packet field, parser, or command-construction path. It also does not publish a source patch or a PAPI-specific workaround. Documentation identifies UDP 8211 as the PAPI port used between access points and controllers, but the CVE advisory itself describes only an “affected UDP port”; teams should avoid treating that broader protocol detail as proof that every UDP 8211 exposure is exploitable.
This matters most where management-plane traffic is reachable beyond the intended wireless infrastructure segment. Aruba controller deployments are common in centrally managed campus and branch networks, including large estates coordinated through Mobility Conductors. That puts enterprises, schools, healthcare providers, retailers and other organisations with controller-managed Aruba wireless in the likely exposure pool—not because a sector is uniquely targeted, but because they often operate this architecture.
Fixed trains are narrow, unsupported systems need attention
HPE’s advisory lists AOS-8 8.13.0.0 through 8.13.3.0 and 8.10.0.0 through 8.10.0.23 as affected. Update the 8.13 branch to 8.13.3.1 or later, or the 8.10 branch to 8.10.0.24 or later. The available material does not establish an in-place fix for other AOS-8 trains.
End-of-Maintenance releases are presumed affected, while versions beyond End of Support were not assessed and should be treated as potentially affected until moved to a supported release. Until patching is complete, restrict CLI and web management access to a dedicated Layer 2 segment or VLAN, or enforce Layer 3 firewall policy, and review activity and resource-use logs. Those are interim controls, not a documented fix for PAPI itself.
The issue appears amid a wider AOS-8 and AOS-10 release, with related entries including CVE-2026-79847, CVE-2026-79849 and CVE-2026-79856. That makes a full inventory and upgrade review more useful than handling this CVE in isolation.
No confirmed attacks, but exposure is enough
As of October 27, 2026, no exploitation in the wild, incident, campaign, public proof of concept, or exploit code had been confirmed. HPE said it knew of no public discussion or exploit code at release, and CVE-2026-79857 is not in CISA’s Known Exploited Vulnerabilities catalogue. Those are useful status signals, not a reason to leave an unauthenticated management protocol exposed.
Start by locating controllers, virtual controllers and managed AP estates on the affected trains, then constrain their management reachability and schedule firmware updates. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which can help keep this kind of appliance exposure from getting lost between network and security teams.
