CVE-2026-79895 exposes a common inventory problem. A vendor can publish fixed HPE Networking ArubaOS releases, but an organization still needs to know which wireless controllers, gateways and access points sit on the affected AOS-10 branches and who is responsible for upgrading them.
The disclosed issue
HPE advisory HPESBNW05162 describes unauthenticated remote denial-of-service vulnerabilities in an affected AOS-10 interface. Successful exploitation can disrupt availability of that interface. HPE assigns CVSS 3.1 7.5 High with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. CISA's enrichment classifies the weakness as CWE-400, uncontrolled resource consumption.
The advisory covers AOS 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. Fixed versions are 10.8.1.2, 10.7.2.7 and 10.4.1.14. HPE does not identify the vulnerable interface in the public advisory and reported no public exploit code at release.
Make the asset record version-aware
A platform inventory often records the manufacturer, model and site. Those fields are not enough for vulnerability response. Add the installed release, product role, management path, support owner and maintenance group. Keep the source and timestamp for each field so the team knows whether a value came from a recent device report, an old spreadsheet or a deployment system.
Use unique device identity where possible. A hostname can change after a replacement, and a site label can cover a controller cluster with several members. Serial numbers, cloud asset IDs or vendor management identifiers provide a better link to the configuration history.
Record end-of-maintenance and end-of-support status as lifecycle fields. A fixed release is only useful if the device platform remains supported and the organization can obtain the image. HPE's advisory says products and versions not specifically listed are not affected, but that statement does not turn an unsupported release into a security baseline. Verify the official support position before treating an old branch as out of scope.
Connect detection to ownership
Create one process that lets either an external observation or an internal scan open an asset-review task. ZoomEye returned 210 product-fingerprint matches for app="ArubaOS" and zero matches for vul.cve="CVE-2026-79895". The first number indicates a broad product footprint, not confirmed vulnerable devices. The second does not prove that no affected device exists.
An external hit should lead to an owner lookup and a version check. If nobody claims the device, treat that as an inventory failure. If the owner has no upgrade window, record the exception and the risk decision. The security team should not count an unresolved owner as covered simply because a public query returned no CVE match.
Build a patch baseline
For this CVE, the patch baseline is simple: use 10.8.1.2, 10.7.2.7 or 10.4.1.14 as the minimum fixed release for the applicable branch. Add the vendor advisory date, risk decision and proof of installation to the change record.
HPE recommends restricting the command-line and web management interfaces to a dedicated Layer 2 segment or VLAN and controlling access with firewall policy at Layer 3 and above. Track that restriction as a configuration control with an owner and review date. A temporary firewall exception should have a removal path from the day it is created.
Feed the next cycle
After the upgrade, verify service health and confirm that the device still appears in future version reports. A successful one-time patch should improve the next response: the asset record is current, the owner is known and the management path is documented.
Review the lesson that this advisory makes visible. A generic product query cannot replace a version-aware inventory, and a vendor fix does not repair an overbroad management network. The longer-term control is a maintained record that connects device role, software release, reachability and accountable owner.