CVE-2026-79861: Building Patch Assurance for ArubaOS AOS-10
Assurance starts with precise facts
CVE-2026-79861 is an unauthenticated command-injection flaw in the AOS-10 PAPI protocol. A crafted packet can execute arbitrary commands as a privileged user, producing high confidentiality, integrity and availability impact. CVSS 3.1 is 9.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and the CWE mapping is CWE-77.
The affected ranges are 10.4.0.0 through 10.4.1.13, 10.7.0.0 through 10.7.2.6 and 10.8.0.0 through 10.8.1.1. The fixed releases are 10.4.1.14, 10.7.2.7 and 10.8.1.2. A patch assurance program should treat those as evidence targets, not as a vague instruction to update ArubaOS.
Define the control objective
The control objective has two parts. First, every affected AOS-10 node must run a fixed build on a supported branch. Second, the management plane must remain reachable only from approved networks. A device can pass the first check and fail the second. A device can also appear in a current inventory while running an old image because the inventory record was not refreshed.
HPE recommends restricting CLI and web management interfaces to a dedicated layer 2 segment or VLAN and controlling them with firewall policy. The recommendation matters because the vulnerability is in a management protocol and requires a reachable packet path. Patch assurance should therefore collect both software and network evidence.
Build the evidence set
For each node, record the device role, hardware or virtual platform, current branch, active image, management address and responsible team. The role matters because HPE lists Mobility Conductors, Mobility Controllers, Mobility Gateways managed by HPE Networking Central and AOS-10 access points in the advisory scope.
Capture the exact version after boot rather than relying on an upgrade ticket. Record whether the node is part of a cluster and which access points depend on it. Capture the management-zone rule that applies to the node and the last review date for that rule. A screenshot of a version command has limited value if it is not tied to an asset identity and a collection time.
Test the exception process
An exception should name the device, the affected branch, the reason the fixed release cannot be installed, the management exposure and the compensating control. HPE's interim guidance is network isolation, so an exception that leaves PAPI reachable from untrusted networks should have a clear escalation path.
Exceptions should expire. A temporary exception that stays open through several review cycles becomes a hidden permanent risk. The reviewer should ask whether the device can be removed from service, moved to an isolated segment or upgraded through a tested maintenance path.
Measure completion
Useful metrics include the number of affected nodes by branch, the number running the fixed release, the number with an approved exception and the number reachable from an untrusted management path. Report access point and controller results separately where the architecture requires it. A single percentage can hide a small but critical controller group.
The ZoomEye Search app="ArubaOS" returned 210 product matches and the CVE Filter returned 0. Exposure is 210, but the search measures product fingerprints and does not prove patch state. It is a useful external indicator for research, not a substitute for the evidence set above.
HPE reported no public exploit code or active exploitation at advisory release. That fact should appear in the risk discussion, while the control decision remains tied to the unauthenticated privileged execution path. A defensible assurance report says what was checked, what was found, what remains unverified and which owner is closing each gap.
