AirSnitch: How Wi-Fi Client Isolation Gets Broken

SPR has defended against these attacks since 2022. We identified how weak network isolation was and built SPR from the ground up to solve it. Per-device VLANs, per-device GTKs, per-device passwords, and coordinated Layer 2/3 firewall policy have shipped as defaults from day one. Every mitigation the paper recommends, SPR already does out of the box.

Now a top-tier academic paper from NDSS 2026 confirms what we've been saying: Wi-Fi client isolation is fundamentally broken. The researchers tested every major router vendor and found that every single one was vulnerable to at least one of their attacks. Even more critically, the attacks break through guest network boundaries into main networks, meaning the "guest Wi-Fi" that most routers advertise as a security feature provides no real isolation.

What Is Client Isolation?

Client isolation (also called AP isolation) is a feature offered by most Wi-Fi routers and access points. When enabled, it blocks direct communication between wireless clients on the same network. It's widely recommended in security guides and is the primary defense against insider attacks like ARP poisoning and ICMP redirects.

The problem: client isolation is not a standardized feature in IEEE 802.11. Vendors implement it inconsistently. Correctly implementing client isolation requires unique per-client passwords, careful coordination between Layer 2 and Layer 3 from Wi-Fi encryption through the IP stack, and disabling shared GTKs that allow clients to bypass the AP and send traffic directly to other clients.

The Attack Methodology

The AirSnitch researchers (from UC Riverside and KU Leuven) analyzed client isolation across three critical boundaries where enforcement should happen:

1. Abusing the Group Temporal Key (GTK)

All clients sharing a BSSID receive the same Group Temporal Key, used for broadcast/multicast traffic. An attacker can abuse this shared key to wrap unicast IP traffic inside a broadcast frame, spoofing the AP's MAC address. The victim's OS decrypts it with the GTK and delivers the embedded IP packet, bypassing isolation entirely.

This worked on all modern operating systems (macOS, iOS, Android, Windows, Linux) and across WPA2 and WPA3 in both Personal and Enterprise modes.

warning

Some implementations that randomize GTKs still have a gap: the GTK delivered during group key handshakes, FT handshakes, or WNM-Sleep Responses may not be randomized, so attackers can simply wait for a periodic key refresh to obtain the real GTK.

2. Gateway Bouncing

Many vendors enforce client isolation at Layer 2 (MAC) but not Layer 3 (IP). An attacker sends packets with the victim's IP as the destination but the gateway's MAC as the Layer 2 destination. The AP allows it through (it's addressed to the gateway), and the gateway routes it back to the victim. The packet "bounces" off the gateway, effectively bypassing Layer 2 isolation.

3. Port Stealing via MAC Spoofing

Each BSSID on an AP functions as a virtualized hardware port connected to an internal software switch. An attacker authenticates on a different BSSID using the victim's MAC address, which tricks the AP's internal switch into remapping the victim's MAC to the attacker's virtual port. All traffic destined for the victim is now forwarded to the attacker, encrypted with the attacker's PTK.

This works across BSSIDs, meaning an attacker on a guest network can intercept traffic from clients on the main/trusted network. If the attacker connects to an open SSID, the victim's WPA2/WPA3-encrypted traffic gets forwarded in plaintext over the attacker's unprotected BSSID.

4. Broadcast Reflection

By crafting a Wi-Fi frame with ToDS=1 and Address 3 set to the broadcast MAC (FF:FF:FF:FF:FF:FF), the AP treats it as group traffic and re-encrypts it with the GTK for all clients on that BSSID. The embedded payload can target a specific victim with unicast IP traffic. Unlike direct GTK abuse, the attacker doesn't need to know the GTK because the AP handles the re-encryption.

Full MitM by Combining Techniques

By chaining port stealing (to intercept traffic) with gateway bouncing or GTK abuse (to return intercepted traffic to the victim), an attacker achieves a full bidirectional Machine-in-the-Middle position. The paper demonstrates this working across BSSIDs and even across physically separate APs that share a wired distribution system.

The end-to-end attack takes about 2 seconds to establish, and the victim experiences no significant lag. The researchers verified this while the victim streamed YouTube.

What's Vulnerable

The researchers tested 7 home routers (Netgear, Tenda, D-Link, TP-Link, ASUS, DD-WRT, OpenWrt) and 4 enterprise devices (Ubiquiti, Cisco Catalyst, LANCOM). Key findings:

• GTK abuse worked against all tested devices regardless of WPA version
• Gateway bouncing worked on most devices across guest and main networks
• Port stealing succeeded on 6 out of 7 home routers and all enterprise devices
• Two real university networks (using WPA2-Enterprise with eduroam) were vulnerable to downlink interception from a guest/open SSID

The attacks also facilitate higher-layer compromise: DNS/DHCP poisoning, stealing plaintext HTTP traffic (still 6-20% of web pages loaded on Windows/Linux), intercepting RADIUS authentication packets to brute-force the shared secret and set up rogue APs, and traffic analysis even against HTTPS connections.

Mitigations

VLAN Segmentation

Place untrusted BSSIDs (guest networks) on separate VLANs. This logically separates the network segments so an attacker on one VLAN cannot use port stealing to reach a victim on another. Ideally, place each user in their own VLAN to synchronize identity across the network stack.

Per-Client GTK Randomization

APs should assign a unique random GTK to each client, converting essential group traffic (like ARP) into unicast frames. This stops GTK abuse attacks. Some vendors like LANCOM have already added this as a configurable option.

Spoofing Prevention

• Reject spoofed gateway MACs on the wireless side
• Prevent the same client MAC from appearing on multiple BSSIDs (as Tenda RX2 Pro does)
• Enable IP spoofing prevention to block gateway bouncing where the source IP doesn't match a legitimate server

Client-Side: wpa_supplicant Frame Filtering

On the client side, wpa_supplicant has landed a patch that hardens clients against GTK abuse by default. Previously, filtering of unicast IP packets hidden inside Layer 2 multicast frames was limited to Hotspot 2.0 networks. The patch introduces two new per-network options:

• drop_unicast_ip_in_l2_multicast — Enabled by default. Instructs the driver to drop unicast IP packets arriving in GTK-encrypted broadcast/multicast frames. This directly blocks the GTK abuse injection vector and broadcast reflection, since both rely on the victim's OS accepting unicast payloads inside group-addressed frames.
• always_use_proxy_arp — When set, the client drops gratuitous ARP and unsolicited Neighbor Advertisement frames if the AP advertises proxy ARP support. This reduces the ARP/NA injection surface that GTK abuse also enables.

The frame filter logic was refactored out of the Hotspot 2.0 code path into a general wpas_configure_frame_filters() function that runs on every association, so all Wi-Fi networks benefit. If you build wpa_supplicant from source, make sure you're on a version that includes this commit.

tip

This is a client-side defense that mitigates GTK abuse and broadcast reflection. It does not protect against gateway bouncing, port stealing, or the full MitM chain, which require AP and network-level fixes.

Client-Side: Apple Kernel Patch

Apple has shipped a kernel fix for iOS and iPadOS (iPhone XS and later, iPad 7th generation and later). Tracked as CVE-2026-20671 and credited to the AirSnitch authors, the advisory describes a logic issue where an attacker in a privileged network position could intercept network traffic, resolved with improved checks. Update to the latest iOS/iPadOS to pick up this fix.

Standardize Client Isolation

The root cause is that client isolation was bolted on by vendors without proper standardization. The Wi-Fi Alliance has started addressing gaps (e.g., adding IGTK randomization), and vendors like LANCOM have added group key randomization options, but industry-wide coordination is still needed.

info

The researchers followed responsible disclosure with 90+ day timelines. Several vendors have issued firmware updates. The Wi-Fi Alliance has acknowledged the findings. Attack tools are open-sourced at github.com/zhouxinan/airsnitch.

Takeaways

If you rely on client isolation to defend against insider threats, especially with shared passwords or guest SSIDs, these attacks undermine that assumption. The most actionable steps:

1. Use VLANs to enforce network segmentation rather than relying solely on AP-level client isolation
2. Enable per-client GTK randomization if your AP supports it
3. Upgrade firmware and check your vendor for AirSnitch-related patches
4. Use WPA2/WPA3-Enterprise with strong RADIUS secrets and encrypted RADIUS transport to limit credential theft

What makes this paper stand out is that the researchers didn't stop at showing weak, partial attack successes. They crafted full bidirectional MitM attacks under scenarios previously thought unexploitable. Speculatively, they may have even solved the mystery of the Hole 196 vulnerability presented at Black Hat in 2010, which demonstrated GTK abuse but was notoriously difficult to reproduce into a practical attack. Systematizing these techniques into a structured, reproducible attack methodology is an impressive feat, and the demonstrated impact was devastating enough to motivate Apple and the wpa_supplicant project to ship fixes.

Client isolation was never standardized, and now we have a comprehensive paper proving it was never reliable either.