CVE-2026-79861 is an unauthenticated command-injection vulnerability in AOS-10, HPE Aruba Networking’s operating system for access points and gateways. A crafted packet sent through PAPI, Aruba’s access-point management protocol, can cause the device to run attacker-controlled commands as a privileged user on its underlying operating system. In other words, this is remote code execution on the network appliance itself, without an account or a user click.
That makes the affected role important. AOS-10 runs enterprise connectivity: campus and branch Wi-Fi, wired access, VPN, SD-WAN and remote-worker deployments, often administered with Aruba Central. The broader bulletin covers Mobility Conductors, Mobility Controllers, Central-managed Mobility Gateways and AOS-10 access points. Organisations with distributed offices, campuses, retail branches, schools, healthcare sites and other fleets of managed network gear should treat their appliance inventory as the first question, not assume this only concerns a controller in a data centre.
Crafted management traffic becomes privileged execution
PAPI is how Aruba infrastructure manages access points. The vendor says specially crafted PAPI packets can trigger command injection, but it does not identify the daemon, packet field, command handler, or destination port involved. That distinction matters: other PAPI issues in the same bulletin mention UDP 8211, but that port is not confirmed for CVE-2026-79861. Defenders should not turn a useful lead into a presumed exposure boundary.
The attacker needs network reachability to the vulnerable PAPI service, but no authentication is required once they have it. A successful request gives arbitrary code execution with privileged OS-level rights, which can enable configuration theft or alteration, persistence, traffic interception, and a foothold from which to move through the environment. The advisory is not a source-level disclosure: HPE provides firmware remediation and vulnerability details, not a patch diff or vulnerable code pattern.
Upgrade supported branches, isolate everything else
Patches are available for supported AOS-10 lines. Affected 10.8 releases from 10.8.0.0 through 10.8.1.1 should move to 10.8.1.2 or later; 10.7.0.0 through 10.7.2.6 should move to 10.7.2.7 or later; and 10.4.0.0 through 10.4.1.13 should move to 10.4.1.14 or later. Test the firmware rollout against controller, gateway and AP dependencies, but prioritise devices exposed across untrusted internal segments or reachable from remote sites.
For systems that cannot move immediately, HPE’s advisory-level mitigation is to put CLI and web management interfaces on a dedicated Layer 2 segment or VLAN, or apply Layer 3-or-higher firewall policy; it also recommends accounting controls for activity and resource-use logging. The bulletin does not offer a PAPI-specific workaround, so network segmentation is containment, not a substitute for upgrading. End-of-Maintenance versions are presumed affected unless excluded, while End-of-Support deployments have not been assessed; move both to a supported release.
No confirmed exploitation or usable public exploit
As of October 28, 2026, no in-the-wild exploitation, victim incident, campaign, indicator of compromise, or public proof of concept could be confirmed. HPE said at disclosure it knew of no public discussion or exploit code, a narrower statement than proving nobody has used it. Conflicting aggregator labels calling a PoC public do not point to an actual CVE-specific exploit and remain unverified. The vulnerability is also absent from CISA’s KEV catalogue.
This arrives in a much wider HPE release covering many ArubaOS issues, including CVE-2026-79848, CVE-2026-79851 and CVE-2026-79859. Patch the fleet rather than narrowly chasing one packet path. In practice, inventory every AOS-10 appliance, restrict management-plane reachability now, and use SecAlerts to monitor the software stack an organisation actually runs and alert on new vulnerabilities affecting it.
