HPE Aruba Networking issues a critical security patch for AOS-CX switches to prevent unauthenticated remote password resets.
What a CVSS 9.8 password-reset flaw means on the switch fabric
HPE Aruba Networking has issued a critical security patch for AOS-CX switches after identifying a weakness that can allow unauthenticated remote password resets. A score of 9.8 on the Common Vulnerability Scoring System places the issue near the top of the severity scale: an attacker does not need valid credentials, and the attack can be attempted over the network rather than only from a local console or a trusted management segment.
On a switch platform, resetting administrative credentials is not a narrow account problem. It can open the path to changing VLAN membership, routing, ACLs, SNMP, and management access itself. Once an attacker can set a new password without proving who they are, they can lock out legitimate operators and reconfigure the device as the new “owner.” Treat that as a full compromise of the control plane for that box until you prove otherwise.
Why unauthenticated remote resets are especially dangerous
Password-reset flows exist so operators can recover access after lockouts. When that flow can be reached without authentication, the recovery path becomes an attack path. Network devices often sit at trust boundaries: they terminate management sessions, enforce segmentation, and sometimes host services that other systems rely on for connectivity. Compromising one switch can cascade into lateral movement, traffic interception, or denial of service across connected hosts.
Unauthenticated remote reset also undermines monitoring. Logs may show a legitimate-looking credential change rather than a failed login storm. If your detection depends only on brute-force alerts, you may miss the quieter pattern of a successful reset followed by a new admin session from an unexpected address.
What network teams should do now
- Inventory every AOS-CX switch and confirm which management interfaces are reachable from untrusted or broad networks.
- Apply the vendor security patch on a controlled schedule, prioritizing internet-facing and shared-management devices first.
- Restrict management planes to dedicated VLANs, jump hosts, or out-of-band paths; do not leave SSH, HTTPS, or other admin endpoints on user or guest segments.
- Rotate administrative credentials after patching any device that may have been exposed, and invalidate stale local accounts you no longer need.
- Review recent configuration and account changes for unexplained password updates, new users, or altered AAA settings.
If a device cannot be patched immediately, reduce exposure: block management ports at upstream firewalls, require VPN or bastion access, and increase logging for authentication and configuration events. Compensating controls do not replace the patch, but they shrink the window in which an unauthenticated reset can be attempted.
Operational habits that reduce blast radius next time
Use unique local passwords per device or a centralized AAA system so a single reset does not unlock a whole fleet. Prefer role-based accounts over shared “admin” logins, and keep configuration backups so you can restore known-good state if an attacker changes the box after taking control. Document who can reach the management network and review that list whenever topology changes.
Critical alerts like this one are a reminder that switches are high-value targets, not background plumbing. Patch promptly, keep management off the open network, and treat any unexplained credential change on AOS-CX gear as an incident until you have ruled out abuse.