NDSS 2026 research shows practical injection and machine-in-the-middle paths across WPA2/WPA3, guest SSIDs, and enterprise multi-AP deployments
Network security | Wi-Fi | WPA2 | WPA3 | Passpoint | MitM | Guest networks | Campus networks
Metadata
- Affected vendor / product: Multi-vendor Wi-Fi routers, enterprise APs, and Passpoint hotspot deployments (implementation and design issues)
- Primary issue: Client isolation bypass enabling traffic injection, interception, and MitM
- Exploitation status: Confirmed in lab and real-world networks by researchers (no public “mass exploitation” claim made)
- Confidence level: High (research backed by multi-device evaluation and in-the-wild tests on authorised devices)
- Patch / mitigation status: Mixed: ecosystem-level fixes required; some vendor and standards updates noted
- Sectors at risk: Higher education, hospitality, enterprises with guest SSIDs, any environment relying on client isolation as last-line control
Source: AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks (NDSS 2026).
Executive Summary
AirSnitch is a set of attack primitives described in NDSS 2026 research that undermines “client isolation” (also called AP isolation) in Wi-Fi networks. The authors show that, across tested environments, isolation can often be bypassed at three boundaries: Wi-Fi encryption (shared group keys), IP routing (gateway “bounce” paths), and internal switching (MAC-to-port learning behaviours) within access points and distribution systems.
The net effect is that an authenticated insider on the same WLAN, including a guest SSID in some architectures, can regain capabilities defenders often assume are neutralised: client-to-client injection, interception of victim traffic, and full machine-in-the-middle positioning. The researchers report successful attacks against multiple home routers, enterprise-grade devices, and authorised tests in two university networks, including scenarios where traffic can be leaked in plaintext via an open SSID when combined with port-stealing techniques.
For defenders, the key takeaway is not “WPA2/WPA3 are broken”, but that client isolation is inconsistently implemented and not standardised, and therefore cannot be treated as a reliable control against malicious insiders.
Context
Client isolation is widely deployed to block direct station-to-station traffic and reduce the blast radius of compromised endpoints (including IoT). However, the AirSnitch authors highlight that isolation is not an IEEE 802.11 standardised security guarantee, and that real-world enforcement varies by vendor and by where in the stack isolation is applied (link layer, network layer, switching domain).
The research evaluates bypasses across:
- Single-BSSID networks (typical home deployments)
- Multi-SSID and multi-BSSID deployments (guest vs staff SSIDs, multi-band)
- Enterprise and campus networks with multiple APs connected to a shared distribution system
Technical Analysis
1) Wi-Fi encryption layer: abusing group keys to inject traffic
A core enabling factor is group-addressed traffic protection in WPA2/WPA3. APs distribute a Group Temporal Key (GTK) to associated clients for broadcast/multicast frames. AirSnitch demonstrates that if a client can obtain the GTK for a BSSID, it can craft frames that appear to originate from the AP and deliver unicast payloads encapsulated inside GTK-protected broadcast/multicast traffic. Victim operating systems commonly accept these frames and pass the embedded packet up-stack, enabling injection that bypasses AP-side isolation policies.
Why this matters: GTK-based injection occurs over the air and does not rely on the AP forwarding station-to-station frames, so AP “drop client-to-client traffic” logic does not necessarily help. The paper also notes operational risk if GTK rotation is infrequent, as an attacker could retain injection capability until rekeying.
2) Passpoint design gaps: randomisation does not consistently cover all key paths
Passpoint attempts to harden hotspots by recommending per-client GTK randomisation via Downstream Group-Addressed Forwarding (DGAF) disable. AirSnitch finds that the spec’s guidance does not fully cover other key transport paths, and highlights avenues where a “real” group key can be learned or where a shared management-frame integrity key (IGTK) can be abused to influence GTK installation under certain conditions.
Defender note: this is not just a vendor bug class; parts of the problem are rooted in how group keying is handled across roaming and management mechanisms.
3) Routing layer: “gateway bouncing” bypasses L2-only isolation
Many implementations enforce isolation at layer 2 (frame switching) but fail to prevent station-to-station reachability via layer 3 routing. AirSnitch’s gateway bouncing sends traffic with the victim’s IP as the destination, but uses the gateway’s MAC as the layer 2 destination. The gateway then routes the packet back to the victim, effectively reintroducing client-to-client injection despite L2 isolation.
4) Switching layer: port stealing across BSSIDs and even across APs
A major enterprise-relevant finding is the reuse of classic MAC learning / port stealing concepts in Wi-Fi, where each BSSID behaves like a virtual switch port. By authenticating using a victim’s MAC address on a different BSSID, an attacker can influence the AP’s MAC-to-port mappings and, in many tested configurations, redirect victim traffic to the attacker’s association where it is encrypted under the attacker’s negotiated keys.
In some architectures, if the attacker’s association is on an open SSID, the victim’s traffic can be exposed in plaintext over the air after redirection, expanding risk from insider MitM to opportunistic eavesdropping within RF range.
The paper also reports that similar learning manipulation can be effective at the distribution switch level, enabling cross-AP interception when APs share a wired distribution system.
Impact Assessment
Confirmed impact (per research evaluation):
- Traffic injection towards victim clients despite client isolation
- Downlink interception via port stealing and related switching behaviours in many tested devices
- Bidirectional MitM by chaining interception and reinjection techniques
- Enterprise/campus risk even with WPA2/WPA3-Enterprise, where per-user credentials do not prevent these network-layer and switching-layer attacks
Who should care most:
- Organisations relying on guest SSIDs and assuming “guest cannot see staff”
- Universities, hospitals, hotels, and large enterprises with multi-AP roaming SSIDs
- Networks with open/captive portal SSIDs co-resident with encrypted SSIDs on the same infrastructure
Threat Intelligence Context (MITRE ATT&CK mapping)
The paper does not publish ATT&CK mappings; the following is analyst mapping based on described behaviours:
- Credentialed adversary-in-the-middle positioning: T1557
- Network traffic capture / sniffing: T1040
- Endpoint/network impersonation via identifier spoofing (MAC spoofing): often operationally aligned with broader spoofing/impersonation tradecraft used to enable interception (no single perfect ATT&CK technique for “MAC spoofing” in enterprise Wi-Fi; treat as enabling behaviour rather than a discrete technique)
Incident Response Guidance
If you suspect Wi-Fi MitM activity or client isolation bypass in a managed environment:
- Confirm whether L3 isolation exists: test whether clients on “isolated” SSIDs can reach each other’s IPs via routed paths (AirSnitch’s gateway bouncing class).
- Inspect for duplicate MAC associations: hunt for the same client MAC appearing on multiple BSSIDs/APs concurrently (AirSnitch highlights this as a practical mitigation lever in at least one implementation).
- Review SSID co-residency risk: if an open SSID shares infrastructure with encrypted SSIDs, treat cross-SSID learning attacks as a potential plaintext leakage path.
- Collect artefacts: AP controller logs (association/auth events, roaming events), switch MAC tables (if centrally managed), DHCP logs (IP-to-MAC changes), and wireless IDS telemetry if available.
Mitigation Recommendations
AirSnitch’s mitigations emphasise that fixes must cover encryption, routing, and switching together. Notable defensive controls discussed or implied by the research include:
- Segment guest SSIDs into separate VLANs / isolation domains where supported. The paper reports that VLAN separation for guest SSIDs can nullify several exploitation techniques in tested configurations.
- Enforce MAC spoofing resistance in Wi-Fi control planes: disconnect or block clients whose MAC appears on multiple BSSIDs, and consider policies that reject spoofed gateway MACs on the wireless side (where feasible).
- Implement IP spoofing prevention to reduce injection and relay options, including paths used to reinject traffic in MitM chains.
- Harden group key handling: where available, enable per-client group keying approaches such as Passpoint DGAF disable, while tracking standards and vendor updates that address incomplete key randomisation.
- Consider device-to-device link-layer encryption (MACsec, IEEE 802.1AE) for high-risk internal segments where insider MitM is a concern; the authors report validating MACsec integration with WPA2/WPA3 to protect confidentiality and integrity end-to-end between endpoints.
- Treat “client isolation” as a best-effort control, not a boundary: use it alongside segmentation, NAC posture checks, MDM, and monitoring rather than as the primary safeguard.
Responsible Disclosure and ecosystem status
The authors report notifying affected vendors and the Wi-Fi Alliance, providing vendors more than 90 days before public disclosure. They note that long-term mitigation requires coordination across standards bodies, device manufacturers, and operators. The paper states that the Wi-Fi Alliance addressed missing IGTK randomisation in Passpoint v3.4, and that some vendors (including LANCOM) confirmed findings and introduced options such as group key randomisation, while others continued mitigation work at time of writing.
Further Reading
- AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks (NDSS 2026 paper, PDF)
- Mathy Vanhoef on X: AirSnitch overview and client isolation bypass summary (x.com)

