Submission ID: 09e49fa1 — HPE Networking Product Public Program (Bugcrowd)
Status: Closed as “Not Applicable — expected network functionality”
GitHub: github.com/JM00NJ/HPE-Aruba-AOS8-Vulnerabilities

Background

This writeup documents a pre-authentication ICMP reflection and Smurf amplification vulnerability confirmed with wire-level evidence from two physically separate machines in ArubaOS 8.13.2.0 LSR. Submitted May 15, 2026.

Triage closed it as “expected network functionality” despite two independent packet captures — one from the attacker, one from the victim — showing an unsolicited Echo Reply arriving at a host that sent zero ICMP requests.

Target

Field Value
Product HPE Aruba Networking Wireless — AOS-8 Controller
Version ArubaOS 8.13.2.0 LSR (Build 95415)
Component ICMP Echo handler — IP stack
Authentication None required
CVSS v3.1 7.4 High — AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
CWE CWE-290 (No Source IP Validation), CWE-406 (Smurf Broadcast Reply)

Vulnerability Description

Component 1 — No Source IP Validation (CWE-290)

The controller does not validate incoming ICMP Echo Request source IPs against MAC/IP bindings or apply reverse path filtering (BCP38/uRPF per RFC 2827). A packet with attacker MAC but victim IP is accepted. The controller ARP-resolves the spoofed source and delivers the reply to the victim.

Component 2 — Broadcast Source Reply (CWE-406)

ICMP Echo Request with Source IP 192.168.56.255 (subnet broadcast) causes the controller to reply to ff:ff:ff:ff:ff:ff, delivering the reply to every host on the L2 segment. Classic Smurf amplification — documented in CERT Advisory CA-1998-01.

Lab Setup

192.168.56.103  Parrot OS  — Attacker
192.168.56.50   ArubaOS    — Target controller
192.168.56.1    Windows    — Victim (passive, never sent ICMP)

Proof of Concept

1
2
3
4
5
6
7

from scapy.all import *

pkt = Ether(src="08:00:27:cc:05:43") / \
      IP(src="192.168.56.1", dst="192.168.56.50") / \
      ICMP(type=8, code=0, id=0xc101)

sendp(pkt, iface="eth0", verbose=0)

Victim PCAP — Frame 1:

192.168.56.50 → 192.168.56.1  ICMP Echo Reply  id=0xc101

The victim received an unsolicited reply. It never sent any ICMP request.

Smurf variant:

Attacker → src=192.168.56.255 → Controller → dst=ff:ff:ff:ff:ff:ff → ALL hosts

Evidence

File Machine Content
parrot_smurf-chain.pcapng Attacker Spoofed request + controller ARP + reply
windows_smurf-chain.pcapng Victim Unsolicited Echo Reply received

The victim-side capture is the primary evidence. A machine that sends zero ICMP requests received an Echo Reply from the controller.

RFC References

RFC 1122 §3.2.2.6 — broadcast ICMP source should not generate a reply.
RFC 2827 / BCP38 — network ingress filtering against IP source spoofing.
CERT Advisory CA-1998-01 — Smurf IP DoS, documented 1998.

The Smurf attack is 28 years old. Every major vendor mitigated it. An enterprise controller shipping in 2026 without broadcast source rejection is not “expected functionality.”

Timeline

Date Event
15 May 2026 Submission created, two-machine pcap attached
01 Jun 2026 N/A — “expected network functionality”
01 Jun 2026 RaR submitted — RFC 1122, CERT CA-1998-01, victim pcap cited

Disclosure Note

The program has classified this as a non-vulnerability. No fix issued, no advisory published. This writeup is published for independent community evaluation.

Vesqer / JM00NJ — netacoding.com