Why end-of-maintenance AOS-8 systems belong in this CVE review
How end-of-maintenance AOS-8 systems change the CVE-2026-79858 inventory and migration decision.
VE-2026-79858 does not stop being a risk because an AOS-8 deployment is old. HPE's advisory explicitly says that products which have reached end of maintenance are presumed affected by the listed vulnerabilities unless the vendor states otherwise. Those versions are not covered by the fixed releases for the supported branches.
That sentence changes the inventory question. A search for 8.10 and 8.13 devices with supported fixes may miss the systems that need the most attention: wireless infrastructure that still carries traffic but no longer receives security updates.
Read the vendor boundary carefully
HPESBNW05162 lists affected AOS-8.13 versions through 8.13.3.0 and AOS-8.10 versions through 8.10.0.23. The corresponding fixed releases are 8.13.3.1 and 8.10.0.24. For products past end of maintenance, HPE says exposure has not been assessed and the installations should be considered potentially impacted.
This is not a claim that every unsupported device is actively exploited. It is a software-support boundary. The vendor is saying that the normal advisory scope and fixes do not cover that state. An organization that keeps the device must make a separate risk decision and plan a supported migration.
Find the devices that are absent from normal dashboards
Legacy wireless systems can survive outside the central asset inventory for practical reasons. A branch may maintain a local controller, a laboratory group may keep an older access-point fleet, or a managed-service contract may leave security ownership unclear. These are exactly the systems that a clean report can omit.
Reconcile procurement records, network discovery, DNS and DHCP data, management-platform inventories, support contracts, and firewall flow logs. Confirm the running software version. Record the deployment owner and the business service that depends on the device.
Use ZoomEye as a supporting discovery source when appropriate. The review recorded 211 ArubaOS product-fingerprint matches for app="ArubaOS" and zero CVE-filter matches. These are not confirmed vulnerable systems. They are evidence that public product fingerprints exist and that asset identity still needs internal validation.
Separate quarantine from migration
A temporary network restriction can reduce exposure while a legacy device is moved or replaced. HPE recommends dedicated Layer 2 segmentation or VLANs for command-line and web management interfaces, Layer 3 and higher firewall policy, and accounting controls. Apply those controls where they fit the architecture and verify that they cover the relevant PAPI path in that environment.
Quarantine is not a permanent lifecycle answer. If a device cannot receive a fixed release, the organization should define a supported replacement path, a removal date, and the interim risk owner. Keep the migration work visible rather than treating an isolated legacy device as a closed exception.
Make the support decision explicit
For each unsupported system, answer these questions in the risk record:
- Is the device still in production service or only in a laboratory or standby role?
- Who owns the service and the security exception?
- Which network sources can reach its management interfaces and PAPI path?
- What replacement or supported upgrade path has been approved?
- What compensating controls are in place, and how are they verified?
- When will the device be removed, migrated, or re-evaluated?
An answer of unknown should become a task with an owner and date. It should not become a permanent status.
Avoid two common errors
The first error is to exclude an asset because it is too old to appear in the vendor's fixed-version table. HPE has already told readers how to treat end-of-maintenance products. Excluding them creates blind spots.
The second error is to label every unsupported device as compromised. The advisory describes a vulnerability and a support boundary. It does not provide evidence of exploitation on a particular network. The correct label is potentially affected and in need of a supported migration or documented compensating decision.
A defensible closure criterion
Do not close the legacy inventory review when a network quarantine is enabled. Close it when the asset is running a supported fixed release, has been replaced, has been removed from service, or has a formally accepted risk with an owner and a date. Verify any compensating control against the actual management path rather than assuming that a general firewall policy covers PAPI.
CVE-2026-79858 is a prompt to look beyond the tidy list of patchable systems. The old controller in the branch closet and the forgotten access-point cluster may be the least visible part of the problem. Their absence from the vendor fix map should trigger a migration decision, not an exemption.
References
Did you enjoy this article?
Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.