A patch ticket can close when a package installs. A vulnerability remediation record should close only when the organization can show that affected AOS-8 systems run a fixed release and that adjacent untrusted networks cannot reach their management functions. CVE-2026-79868 needs both kinds of evidence because HPE describes an authentication bypass with administrative impact.
The risk being closed
HPE advisory HPESBNW05162 describes authentication bypasses in an affected AOS-8 interface. An unauthenticated adjacent attacker can gain administrative access, modify configurations and access or manipulate sensitive data, leading to complete system compromise. The CVSS 3.1 score is 9.6 with CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
The exact vulnerable interface is not public. That makes a narrow exploitation retest difficult to justify. The stronger verification path is to establish the fixed release, confirm device roles and reduce all unnecessary management reachability. HPE recommends dedicated layer 2 isolation, layer 3 and above firewall policy and accounting controls.
First evidence set: software state
Affected AOS-8 versions are 8.13.0.0 through 8.13.3.0 and 8.10.0.0 through 8.10.0.23. Fixed releases are 8.13.3.1 and 8.10.0.24 or later. Record the running version from each device and from the central management system. Compare serial numbers and roles so a stale console entry does not hide a device or make an upgraded device appear twice.
Check standby controllers, gateway peers and managed access points. An access point may depend on a controller whose software contains the flaw. A high-availability pair may not be fully upgraded at the same time. Rollback images should not restore an affected build without a new risk decision.
Second evidence set: network state
List all management addresses and the source networks permitted to reach CLI and web management interfaces. Confirm the intended administrative path and remove rules that expose management services to guest, user, partner or other adjacent networks without a business need. Keep the firewall evidence associated with the device record.
HPE's workaround is a control while patching, but it is also useful assurance after patching. A fixed device with broad adjacent management access has less defense in depth if another management vulnerability appears. A time-bound exception should identify the source group, reason, compensating control, owner and review date.
Third evidence set: activity review
Preserve authentication records, administrative sessions, configuration changes and accounting data covering the period before the fix. Review for unexpected administrative access, new accounts, policy changes or management sessions from adjacent sources. These records do not prove exploitation by themselves, but they can reveal outcomes that conflict with a clean remediation story.
HPE recommends accounting controls for user activity and resource usage. Teams should verify that logs are enabled, retained and available to the people who investigate alerts. A log configuration that exists but is never collected is not useful evidence.
Exposure context
ZoomEye returned 212 matches for app="ArubaOS". A CVE-specific Filter returned 0. The first result is a product-fingerprint count and does not report confirmed vulnerable assets. The second result does not prove that the organization's internal estate is clean. Use the evidence to contextualize the broader installed base, then rely on asset inventory, version checks, reachability review and internal telemetry for the closeout.
Completion checklist
The remediation record should answer these questions:
Which AOS-8 devices used an affected release?
Which fixed release is running now on each device and peer?
Which adjacent networks can reach management interfaces?
Which firewall, VLAN and accounting controls support the claimed boundary?
Were unusual sessions or configuration changes found before the fix?
Which unsupported or temporarily excepted devices remain?
Who owns each exception and when will it be reviewed?
HPE reported no known public exploit code at the advisory's release. That statement affects the immediate exploitation outlook, not the severity of the flaw or the need for proof. A strong closeout shows the old vulnerable state is gone, the management plane is constrained and the evidence is available for later review.