Upgrading an AOS-10 device is the central step for CVE-2026-79871, but it is not the only evidence a completed response needs. The validation record should show the running fixed image, the reachable management paths and the logging available for investigation.
Confirm the software state
HPE maps the affected ranges to these releases:
10.8.0.0 through 10.8.1.1 requires 10.8.1.2 or later
10.7.0.0 through 10.7.2.6 requires 10.7.2.7 or later
10.4.0.0 through 10.4.1.13 requires 10.4.1.14 or later
After the reboot, read the active image from the device and compare it with the approved target. Confirm the model, role and branch. An uploaded package, a successful file transfer or a controller view that is not refreshed is weaker evidence than the running system state.
Record the device identifier, previous image, fixed image, verification time and verifier. If a device rolls back or fails to boot, keep it in the restricted management segment and mark it unresolved. Do not let a successful neighbor stand in for its status.
Recheck the management path
HPE describes CVE-2026-79871 as an unauthenticated information disclosure in the AOS-10 CLI. The CVSS vector uses adjacent-network access. A fixed image should be paired with a review of every path to the CLI and web management interface.
The vendor recommends a dedicated layer 2 segment or VLAN, layer 3 firewall policy and accounting controls. Verify that the intended management hosts can reach the device and that general user, guest and remote-support paths cannot. Check IPv4 and IPv6, alternate interfaces and any temporary rule created during the response.
A firewall policy is only verified when its effective behavior is observed from the relevant zones. A configuration export can support the review, but it should not be the only evidence.
Validate logging and ownership
HPE recommends accounting controls for tracking and logging user activity and resource use. Confirm that the device sends the expected records and that the collection pipeline receives them with accurate time.
Identify the owner for administrator accounts, automation and support access. Confirm who can approve a management-path exception and when it expires. This matters when a device remains on an interim restriction after the fixed image is installed or when a new integration requests CLI access.
Review administrative activity around the maintenance window. Expected source addresses, session times and change records should match. An unexpected connection is not proof that CVE-2026-79871 was used, but it is a reason to correlate device, firewall and downstream authentication data.
Use Exposure evidence as a lead
ZoomEye Search app="ArubaOS" returned 212 product matches and vul.cve="CVE-2026-79871" returned 0. Exposure is 212 for the selected product query, not a count of confirmed vulnerable devices. The result can help find ArubaOS assets that require authorized ownership and version checks.
Search: https://www.zoomeye.ai/searchResult?q=YXBwPSJBcnViYU9TIg%3D%3D
After remediation, a product match still cannot prove the installed branch. Use internal inventory and device evidence for the completion decision, and label any public result by its actual scope.
Close the fleet-level gap
Compare the pre-upgrade inventory with the post-upgrade list. Account for every device in the affected branches, every exception and every failed application. Confirm that the fixed releases are active and that management restrictions remain where needed.
Keep the evidence with the vulnerability record rather than only in a maintenance ticket. A later audit should be able to answer four questions: which image is running, who can reach the CLI, what activity was recorded and who owns any remaining exception.