Avoiding Partial ArubaOS Branch Upgrades for CVE-2026-79872
Avoiding Partial ArubaOS Branch Upgrades for CVE-2026-79872 CVE-2026-79872 has affected ranges across five ArubaOS release families. Each family has a different minimum fixed release. A generic instruction to install t
Avoiding Partial ArubaOS Branch Upgrades for CVE-2026-79872
CVE-2026-79872 has affected ranges across five ArubaOS release families. Each family has a different minimum fixed release. A generic instruction to install the latest image is not a finished remediation plan because devices can remain on an old branch, a standby node can be missed, or an access point can be left outside the upgrade scope.
The vulnerability is a buffer overflow in the underlying operating system of AOS. HPE describes it as remotely reachable without authentication and capable of leading to privileged code execution. The CVSS 3.1 base score is 9.4 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L.
The five branch targets
Use the branch already deployed on the device when choosing the minimum fixed build:
- AOS-10.8.x: 10.8.1.2 or later on the supported branch
- AOS-10.7.x: 10.7.2.7 or later on the supported branch
- AOS-10.4.x: 10.4.1.14 or later on the supported branch
- AOS-8.13.x: 8.13.3.1 or later on the supported branch
- AOS-8.10.x: 8.10.0.24 or later on the supported branch
A device on one of these branches is not fixed because a different device in the same estate has the corresponding release. The release must be evidenced on the affected host.
What creates a partial upgrade
A controller cluster can report an overall status while individual members are still rebooting or running a different image. Gateways managed through HPE Networking Central may follow a separate procedure. Access points can be updated by a controller but may fail and continue running an older image. Standby and disaster-recovery systems are easy to omit when the inventory focuses on active traffic.
The affected product scope includes Mobility Conductors, Mobility Controllers, Mobility Gateways managed by HPE Networking Central, AOS-10 Access Points, and AOS-8 Instant Access Points. Treat each role as a separate completion unit.
Verify before and after
Before maintenance, record the device model, role, branch, exact build, management address, owner, and support status. Identify whether the intended image is vendor-supported for that hardware and whether the deployment is part of a cluster or managed fleet.
After maintenance, verify the active image instead of relying on an upload success message. Check every node, gateway, and access point. Confirm that management access, logging, and essential wireless functions work as expected. Record failures and rollback decisions in the same plan so later reviewers can see that the estate was not fully patched.
Mechanism and impact limits
HPE does not identify the vulnerable interface or describe the malformed input that triggers the overflow. The confirmed impact is arbitrary code execution as a privileged user when exploitation succeeds. The CVSS vector shows high confidentiality and integrity impact and low availability impact. Those facts support integrity and credential review after suspicious activity, not a claim that every device was compromised.
Interim controls
While any device remains on an affected release, restrict CLI and web management interfaces to a dedicated Layer 2 segment or VLAN and apply firewall policy at Layer 3 and above. Use accounting controls for user activity and resource use. These measures reduce exposure to management interfaces but do not repair the overflow or prove that another network path is safe.
Exposure context
A ZoomEye Search for app="ArubaOS" returned 212 product matches and the Filter vul.cve="CVE-2026-79872" returned 0. The product count is not a post-patch inventory. It can help find externally visible devices, but only version telemetry can establish whether each device is on a fixed build.
Closure criteria
Close the remediation only when every affected branch maps to a fixed build, every role has a successful verification record, unsupported systems have an owner decision, and management-plane restrictions remain consistent with policy. HPE was not aware of public exploit code at advisory release, but that does not lower the need for a complete upgrade.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.