HPE Aruba patches two unauthenticated code-execution flaws in AOS-CX

September 1, 2026. HPE Aruba Networking publishes advisory HPESBNW05134, fixing more than twenty vulnerabilities in ArubaOS-CX, the operating system of its CX switches. Two independent bugs — CVE-2026-73749 (CVSS 9.8) and CVE-2026-73782 — each give remote code execution without authentication. No confirmed exploitation in the wild so far. Why it matters: a compromised core or access switch becomes a point for traffic interception, VLAN hopping, and persistence that almost no EDR watches.

Two code-execution paths in one bulletin

CVE-2026-73749 is a buffer overflow in an ArubaOS-CX daemon, caused by improper handling of malformed input. A remote attacker sends specially crafted packets to the affected service — no authentication, no user interaction, low attack complexity — and gets code execution with the daemon’s elevated privileges. HPE names neither the daemon nor the transport, standard practice before a public proof-of-concept lands.

CVE-2026-73782 is a format-string vulnerability in the ArubaOS-CX command-line interface, also rated high severity. A format string appears when attacker-controlled input — a hostname, an SNMP string, a syslog message — is passed as a format specifier instead of as data. The attacker can then read or write arbitrary memory and pivot to code execution.

The oddity is the coincidence: two structurally different components of the same OS — a network daemon on one side, the CLI on the other — are independently exploitable with no credentials at all. Most critical bulletins ship one headline bug and a tail of lower-severity fixes. This one ships two.

A range that covers every maintained branch

ArubaOS-CX powers the CX switch portfolio — the 6000, 8000, 9000 and 10000 families — widely deployed in access, distribution, core and top-of-rack roles across campuses, data centers, healthcare, education and service-provider networks. The affected range covers essentially every still-maintained branch:

The detail that marks the severity: the 10.10.x branch has already reached end of maintenance and normally only receives fixes for internally discovered critical issues. HPE made an exception to patch these two bugs on that branch — a signal the vendor treats this as a priority, not routine maintenance.

Why a switch is worse than a server

A switch is not an endpoint. Compromising one gives a position that reaches far beyond the box itself. From a distribution or core switch, an attacker can intercept, redirect, or drop traffic for every host behind it, pivot between VLANs, poison ARP or DHCP tables, and harvest credentials from the TACACS+ or RADIUS flows it relays, plus 802.1X secrets.

Above all, a switch is a stealthy persistence point. Incident responders rarely reimage network gear, and most SOCs have no visibility beyond syslog into what happens on a switch’s management plane. Unauthenticated code execution on the switching fabric is as close to worst-case as network CVEs get.

A busy month for network equipment

The Aruba flaw lands in a dense stretch for network hardware. In early September 2026, CISA added two actively exploited MikroTik RouterOS flaws to the KEV catalog. Cisco, for its part, patched a critical flaw on its Nexus 9000 switches — unauthenticated root code execution via TCP ports 43210 and 43211. Days earlier, Arista shipped fixes for unauthenticated code execution via P4Runtime and gNPSI.

The clustering is no accident. Network equipment has become the preferred target for actors seeking a durable foothold, and vendors concentrate their security advisories at the start of the month, often aligned with their patch cycles. Every critical network-hardware advisory opens a window where fast patching counts double: the device is rarely patched on the same cadence as a server, and its compromise is usually detected only after the fact.

Exposure matters more than the score

There is no public proof-of-concept or confirmed exploitation as of publication, and the flaw is not listed in the CISA KEV catalog. That is not a reason to wait. Critical network-device CVEs with public advisories are routinely weaponized within days to weeks once the fix can be reverse-engineered. The window between “patched and quiet” and “mass scanning” is short for a 9.8 bug on network hardware.

The real question is not the CVSS score but the exposure surface: is your switch management plane isolated in a dedicated VRF or VLAN, or is it reachable from user VLANs — and, worst case, from the internet? These flaws are only reachable if the vulnerable daemon or CLI is reachable by an attacker. In many networks, that reachability is broader than teams assume.

What to do now

The fix comes in three moves, in order.

• Patch first. Apply the fixed branch (10.18.1002, 10.17.1030, 10.16.1060, 10.13.1190, 10.10.1181) at the next maintenance window. Download firmware only from the HPE support portal and verify signatures and checksums.
• Isolate the management plane today, patched or not. Move management interfaces into a dedicated management VRF/VLAN reachable only from named admin hosts, and enforce it with ACLs on every routed path. This single control turns a 9.8 bug into a near-unexploitable one.
• Reduce exposed services. Disable the REST API and web UI (https-server) on any switch that does not need programmatic management, and turn off Telnet and read-write SNMPv1/v2c strings.

Monitoring complements, it does not replace. Centralize ArubaOS-CX syslog to your SIEM and alert on account creation, configuration changes, core dumps, and authentication failures — exploitation attempts against embedded services often produce crash noise before they succeed.

Completeness matters as much as speed. You cannot patch a switch you have not mapped — access-layer closets get forgotten in every patching cycle, and they are exactly where a 9.8 flaw sits longest. Confirm your CMDB reflects every AOS-CX device, then verify each one against the fixed-version matrix. A switch that is invisible to inventory is a switch that will still be vulnerable next quarter.

Before you patch, audit who can actually reach the management plane today. In most networks that reachability is broader than intended — user VLANs, guest segments, even the internet through a misconfigured NAT. That audit is the cheapest control in this article, and it often turns up an exposure the patch alone would not have closed.

Finally, treat the pairing itself as a signal. Two unrelated, no-credentials RCE paths shipping in one bulletin is unusual, and it draws exactly the audience that weaponizes patches — expect researchers to publish diffs within days. If your exposure is not yet locked down, assume the countdown has already started.

Verdict

If you run Aruba CX switches in production, apply the fixed branch at the first available maintenance window: two unauthenticated code-execution flaws shipped in one bulletin is a rare signal, and the history of network CVEs shows it usually precedes mass exploitation. If patching is impossible in the short term, isolate the management plane into a dedicated VLAN/VRF now and disable the REST API and web UI on devices that do not need them — these two controls turn a critical risk into an acceptable residual risk while you schedule the upgrade.

References

• HPE — HPESBNW05134, Multiple Vulnerabilities in HPE Aruba Networking AOS-CX
• SecurityWeek — HPE Patches Critical RCE Vulnerabilities in AOS-CX
• BleepingComputer — HPE patches critical ArubaOS-CX remote code execution flaw
• IONIX Threat Center — CVE-2026-73749
• Security Arsenal — CVE-2026-73749 detection and remediation guide, September 4, 2026