CVE-2026-79846 · HPE Aruba AOS PAPI protocol unauthenticated CLI service command…

01 · The Real Story

A root-shell vending machine bolted to your wireless backbone — just feed it one crafted UDP packet, no coins needed

CVE-2026-79846 is an unauthenticated command injection in the CLI service of HPE Aruba Networking's AOS-8 and AOS-10 wireless operating systems, reachable via the PAPI management protocol on UDP port 8211. An attacker who can send a single specially crafted UDP packet to this port achieves privileged OS command execution on Access Points, Mobility Conductors, Controllers, and Gateways — no credentials, no user interaction, no multi-step chain. Affected AOS-10 versions span 10.3.0.0 through 10.8.1.1 across three release trains; AOS-8 versions span 8.10.0.0–8.10.0.23 and 8.12.0.0–8.13.3.0. Fixed releases are AOS-10 10.8.1.2 / 10.7.2.7 / 10.4.1.14 and AOS-8 8.13.3.1 / 8.10.0.24. This CVE is one of eight CVSS 10.0 bugs in the HPESBNW05162 advisory, which patches 72 total flaws (34 critical).

HPE's CRITICAL / 10.0 rating is technically accurate for the vulnerability in isolation — the CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is a fair reflection of what happens when a crafted packet reaches UDP 8211. Where the vendor score overstates real-world risk is the AV:N assumption: PAPI is a management-plane protocol between APs and controllers that operates on internal campus or management VLANs. Censys found only ~180 ArubaOS hosts with exposed SNMP in mid-2024, and direct internet exposure of UDP 8211 is essentially zero. That said, Aruba wireless infrastructure is a canonical network edge appliance — HPE holds ~15–20% of the enterprise WLAN market — and compromising it yields fleet-scale wireless traffic interception, credential harvesting, and lateral movement. noisgate retains CRITICAL severity because the blast radius on this class of device is catastrophic, but adjusts the score from 10.0 to 9.4 to reflect the management-plane-only attack surface.

Bottom line: Under the noisgate mitigation SLA for CRITICAL findings, deploy compensating controls — enable cluster-security on AOS-8 and block UDP 8211 from untrusted segments — within 3 days. Under the noisgate remediation SLA, apply vendor patches (AOS-8 8.13.3.1 / 8.10.0.24; AOS-10 10.8.1.2 / 10.7.2.7 / 10.4.1.14) within 90 days. No active exploitation or KEV listing overrides these timelines today, but given the zero-auth single-packet attack path on network infrastructure, treat mitigation urgently — a public PoC would convert this from theoretical to mass-exploitable overnight.

"One UDP packet, no auth, full RCE on your Aruba wireless fleet. PAPI is internal — but so is the attacker."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Internal network positioning

Attacker establishes presence on a network segment that can route UDP traffic to Aruba device management interfaces on port 8211. This could be via a compromised endpoint, VPN credentials, rogue wireless client, or physical access to a campus network port. PAPI is not typically internet-reachable, so the attacker must be inside the perimeter or on a connected partner/vendor network.

Conditions required:

Internal network access or access to a segment with routing to management VLAN
Ability to send UDP packets to port 8211

Where this breaks in practice:

Requires initial foothold — phishing, credential theft, physical, or supply-chain compromise
Properly segmented management VLANs with ACLs restrict which hosts can reach UDP 8211
802.1X/NAC may block unauthorized devices from joining the network

Detection/coverage: NAC logs, 802.1X authentication failures, VPN anomaly detection, physical port security alerts

STEP 02

Target discovery via UDP 8211 scanning

Attacker scans the reachable subnets for hosts listening on UDP 8211 using tools like nmap -sU -p 8211. PAPI is enabled by default on all Aruba APs and controllers, so any device running a vulnerable AOS version will respond. The attacker can also fingerprint the AOS version via SNMP or HTTP management interfaces if those are reachable.

Conditions required:

Network scanner (nmap, masscan)
Reachability to target subnets

Where this breaks in practice:

UDP scanning is slow and generates significant traffic — IDS/NIDS should flag large-scale UDP scans
In well-segmented networks, the management VLAN may not be reachable from the attacker's position

Detection/coverage: IDS/NIDS rules for UDP port-scan activity on 8211; NetFlow/sFlow anomaly detection for unusual UDP traffic patterns to infrastructure devices

STEP 03

Craft PAPI exploitation packet

The attacker constructs a specially formed PAPI UDP datagram targeting the underlying CLI service handler. The PAPI protocol is proprietary but has been partially reverse-engineered by researchers working on prior CVEs (CVE-2024-42509, CVE-2024-26304). The injected payload embeds OS commands within PAPI message fields that the CLI service parser fails to sanitize. No public PoC for *this* CVE exists yet, but the PAPI attack surface is well-documented from prior rounds.

Conditions required:

Knowledge of PAPI protocol wire format
Understanding of the CLI service command injection vector

Where this breaks in practice:

No public PoC or exploit code as of 2026-10-23
Requires reverse-engineering or adaptation from prior PAPI exploit research
PAPI protocol details are not publicly documented by HPE

Detection/coverage: Deep packet inspection on UDP 8211 if available; Aruba IDS signatures for malformed PAPI packets (limited availability)

STEP 04

Unauthenticated command execution

The crafted packet reaches the CLI service handler via PAPI. Due to improper input validation (CWE-77), the injected OS commands execute as a privileged user on the underlying ArubaOS Linux-based operating system. No authentication token, session cookie, or prior handshake is required — the vulnerability is fully pre-auth. The attacker now has a root-equivalent shell on the AP, controller, conductor, or gateway.

Conditions required:

Target running a vulnerable AOS version (default PAPI listener active)
Crafted packet delivered to UDP 8211

Where this breaks in practice:

None once the packet reaches the service — zero authentication, zero interaction, zero complexity

Detection/coverage: ArubaOS has limited host-based monitoring; no standard EDR agent coverage. Process execution anomalies may be visible via Aruba Central or syslog forwarding if configured.

STEP 05

Wireless infrastructure takeover and lateral movement

With privileged access on the Aruba device, the attacker can intercept all wireless client traffic (MitM), extract stored credentials (RADIUS shared secrets, 802.1X configurations, WPA keys), modify firmware for persistence, pivot into connected VLANs and backend networks, and propagate to other APs/controllers via trusted management channels. A compromised Mobility Conductor can push malicious configurations to the entire AP fleet.

Conditions required:

Root shell from step 4
Knowledge of Aruba device internals and management architecture

Where this breaks in practice:

Embedded Linux environment limits available tooling compared to a full server
Firmware integrity checks on some newer models may detect modifications
Aruba Central cloud management may flag unexpected configuration changes

Detection/coverage: Configuration drift alerts from Aruba Central or Mobility Conductor; anomalous east-west traffic from AP management IPs; RADIUS authentication log anomalies; wireless IDS detecting rogue AP behavior

03 · Compensating Control

CRITICAL 9.4→LOW 2.5

SEVERITY REDUCED

Enable PAPI Enhanced Security (cluster-security) on AOS-8 devices — Run cluster-security on all Instant AOS-8 access points and controllers. This forces PAPI communication to use authenticated and encrypted channels, preventing unauthenticated exploitation of the CLI service via crafted packets. This is HPE's recommended workaround and has been effective for all prior PAPI CVEs. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. Note: this command is not available on AOS-10 — use UDP 8211 blocking instead.

CRITICAL 9.4→MEDIUM 5.5

SEVERITY REDUCED

Block UDP 8211 from all untrusted network segments — Deploy firewall rules or infrastructure ACLs restricting UDP 8211 to only authorized management hosts, controller IPs, and AP subnets. On AOS-10 (where cluster-security is unavailable), this is the primary mitigation. Ensure the rules are applied at the switch/router layer closest to the APs. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings.

CRITICAL 9.4→MEDIUM 4.5

SEVERITY REDUCED

Isolate AP/controller management on a dedicated VLAN with strict ACLs — If not already segmented, move all Aruba management traffic to a dedicated management VLAN accessible only from jump hosts or a network management station. This reduces the population of hosts that can reach PAPI from the entire campus to a handful of authorized management systems. This is a defense-in-depth measure that compounds with the UDP 8211 block.

CRITICAL 9.4→IGNORE 0.0

SEVERITY REDUCED

Apply vendor patches to fixed AOS versions — Upgrade AOS-10 to 10.8.1.2, 10.7.2.7, or 10.4.1.14; upgrade AOS-8 to 8.13.3.1 or 8.10.0.24. This eliminates the vulnerability entirely. Complete within 90 days per the noisgate remediation SLA for CRITICAL findings. Stage rollouts by site criticality — patch controllers and conductors first, then APs.

What doesn't work

Web Application Firewall (WAF) — PAPI is a proprietary binary UDP protocol on port 8211, not HTTP/HTTPS. WAFs cannot inspect, parse, or filter this traffic.
Endpoint Detection and Response (EDR) — The vulnerable component is embedded firmware on APs and controllers, not a user-space process on a managed endpoint. No mainstream EDR agent runs on ArubaOS devices.
TLS/SSL inspection — PAPI does not use TLS. SSL inspection appliances have no ability to proxy or inspect UDP 8211 traffic. This also means the protocol inherently lacks confidentiality unless cluster-security is enabled.
Disabling the PAPI service — PAPI is required for AP-to-controller communication. Disabling it breaks the wireless management plane and renders APs unmanageable. This is not a viable workaround.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None confirmed. Not listed on CISA KEV. Previous PAPI CVEs (CVE-2024-42509, CVE-2024-26305) also never reached KEV despite 2+ years of exposure, suggesting the internal-only attack surface limits mass exploitation.
PoC / exploit code	None public. No repos found on GitHub or pocindex.io for CVE-2026-79846. One PoC exists for the analogous CVE-2024-26304 (X-Projetion/CVE-2024-26304-RCE-exploit), demonstrating the PAPI wire format is reverse-engineerable.
EPSS	Not yet scored — CVE disclosed 2026-10-22 (1 day ago), NVD analysis pending. The analogous CVE-2024-42509 had EPSS of 2.0% (low percentile), suggesting these PAPI bugs historically score low on exploitation probability.
CISA KEV	Not listed as of 2026-10-23. No previous Aruba PAPI command injection CVE has been added to KEV.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` → 10.0. The `S:C` (Changed scope) reflects that AP/controller compromise impacts connected wireless clients and backend networks. `AV:N` is technically valid but overstates internet reachability — PAPI is management-plane traffic.
Affected versions	AOS-10: 10.3.0.0–10.4.1.13, 10.6.0.0–10.7.2.6, 10.8.0.0–10.8.1.1. AOS-8: 8.10.0.0–8.10.0.23, 8.12.0.0–8.13.3.0. Affects Mobility Conductors, Controllers, Gateways, and Access Points.
Fixed versions	AOS-10: 10.4.1.14, 10.7.2.7, 10.8.1.2. AOS-8: 8.10.0.24, 8.13.3.1. No distro backports apply — these are firmware updates from HPE.
Exposure surface	PAPI (UDP 8211) is an internal AP↔controller management protocol. Censys observed ~180 ArubaOS hosts via SNMP (May 2024); direct UDP 8211 internet exposure is effectively zero. HPE Aruba holds ~15–20% of the enterprise WLAN market (IDC Q2 2025, $376M revenue).
Disclosure & advisory	Disclosed 2026-10-22. HPE advisory HPESBNW05162. Part of a batch: 72 CVEs total, 34 critical, 8 at CVSS 10.0.
Credits	Majority found internally by HPE Networking. External: Bugcrowd researchers (moonv, LIUPENG, zzcentury), Diego Gomez, David Kierznowski, and a Siemens Energy team member.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.4/10)

Why this verdict

Unauthenticated single-packet RCE: A lone crafted UDP datagram achieves privileged OS command execution on network infrastructure — zero credentials, zero interaction, zero complexity. This is the most dangerous class of network device vulnerability.
Role multiplier: Aruba APs and controllers ARE network edge appliances by definition — ≥90% of the installed base serves exactly this canonical high-value role (campus/branch wireless backbone). Successful exploitation yields fleet-scale wireless traffic interception, credential harvesting (RADIUS secrets, 802.1X configs), and lateral pivot into backend networks. A compromised Mobility Conductor can push malicious config to the entire AP fleet. This locks the verdict floor at CRITICAL.
Internal-only friction (does not break floor): PAPI UDP 8211 is a management-plane protocol. Internet exposure is near zero (~180 ArubaOS hosts found by Censys via SNMP in 2024; direct PAPI exposure likely lower). This prevents mass internet-driven exploitation but does NOT lower the severity class — any post-initial-access attacker, insider, or compromised host on the campus LAN reaches PAPI trivially. A generic 'requires internal access' statement is not sufficient to break the CRITICAL floor for network infrastructure.
No PoC / no exploitation — score adjustment only: With no public exploit code, no observed in-the-wild activity, and no KEV listing, we adjust the numerical score from 10.0 to 9.4 while maintaining CRITICAL severity. Prior PAPI CVEs (2023–2024) also never reached KEV, suggesting the weaponization gap provides a brief patching window — but the PAPI attack surface has been reverse-engineered before (CVE-2024-26304 PoC exists on GitHub).
Batch context amplifies urgency: This CVE is one of 8 CVSS-10.0 bugs and 34 critical flaws in a single advisory (HPESBNW05162). Attackers targeting Aruba infrastructure will have 72 vulnerabilities to chain or choose from — the effective attack surface is larger than any single CVE suggests.

Why not higher?

The vendor's 10.0 assumes AV:N internet reachability to UDP 8211, which does not match real deployments. PAPI is a management-plane protocol operating within campus/management VLANs, and direct internet exposure is effectively zero. Additionally, no public PoC exists and no in-the-wild exploitation has been observed, meaning the immediate mass-exploitation risk is lower than the 10.0 score implies. A perfect 10.0 should be reserved for vulnerabilities with confirmed internet-facing exposure and active weaponization.

Why not lower?

Aruba wireless infrastructure is a canonical network edge appliance deployed by ~15–20% of the enterprise WLAN market. The exploitation chain requires no authentication, no user interaction, and achieves privileged RCE via a single UDP packet. From the internal network — which is the realistic attack surface — the chain is trivially weaponizable, and the blast radius is fleet-scale: wireless traffic interception, credential theft, persistent backdoors on devices with no EDR coverage. The CRITICAL floor is locked by the deployment-role blast radius rule and cannot be broken by the 'internal access required' friction alone.

06 · Verification

Crowdsourced verification payload.

Run this script from any auditor workstation with SSH access to the target Aruba AP, controller, or conductor. Usage: bash check_cve_2026_79846.sh 10.1.1.1 admin. Requires SSH credentials for the device (typically the admin account). Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-79846 Checker — HPE Aruba AOS PAPI CLI Service Command Injection
# Connects via SSH, parses AOS version, checks against vulnerable ranges.
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

TARGET="${1:-}"
SSH_USER="${2:-admin}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <host> [ssh_user]"
  echo "Example: $0 10.1.1.1 admin"
  exit 2
fi

echo "[*] Connecting to $TARGET as $SSH_USER ..."
RAW=$(ssh -o ConnectTimeout=15 -o StrictHostKeyChecking=no -o BatchMode=yes \
  "$SSH_USER@$TARGET" "show version" 2>/dev/null) || {
  echo "UNKNOWN - SSH connection to $TARGET failed."
  exit 2
}

# Parse AOS version from 'show version' output
VER=$(echo "$RAW" | grep -oP '[Vv]ersion\s+\K[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [[ -z "$VER" ]]; then
  VER=$(echo "$RAW" | grep -oP 'AOS[- ]*[0-9]+[^0-9]+\K[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)
fi
if [[ -z "$VER" ]]; then
  echo "UNKNOWN - Could not parse AOS version from device output."
  exit 2
fi
echo "[*] Detected AOS version: $VER"

# Version less-than-or-equal comparison for dotted quads
vle() {
  [[ "$(printf '%s\n' "$1" "$2" | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | head -1)" == "$1" ]]
}

FIX=""
# --- AOS-10 vulnerable ranges ---
if vle "10.8.0.0" "$VER" && vle "$VER" "10.8.1.1"; then
  FIX="10.8.1.2"
elif vle "10.6.0.0" "$VER" && vle "$VER" "10.7.2.6"; then
  FIX="10.7.2.7"
elif vle "10.3.0.0" "$VER" && vle "$VER" "10.4.1.13"; then
  FIX="10.4.1.14"
# --- AOS-8 vulnerable ranges ---
elif vle "8.12.0.0" "$VER" && vle "$VER" "8.13.3.0"; then
  FIX="8.13.3.1"
elif vle "8.10.0.0" "$VER" && vle "$VER" "8.10.0.23"; then
  FIX="8.10.0.24"
fi

if [[ -n "$FIX" ]]; then
  echo "VULNERABLE - AOS $VER is in a CVE-2026-79846 affected range."
  echo "  Recommended upgrade: $FIX or later."
  exit 1
else
  echo "PATCHED - AOS $VER is not in any known vulnerable range for CVE-2026-79846."
  exit 0
fi