CVE-2026-79873 is a critical authentication bypass in the PAPI protocol of HPE AOS-10. The vendor says an unauthenticated adjacent attacker can obtain administrative access, change configuration, and access or manipulate sensitive data. This runbook turns the advisory into a sequence that operations, network security, and incident response teams can execute without inventing the undisclosed exploit details.
1. Freeze the scope
Collect the AOS-10 asset list from controllers, gateways, access points, and the central management platform. Record the running software version, role, site, management address, owner, and current reachability. Include recently replaced or retired assets that may still be active.
Use the CVE's intended affected ranges: 10.8.0.0 through 10.8.1.1, 10.7.0.0 through 10.7.2.6, and 10.4.0.0 through 10.4.1.13. The vendor has not published the exact vulnerable PAPI request or code path, so scope the work by product, release, and management path rather than by a guessed signature.
2. Rank by reachability and role
Find the systems that an adjacent client, guest, branch, partner, or shared internal network can reach. Then consider the device role. A controller or gateway that affects a large wireless estate usually carries more immediate operational risk than a narrowly used access point.
HPE recommends restricting CLI and web management interfaces to a dedicated layer 2 segment or VLAN and controlling layer 3 access with firewall policy. Apply and verify those controls while the maintenance window is pending. Enable accounting so management activity and configuration changes can be reviewed.
Do not treat a temporary rule as proof that the device is fixed. Record its scope, owner, exceptions, and removal date.
3. Prepare the maintenance
Choose the fixed release for the branch: 10.8.1.2, 10.7.2.7, or 10.4.1.14, or a later approved release. Confirm image compatibility, access-point requirements, gateway dependencies, rollback steps, and a method to verify the running version after boot.
Capture the current configuration and relevant logs before changing the device. If misuse is suspected, coordinate with incident response before restoring a backup or overwriting settings that may be evidence.
4. Upgrade and verify
Apply the approved image. After the system returns, obtain the version from a trusted local or management path. Compare it with the intended release and store the evidence in the asset record.
Test the services that matter: controller membership, gateway traffic, access-point adoption, authentication, policy enforcement, management access, time synchronization, and logging. Confirm that the device appears correctly in the management platform.
5. Review integrity
Compare security-relevant configuration with the approved baseline. Review administrative accounts, management rules, authentication settings, logging destinations, forwarding, trust relationships, and access policy. Resolve differences through the change process or incident process as appropriate.
HPE describes administrative access and sensitive-data manipulation as possible outcomes. Those claims justify a careful review of administrative actions and configuration changes. They do not prove that every affected device was compromised, and the advisory does not state that credentials were exposed.
6. Preserve and interpret evidence
Keep the exact ZoomEye dorks, subtype, timestamps, result IDs, counts, and status. The selected Search app="ArubaOS" returned 212 product-fingerprint matches. The Filter vul.cve="CVE-2026-79873" returned 0. Exposure is 212 under the larger-successful-count rule, but this is not 212 confirmed vulnerable devices and the zero filter is not proof of safety.
HPE reported no known public exploit code at the advisory release. That statement belongs in the record with its date and source. It should not be rewritten as proof that no attacker used the flaw.
7. Close the item
Mark an asset complete only when the observed running release is fixed, the operational checks pass, and the configuration review has an accountable result. Record any unresolved evidence gap. Remove temporary network restrictions after approval, or document why they remain.
A final report should show the affected count, fixed count, isolated count, unsupported count, failed upgrades, and any incident referrals. It should also distinguish internal version evidence from external ZoomEye measurements. That separation gives management a clear view of what was remediated and what was only estimated.