Mathy Vanhoef (KU Leuven, of KRACK and FragAttacks) and collaborators from UC Riverside took aim at Wi-Fi client isolation, the feature behind every "guest network" and coffee-shop AP that is supposed to stop one connected client from attacking another. Their finding: isolation is enforced at one layer at a time, but a network is a stack, so an attacker who moves between layers walks around it. They show three bypasses, (1) abusing the shared Wi-Fi group key to inject frames, (2) "gateway bouncing" to inject at the IP layer, and (3) Ethernet "port stealing" to intercept, and combine them into full man-in-the-middle in both directions. Across 7 home routers and 4 professional access points with isolation switched on, and two university networks, every tested device and network had at least one flaw. The root problem is that client isolation was never standardized, so each vendor implements a partial version. The talk ships a tool, AirSnitch, to test your own network, and the full result is an NDSS 2026 paper.
Post 03 of my Black Hat Asia 2026 series. Analysis-first: the mechanisms and the defenses, not a build-your-own-MitM guide. The AirSnitch tool and the NDSS paper carry the operational detail.
1. What client isolation is, and why it matters
Client isolation (also called AP isolation, peer-to-peer blocking, or Layer-2 isolation) is the setting that stops clients on the same Wi-Fi network from talking to each other. It is what should make a hotel or airport Wi-Fi safe to join: your laptop can reach the internet, but the stranger two seats over cannot reach your laptop.
A fair objection is: with TLS and HTTPS everywhere, why care about local isolation at all? The talk gives concrete answers:
- Not everything is behind TLS. IoT devices, printers, network-attached storage, and old internal servers frequently expose unauthenticated services on the local network. Isolation is the only thing standing between them and a malicious peer.
- This is a real, observed attack. The team cites Volexity's documented "Nearest Neighbor" attack, in which a Russian APT compromised a nearby organization's Wi-Fi to pivot into the target over the air.
- Even encrypted traffic leaks. An on-path attacker can fingerprint HTTPS by packet lengths and timing to infer which pages a victim visits, so a MitM position has value even without breaking TLS.
A crucial historical point frames the whole talk: client isolation is not part of the IEEE 802.11 standard. It began around 2010 as a small Linux kernel option (ap_isolate) whose original purpose was saving airtime by not forwarding every broadcast between clients, not security. Vendors later repurposed that airtime optimization as a security feature, each in their own way, with no shared specification and therefore no shared guarantees.
2. The threat model and the three kinds of isolation
The adversary is a malicious insider: someone with legitimate access to the network, for example a guest-network user, who wants to attack another user. Because Wi-Fi networks are internally complex (several basic service sets, multiple radios for 2.4 and 5 GHz, internal switches), the adversary can sit in the same BSS as the victim, a different BSS on the same SSID, or even a different SSID entirely, such as guest attacking staff. Isolation is supposed to hold in all three cases:
| Isolation type | Should block |
|---|---|
| Intra-BSS | Two clients on the same access point / BSS |
| Inter-BSS | Clients on different APs but the same SSID |
| Between SSIDs | Clients on different SSIDs, e.g. guest vs. staff |
Vanhoef's thesis in one line: you must enforce isolation at every layer, because the attacker gets to choose the layer. A defense that filters Ethernet frames does nothing about IP routing; a defense that filters IP does nothing about the shared radio key.
3. Attack #1 — abusing the shared group key (Wi-Fi layer, inject)
To understand this you need one fact about Wi-Fi key hierarchy. After a client authenticates and runs the 4-way handshake, it holds two kinds of key: a pairwise session key unique to that client (used for its unicast traffic), and a group key (GTK) that is shared by every client on the BSS and used to encrypt broadcast and multicast frames so all clients can decrypt them.
That shared group key is the flaw. Since every insider legitimately holds it, an attacker can craft a broadcast Wi-Fi frame, encrypted with the group key everyone has, that carries a unicast IP packet aimed at the victim. The AP and other clients accept it because it is validly encrypted, and the victim's stack processes the inner IP packet as if it came from the network. Client isolation, which filters normal client-to-client frames, never sees a client-to-client frame: it sees a broadcast.
The talk also shows this reaches into Passpoint / Hotspot 2.0, the spec for secure public hotspots. Passpoint recommends randomizing the group key, but only mandates it for one handshake, leaving the GTK shared in others and forgetting the Integrity Group key (IGTK) entirely, which re-enables the attack.
4. Attack #2 — gateway bouncing (IP layer, inject)
The second bypass is elegantly simple and follows from a single realization: many vendors only enforce isolation at the Wi-Fi / Ethernet layer, so isolation can be bypassed one layer up, at IP.
A normal client-to-client frame puts the victim's MAC address in the Ethernet destination field. That is exactly what isolation filters block. But the router is not a client, and clients are always allowed to talk to the router. So the attacker sends the frame with the router's MAC as the Ethernet destination, while the inner IP packet is addressed to the victim's IP. The switch and NIC happily pass it, because at layer 2 it is going to the gateway. The router then does its normal job, routes the packet at the IP layer, and re-emits it toward the victim. The router has "bounced" the packet around the isolation boundary.
Fig. 1 — The isolation filter only checks the layer-2 destination. Addressing the frame to the router (allowed) and the IP packet to the victim lets the router deliver what isolation would have dropped.
5. Attack #3 — port stealing (Ethernet layer, intercept)
The first two attacks inject. To reach full MitM you also need to intercept, and that comes from reviving a classic wired-switch attack inside Wi-Fi. Internally, a Wi-Fi network uses Ethernet switches with a switching table that learns which MAC address lives on which port by watching source addresses go by. It is self-learning and trusts whatever it sees.
So the attacker spoofs another device's MAC address as their own source, and the switch "re-learns" that the victim's MAC is now on the attacker's port. Two variants:
- Steal downlink (traffic heading to the victim): spoof the victim's MAC. The switch redirects incoming packets for the victim to the attacker. To avoid kicking the real victim off the network, the attacker connects from a different BSS. This works even under WPA1/2/3, because it is a switching-table trick, not a crypto break.
- Steal uplink (traffic from the victim to the internet): spoof the router's MAC. The victim's outbound packets get delivered to the attacker instead of the gateway. Most networks don't warn about duplicate MAC addresses, so nothing alerts.
6. Composing them into full man-in-the-middle
Individually: two injects and one intercept. Combining them into a working MitM is not automatic, because a naive intercept breaks forwarding. The talk is candid about the two problems and how they're solved.
| Step | Problem | Fix in the talk |
|---|---|---|
| Uplink MitM | After stealing the router's MAC, the attacker can't forward the victim's packet on to its real destination, the switch sends it back to the attacker | Server-triggered port restoration: elicit ping replies from the network so the switch briefly relearns the router's real port, opening a window to forward |
| Downlink MitM | After stealing the victim's MAC, the attacker can't use gateway bouncing to forward a frame back to the victim, it loops back | Client-triggered port restoration: make the victim send ping replies (by injecting ping requests to it via the shared group key from Attack #1) so the switch relearns the victim's real port |
Notice how the pieces interlock: the group-key injection of Attack #1 is what makes the victim emit the traffic that restores the port for the downlink path. The three techniques are not independent tricks; they compose into a self-sustaining MitM in both directions, with port restoration run continuously to keep forwarding alive.
7. How bad it is in practice
The team built AirSnitch (an extension of their earlier MacStealer tool) and tested with client isolation explicitly enabled:
- 7 home routers and 4 professional APs, each with a guest and main network configured. All were vulnerable to at least one attack.
- No AP randomized the group key, so Attack #1 worked everywhere.
- Gateway bouncing between main and guest was inconsistent across vendors, evidence that behavior is ad hoc and unstandardized.
- In roughly half of cases, a guest could intercept a main-network user's traffic via port stealing.
- Two universities: at one, the researchers could inject packets from guest into staff; at the other, port stealing let them intercept staff-network packets, which leaked onto the open guest network.
The "all vulnerable" result is the headline, but the "no AP randomized the group key" line is the most actionable: a defense the Passpoint spec already recommends is simply not being implemented.
8. Disclosure and the standardization gap
The talk's disclosure section is a small case study in why cross-layer bugs are hard to fix. Vendors deflected along predictable lines: "we only cover layers 1 and 2," "it's a protocol issue, ask the Wi-Fi Alliance," and "it's a configuration issue [so it's the user's fault]." Because isolation was never standardized, no single party owns the whole guarantee, so each can point elsewhere. Some concrete progress did follow:
- Apple patched the acceptance of unicast IP inside group-addressed Wi-Fi frames (CVE-2026-20671), the client-side half of Attack #1's defense.
- LANCOM is adding a setting to randomize group keys.
- Ubiquiti updated its documentation to state plainly that guest-network users are not isolated from one another, honesty as a mitigation.
- The Wi-Fi Alliance is reportedly working on a standardized "WPA3 Client Isolation," which is the real fix: a specification with actual guarantees.
9. How to actually isolate clients
For network operators:
- Don't trust the "client isolation" checkbox alone. It is a per-vendor, per-layer partial control. Treat it as one layer of defense, not the defense.
- Use VLANs for real separation, and where the threat justifies it, a unique VLAN per user. This is the one mechanism that actually segments traffic below IP.
- Enforce firewall rules at both Ethernet and IP layers, so gateway bouncing has nothing to bounce through, and enable IP spoofing prevention.
- Enable randomized group keys where the AP supports it, combined with a Proxy ARP service to keep connectivity working, this neutralizes the group-key injection.
- Test, don't assume. Run AirSnitch against your own guest and main networks with isolation on. "All tested networks were vulnerable" means yours probably is until you verify.
For client/AP vendors:
- Clients should drop unicast IP packets carried in broadcast Wi-Fi frames (Apple's CVE-2026-20671 fix). It closes the interception half of the group-key attack, though broadcast-IP injection can remain.
- APs should randomize the group key per client, which effectively disables the shared-key injection surface by removing the shared secret an attacker relies on.
- Warn on duplicate MAC addresses, which removes the silent-success property that makes port stealing so clean.
Does WPA3 stop these attacks?
Not by itself. Port stealing works under WPA1/2/3 because it manipulates the Ethernet switching table, not the crypto. The group-key attack depends on the shared GTK, which WPA3 still uses for broadcast/multicast. A standardized "WPA3 Client Isolation" is being worked on, but the WPA3 you have today does not close these seams.
Is my home guest network affected?
Every home router the team tested (with isolation on) was vulnerable to at least one attack, and none randomized the group key. For a home network the practical mitigation is to keep untrusted/IoT devices on a separate VLAN or a physically separate AP, and not to rely on the guest-isolation toggle for security.
Why does removing a user not fix it?
Because the group key rarely rotates. An insider who learned the current GTK can keep injecting frames long after their account is disabled, until the key is changed. Forcing a group-key rotation on deprovisioning would help.
Is this a software bug or a configuration bug?
Both, which is the point. Some cases are implementation flaws (accepting unicast IP in broadcast frames); others are configuration gaps (isolation enforced at only one layer, no VLANs). Because isolation was never standardized, the line between "bug" and "misconfiguration" is blurry, which is why fixes need standardization, not just patches.
Takeaways
- Wi-Fi client isolation was never standardized, it grew out of a 2010 airtime optimization, so every vendor's version has different, partial guarantees.
- Three cross-layer bypasses: group-key injection (Wi-Fi), gateway bouncing (IP), port stealing (Ethernet), each defeating a per-layer isolation check.
- They compose into full two-way MitM, using group-key injection to trigger the port restoration that keeps forwarding alive.
- Every tested router, AP, and university network had at least one flaw, and no AP randomized the group key.
- The real fix is VLAN-based segmentation plus cross-layer firewalling, not the isolation checkbox. Randomize group keys and warn on duplicate MACs.
- A standardized WPA3 Client Isolation is the durable answer; until then, test with AirSnitch and assume the toggle is insufficient.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- NDSS 2026 — the peer-reviewed AirSnitch paper with full methodology and the IGTK/Passpoint details.
- Volexity — The Nearest Neighbor Attack — real-world Wi-Fi insider pivot cited in the talk.
- Mathy Vanhoef — research page — background on KRACK, FragAttacks, and MacStealer, the lineage AirSnitch extends.
- Hole-196 (Black Hat USA 2010) — the original group-key abuse this work generalizes.