CVE-2026-79844 · HPE Aruba AOS-10 PAPI protocol pre-auth command execution via…

01 · The Real Story

Someone left the master key under the mat, but the mat is inside a locked maintenance closet

CVE-2026-79844 is an authentication bypass (CWE-288) in HPE Aruba Networking AOS-10, the operating system powering Aruba wireless Access Points, Gateways, and Mobility Conductors. The flaw lives in the PAPI protocol (Aruba's AP management channel on UDP port 8211). An unauthenticated attacker who can reach that port can send crafted PAPI packets to bypass authentication controls and execute arbitrary commands on the underlying host — with one caveat HPE keeps vague: *"certain preconditions outside of the attacker's control must be met."* Affected version ranges span AOS-10 10.3.0.0–10.4.1.13, 10.6.0.0–10.7.2.6, and 10.8.0.0–10.8.1.1. Patched releases are 10.4.1.14, 10.7.2.7, and 10.8.1.2 per advisory HPESBNW05162. This is one of eight CVSS 10.0 bugs in a 72-vulnerability mega-patch from HPE.

HPE scored this a perfect 10.0 — the maximum possible — which overstates the real-world risk for most enterprises. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C) models a trivially exploitable, internet-facing, zero-click bug with scope change. But PAPI is a management-plane protocol that should never be routable from untrusted networks. In a properly segmented deployment, only the controller management VLAN can reach UDP 8211 on an AP. Censys data from prior PAPI disclosure cycles found only ~180 hosts with exposed ArubaOS management interfaces internet-wide. Combine that with HPE's own disclosure that unspecified preconditions further limit exploitability, and the 10.0 label is misleading for patch-priority triage. The bug is still dangerous — if an attacker is already on the management network, this is a one-packet-to-RCE path on every AP and gateway in range — but it is not the internet-facing zero-click apocalypse the score implies.

"Auth bypass in Aruba PAPI is serious, but management-plane-only access keeps it off the CRITICAL ledge."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain access to the PAPI management network

The attacker must be able to send UDP packets to port 8211 on a target Aruba device. In the vast majority of enterprise deployments, PAPI traffic is confined to a dedicated management VLAN. The attacker either needs internal network access (post-compromise lateral movement, rogue device on the wireless network, or VPN access) or, in rare misconfigured environments, the port is reachable from the internet.

Conditions required:

Network path to target device's UDP port 8211
Target device running a vulnerable AOS-10 version

Where this breaks in practice:

PAPI is a management protocol — properly segmented deployments restrict it to a management VLAN
Internet exposure is extremely low: ~180 hosts globally per Censys historical scans
Enterprise firewalls and ACLs typically block non-standard UDP ports from user segments

Detection/coverage: Network IDS signatures for anomalous PAPI traffic on UDP 8211; Nessus/Qualys have plugin coverage for prior PAPI CVEs and will likely add checks for this batch. Shodan/Censys dork: port:8211 product:ArubaOS.

STEP 02

Send crafted PAPI packets to bypass authentication

The attacker crafts specially formed PAPI protocol packets that exploit CWE-288 — an alternate authentication path. The protocol accepts the packets without requiring valid credentials, bypassing the normal authentication gate. HPE notes that "certain preconditions outside of the attacker's control" must be met, suggesting a race condition, specific device state, or configuration-dependent trigger. No public PoC exists to clarify the exact mechanism.

Conditions required:

Network reachability to UDP 8211 (from step 1)
Unknown environmental preconditions met on the target

Where this breaks in practice:

Preconditions are unspecified — attacker cannot guarantee they are met
No public PoC or exploit tooling exists to automate this step
PAPI is a proprietary binary protocol with limited public documentation, raising the skill bar

Detection/coverage: Deep packet inspection on PAPI traffic; HPE Aruba Central can log PAPI authentication events; anomalous management-plane access from non-controller IPs should trigger alerts.

STEP 03

Execute arbitrary commands as privileged user

Once authentication is bypassed, the attacker can inject commands into the underlying AOS-10 Linux-based operating system. Command execution runs with elevated privileges, giving the attacker full control of the AP, Gateway, or Conductor. From here the attacker can intercept wireless traffic, pivot to other network segments, extract wireless credentials (including RADIUS shared secrets and 802.1X configurations), or implant persistent backdoors.

Conditions required:

Successful authentication bypass (step 2)

Where this breaks in practice:

Post-exploitation on embedded AOS devices requires familiarity with the proprietary filesystem and services
EDR/AV cannot run on AOS devices — detection depends on network monitoring
Persistence mechanisms on APs may not survive firmware upgrades

Detection/coverage: Aruba IDS/IPS integration; syslog anomalies (unexpected shell spawns, config changes); HPE Aruba Central alerts on unauthorized management sessions; configuration integrity monitoring.

STEP 04

Lateral movement and infrastructure compromise

On a compromised Mobility Conductor or Gateway, the attacker has visibility into the entire wireless fleet. They can push rogue configurations to all managed APs, intercept enterprise wireless authentication flows (RADIUS, EAP), harvest credentials, and pivot into connected wired network segments. On a standalone AP, the blast radius is narrower but still includes traffic interception for all clients associated with that AP and potential VLAN-hopping into adjacent segments.

Conditions required:

Command execution achieved on a Conductor/Gateway (highest impact) or AP (moderate impact)

Where this breaks in practice:

Network segmentation between management and production limits pivot paths
Wireless traffic may be encrypted end-to-end (WPA3-Enterprise, TLS) limiting passive interception value
Fleet-wide push requires Conductor-level compromise, not just a single AP

Detection/coverage: Aruba Central configuration change auditing; 802.1X/RADIUS log anomalies; unexpected AP reboots or firmware changes; network flow analysis for anomalous east-west traffic from AP management IPs.

03 · Compensating Control

HIGH 8.2→LOW 3.2

SEVERITY REDUCED

Block UDP 8211 from all non-controller sources at the management VLAN ACL — This is HPE's recommended workaround for AOS-10 (cluster-security is AOS-8 only). Configure infrastructure ACLs or firewall rules to permit PAPI traffic only from known Aruba Central / controller management IPs to AP management interfaces. This completely eliminates the unauthenticated remote attack path for any attacker who is not already on the controller. As a HIGH-severity finding, deploy this control within 30 days per noisgate mitigation SLA — though given the pre-auth nature, earlier is better.

HIGH 8.2→LOW 2.8

SEVERITY REDUCED

Enforce management VLAN isolation with dedicated out-of-band management network — Place all Aruba AP, Gateway, and Conductor management interfaces on a physically or logically separated management network that is not routable from user VLANs, guest networks, or the internet. This is defense-in-depth beyond the ACL control — even if the ACL is misconfigured, network topology prevents reachability. Deploy within 30 days.

HIGH 8.2→MEDIUM 5.5

SEVERITY REDUCED

Enable PAPI enhanced security mode where available — On AOS-8 devices in the same fleet, enable cluster-security to encrypt and authenticate PAPI communications. While this does not directly mitigate CVE-2026-79844 on AOS-10, it protects AOS-8 devices from the related batch of 72 vulnerabilities and reduces the overall PAPI attack surface in mixed fleets. Deploy within 30 days.

HIGH 8.2→HIGH 7.5

Deploy network detection for anomalous PAPI traffic — Configure IDS/IPS rules or network monitoring to alert on PAPI traffic (UDP 8211) from unexpected source IPs — particularly from user VLANs, guest networks, or external sources. Aruba Central provides management-plane audit logging that should be forwarded to your SIEM. This does not prevent exploitation but dramatically improves detection time. Deploy within 30 days.

HIGH 8.2→IGNORE 0.0

SEVERITY REDUCED

Upgrade to patched AOS-10 firmware — Apply the definitive fix by upgrading to AOS-10 10.8.1.2, 10.7.2.7, or 10.4.1.14. For end-of-maintenance branches (10.5.x, older 10.6.x), plan migration to a supported branch — no patch is coming. Per noisgate remediation SLA for HIGH severity, complete patching within 180 days. Prioritize Conductors and Gateways first given their fleet-scale blast radius.

What doesn't work

WAF / reverse proxy — PAPI is a UDP-based binary protocol, not HTTP. Web application firewalls provide zero coverage.
EDR / endpoint agents — AOS-10 is an embedded Linux OS on access points and gateways. No EDR agent can be installed on these devices. Detection must be network-based.
WPA3 or 802.1X hardening — These protect wireless client authentication but do not affect the PAPI management-plane attack vector. The vulnerability is in device management, not client-facing wireless security.
TLS/certificate pinning on PAPI — AOS-10 does not support authenticated/encrypted PAPI natively (unlike AOS-8 cluster-security). You cannot encrypt your way out of this; block at the network layer.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	Not observed. No CISA KEV listing, no vendor confirmation of active exploitation, no campaign reporting as of 2026-10-23. HPE's advisory does not flag active exploitation.
Proof-of-Concept	None publicly available. No PoC on pocindex.io, GitHub, ExploitDB, or Nuclei templates. PAPI is a proprietary binary protocol with limited public tooling, which raises the bar for independent exploit development.
EPSS Score	Not yet scored. CVE was published 2026-10-22 — EPSS scoring typically lags by several days. Expect a moderate-to-high initial EPSS score given the CVSS 10.0 base and network attack vector, but the management-plane-only access pattern historically tempers EPSS predictions for PAPI bugs.
KEV Status	Not listed as of 2026-10-23. Prior Aruba PAPI CVEs (e.g., CVE-2024-42509, CVE-2024-47460) were also not added to KEV despite CVSS 9.8 scores, suggesting CISA considers the management-plane restriction a mitigating factor.
CVSS Vector Analysis	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N` — Network/Low-complexity/No-privileges/No-interaction with Scope Change. The S:C (scope change) is accurate: compromise of a Conductor changes the security scope of all managed APs. However, AV:N overstates real reachability since PAPI is a management-plane protocol.
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. Note: AOS-10 branches 10.5.x and 10.6.x-below-10.6.0.0 are end-of-maintenance and will NOT receive patches.
Fixed Versions	AOS-10 10.4.1.14, 10.7.2.7, 10.8.1.2. AOS-8 users should also update to 8.13.3.1 or 8.10.0.24 for the broader 72-CVE batch.
Scanning / Internet Exposure	Censys historically identified ~180 hosts with exposed ArubaOS management interfaces. PAPI on UDP 8211 has minimal internet exposure. Most deployments restrict PAPI to management VLANs. Shodan dork: `port:8211`.
Vendor Market Share	HPE Aruba holds approximately 11–14% of the enterprise wireless AP market (IDC 2025–2026). This means the vulnerability affects a significant installed base across Fortune 500 and mid-market enterprises.
Disclosure Timeline	Published 2026-10-22 per NVD/HPE. Part of a 72-vulnerability disclosure in advisory HPESBNW05162. Canadian Cyber Centre issued advisory AV26-1046 on 2026-10-15 (advance notification).

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.2/10)

Why this verdict

Management-plane restriction: PAPI on UDP 8211 is a management protocol confined to management VLANs in any properly segmented deployment. The CVSS AV:N score models internet-facing reachability, but real-world exposure is ~180 hosts globally. This single factor eliminates the majority of the unauthenticated-remote threat surface that justifies a 10.0.
Unspecified preconditions: HPE explicitly states that "certain preconditions outside of the attacker's control must be met" — this contradicts the AC:L (low attack complexity) in the CVSS vector. Unknown preconditions represent real friction that the CVSS score ignores.
No PoC or exploitation: Zero days after disclosure, there is no public exploit code, no Nuclei template, no Metasploit module, and no observed campaign. PAPI's proprietary binary protocol raises the skill bar for independent exploit development. Prior PAPI CVEs (CVE-2024-42509, CVE-2024-47460) also never saw public exploitation despite 9.8 scores.
Role multiplier: AOS-10 is a canonical network infrastructure component — it runs on wireless APs, Gateways, and Mobility Conductors. On a standalone AP (typical role ~70% of installs), compromise yields traffic interception for that AP's clients and a lateral-movement pivot — blast radius is host-to-segment. On a Mobility Conductor or Gateway (high-value role ~15–20% of installs), compromise gives fleet-scale wireless infrastructure takeover: the attacker can push rogue configs to all managed APs, intercept RADIUS/EAP flows, and pivot to wired segments — blast radius is fleet-scale. Because this is a canonical network infrastructure component and the Conductor/Gateway scenario is fleet-scale with ≥10% of the installed base occupying that role, the verdict floor is HIGH.
No active exploitation keeps this below CRITICAL floor: Despite the high-value-role floor, the combination of management-plane-only reachability, unspecified preconditions, and zero exploitation evidence means the real-world immediacy does not justify CRITICAL. The floor holds at HIGH.

Why not higher?

The floor for a canonical network infrastructure component with fleet-scale blast radius on Conductors/Gateways would be CRITICAL if the attack path were frictionless and internet-facing. However, PAPI's management-plane confinement means the attacker must already have internal network access or exploit a rare misconfiguration. HPE's own "preconditions outside attacker's control" language further limits the chain. No PoC or exploitation activity confirms that the weaponization barrier is non-trivial. CRITICAL would require either confirmed exploitation, a public PoC demonstrating trivial exploitation, or evidence of significant internet exposure — none of which exist.

Why not lower?

Dropping to MEDIUM would ignore the canonical high-value-role floor. AOS-10 Conductors and Gateways are fleet-critical infrastructure: compromising one gives an attacker control of every managed AP and visibility into all enterprise wireless traffic. Aruba holds 11–14% of the enterprise wireless market, meaning hundreds of thousands of devices are affected. The authentication bypass is unauthenticated — no credentials needed — and any attacker who has reached the management VLAN (common post-initial-access) gets one-packet RCE. The scope-change property is real: AP compromise changes the security boundary for all associated wireless clients. MEDIUM would be appropriate only if the blast radius were limited to a single low-value host, which it demonstrably is not.

06 · Verification

Crowdsourced verification payload.

Run this script on any host with network access to the Aruba device management interface (e.g., a jump box on the management VLAN). Pass the target device IP as the first argument: bash check_cve_2026_79844.sh 10.1.1.100. Requires snmpget or curl for version detection — no elevated privileges needed on the auditor host. The script checks the AOS version via SNMP or HTTP and compares against known-vulnerable ranges.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_79844.sh — Check HPE Aruba AOS-10 for CVE-2026-79844
# Usage: bash check_cve_2026_79844.sh <target_ip>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_ip>"
  echo "UNKNOWN — no target specified"
  exit 2
fi

echo "[*] Checking CVE-2026-79844 on $TARGET"
echo "[*] Attempting HTTPS version detection..."

# Try to grab version from the web UI login page or API
VERSION=""
if command -v curl &>/dev/null; then
  # Aruba devices often expose version in the login page or REST API
  RAW=$(curl -sk --connect-timeout 5 --max-time 10 "https://${TARGET}/rest/v1/configuration/object/version" 2>/dev/null || true)
  if [[ -n "$RAW" ]]; then
    VERSION=$(echo "$RAW" | grep -oP '10\.[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
  fi
  # Fallback: try login page
  if [[ -z "$VERSION" ]]; then
    RAW=$(curl -sk --connect-timeout 5 --max-time 10 "https://${TARGET}/" 2>/dev/null || true)
    VERSION=$(echo "$RAW" | grep -oP 'AOS[- ]?10[._]([0-9]+[._])+[0-9]+' | head -1 | sed 's/[_]/./' | grep -oP '10\.[0-9]+\.[0-9]+\.[0-9]+' || true)
  fi
fi

# Fallback: try SNMP if available
if [[ -z "$VERSION" ]] && command -v snmpget &>/dev/null; then
  echo "[*] HTTPS failed, trying SNMP..."
  RAW=$(snmpget -v2c -c public -t 5 "$TARGET" 1.3.6.1.2.1.1.1.0 2>/dev/null || true)
  VERSION=$(echo "$RAW" | grep -oP '10\.[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — could not detect AOS-10 version on $TARGET"
  echo "[*] Verify manually: check 'show version' on the device CLI"
  exit 2
fi

echo "[*] Detected AOS-10 version: $VERSION"

# Version comparison function
version_lte() {
  [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

version_gte() {
  [ "$(printf '%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

# Check against vulnerable ranges
# Range 1: 10.3.0.0 - 10.4.1.13 (fixed: 10.4.1.14)
# Range 2: 10.6.0.0 - 10.7.2.6 (fixed: 10.7.2.7)
# Range 3: 10.8.0.0 - 10.8.1.1 (fixed: 10.8.1.2)

VULNERABLE=false

if version_gte "$VERSION" "10.3.0.0" && version_lte "$VERSION" "10.4.1.13"; then
  echo "[!] Version $VERSION is in vulnerable range 10.3.0.0 - 10.4.1.13"
  echo "[!] Upgrade to 10.4.1.14 or later"
  VULNERABLE=true
elif version_gte "$VERSION" "10.6.0.0" && version_lte "$VERSION" "10.7.2.6"; then
  echo "[!] Version $VERSION is in vulnerable range 10.6.0.0 - 10.7.2.6"
  echo "[!] Upgrade to 10.7.2.7 or later"
  VULNERABLE=true
elif version_gte "$VERSION" "10.8.0.0" && version_lte "$VERSION" "10.8.1.1"; then
  echo "[!] Version $VERSION is in vulnerable range 10.8.0.0 - 10.8.1.1"
  echo "[!] Upgrade to 10.8.1.2 or later"
  VULNERABLE=true
elif version_gte "$VERSION" "10.5.0.0" && version_lte "$VERSION" "10.5.99.99"; then
  echo "[!] Version $VERSION is in end-of-maintenance branch 10.5.x"
  echo "[!] No patch available — migrate to a supported branch"
  VULNERABLE=true
fi

if $VULNERABLE; then
  echo "VULNERABLE — CVE-2026-79844 affects this device"
  exit 1
else
  echo "PATCHED — version $VERSION is not in a known vulnerable range"
  exit 0
fi