Upgrading an AOS-8 device is the central response to CVE-2026-79855, but the maintenance event is not the whole assurance process. Administrators need evidence that the fixed image is running, the management path is controlled and the recovered configuration preserves the intended security state.
HPE describes the issue as an authentication bypass in the SSH daemon of AOS-8. An unauthenticated remote attacker can gain administrative privileges and completely compromise the host.
Confirm the intended fixed release
The affected ranges are 8.13.0.0 through 8.13.3.0 and 8.10.0.0 through 8.10.0.23. The fixed releases are 8.13.3.1 and 8.10.0.24.
Record the installed branch before maintenance and the running branch afterward. A maintenance ticket that says "upgraded" is weaker than an image version captured from the device or inventory system.
If the device uses a different supported branch, obtain the applicable vendor guidance before claiming the CVE is fixed.
Validate the management boundary
HPE recommends placing CLI and web management interfaces in a dedicated layer 2 segment or VLAN and enforcing firewall policy at layer 3 and above. It also recommends accounting controls for tracking and logging user activity and resource use.
After the upgrade, verify that SSH management is reachable only from approved sources. Check the actual routing and firewall path rather than relying on an intended architecture diagram.
Include temporary support links and automation accounts in the review. A fixed software version with an unintentionally broad management path still leaves a critical service more exposed than necessary.
Review the restored configuration
Configuration backup and restore can reintroduce old access rules, local accounts or monitoring paths. Compare the post-upgrade configuration with the approved baseline.
Confirm that administrative accounts, access policies and logging settings remain in the expected state. Record any intentional exception and its expiry.
Check for evidence of prior access
The vendor says it was not aware of public discussion or exploit code when the advisory was released. It does not state that no exploitation has occurred anywhere.
Review administrative authentication, configuration changes and availability events around the exposure window. If the platform supports accounting records, preserve them before rotation or rebuild. Escalate unexplained privileged activity.
Reconcile the inventory
Update each affected asset with:
the fixed image version
the validation time
the owner
the SSH management path
any remaining exception
the next review date
Systems that cannot be upgraded need a documented containment and lifecycle decision. The advisory treats end-of-maintenance systems as presumed affected and says exposure for software past end of support has not been assessed.
Use external evidence proportionally
ZoomEye reports 212 ArubaOS product fingerprint matches and zero selected CVE filter matches. Those values can support an inventory review, but they do not validate a specific device's patch state.
The closure condition should be the fixed software plus an approved management boundary plus retained evidence. An external product count should not replace that work.
HPE published a clear fixed release and a practical interim workaround. A disciplined post-patch record makes both visible and auditable.