New AirSnitch attack bypasses Wi-Fi encryption in homes, offices, and enterprises

It’s hard to overstate the role that Wi-Fi plays in virtually every facet of life. The organization that shepherds the wireless protocol says that more than 48 billion Wi-Fi-enabled devices have shipped since it debuted in the late 1990s. One estimate pegs the number of individual users at 6 billion, roughly 70 percent of the world’s population.

Despite the dependence and the immeasurable amount of sensitive data flowing through Wi-Fi transmissions, the history of the protocol has been littered with security landmines stemming both from the inherited confidentiality weaknesses of its networking predecessor, Ethernet (it was once possible for anyone on a network to read and modify the traffic sent to anyone else), and the ability for anyone nearby to receive the radio signals Wi-Fi relies on.

Ghost in the machine

In the early days, public Wi-Fi networks often resembled the Wild West, where ARP spoofing attacks that allowed renegade users to read other users’ traffic were common. The solution was to build cryptographic protections that prevented nearby parties—whether an authorized user on the network or someone near the AP (access point)—from reading or tampering with the traffic of any other user.

New research shows that behaviors that occur at the very lowest levels of the network stack make encryption—in any form, not just those that have been broken in the past—incapable of providing client isolation, an encryption-enabled protection promised by all router makers, that is intended to block direct communication between two or more connected clients.

The isolation can effectively be nullified through AirSnitch, the name the researchers gave to a series of attacks that capitalize on the newly discovered weaknesses. Various forms of AirSnitch work across a broad range of routers, including those from Netgear, D-Link, Ubiquiti, Cisco, and those running DD-WRT and OpenWrt.

physical accessto Wi-Fi? I mean, yes, you have to be in range of the wifi devices. But that might be having a nearby repeater device outside the premises.Keeping in mind that this IS about Wi-Fi and not ethernet, but, perhaps your confusion is because of some things the article said about ethernet. If I'm understanding correctly, the references to Ethernet are because, Wi-Fi at a low level, basically is Ethernet over radio, with a few tweaks like SSIDs, and then encryption layered on top of that.

But the very lowest level of the stack, that goes out over the radio waves, isn't encrypted and validated against known keys. So MAC address spoofing can happen, which it sounds like is the basis of this attack - that the malicious device spoofs another device, then forwards traffic as a machine-in-the-middle.

Any traffic that gets decrypted at the router, normally, like DNS, can thus be decrypted by the MITM using the MITM's provided keys, I think is what's being said here. Which is yet another argument to use encrypted DNS.

What we really need, I think, though, is a modern Wi-Fi replacement/updated version that uses strong key-based encryption/authentication at Level 1 of the network stack? Is that the right takeaway here?

Just turning on VLANs doesn't do anything. You have to segment your network. VLANs are a tool that allow you to segment your network without duplicating every switch and AP on your network for each subnet.

Wi-Fi has the same basic problem as SMTP: it has fundamental weaknesses that are extremely hard to fix without utterly shattering backward compatibility that too many things rely on. It's good enough for most things, and there are a pile of fixes to address the problem.

My first thought on this was increasing the security of the perceived reconnection. Require it to be encrypted by the last key used or signed by the last DH key negotiated. If it's not, don't let it connect and don't put it in the CAM table. Require a timeout from the last known good connection before letting it reconnect. However, this could affect devices that sleep for long periods and could set up a DoS attack by connecting with a known MAC address that one wants to block.

Edit: Original comment indicated that VLANs didn't help, I had misread the cross-BSSID attack details.

The paper is clear that the inject/MITM is cross-BSSID but not cross-VLAN (assuming the device isolates correctly).

Thanks for the feedback!

To make the MitM bidirectional the attacker needs a way to redirect the intercepted frames back to the target. To do this, the attacker restores the MAC > port mapping to the original one, i.e. the one that associated the target's MAC to the port. The attacker does this by sending a ping from a random (i.e. not the attacker's) MAC . This ping must be wrapped in the Group Temporal Key.

Then, the attacker repeats these two steps over and over, in rapid succession. Please also see the diagram that I added.

Does any of this help clarify?

The most fundamental, basic element of the attack is happening at layer one (the shared radio medium).

From the paper, that's this part:

From there, they were able to pivot to other attacks that facilitated hopping over to a protected BSSID and (for example) carrying out attacks against the RADIUS authentication.

They had to add a rogue AP and rogue RADIUS server to demonstrate an attack that pivoted from a guest SSID to a WPA2/3 enterprise SSID, but that's easy enough to build into an attack kit that it's still viable.

So what mitigations are actually viable?Well, the vendors will probably patch stuff, which will help. But there are also other important elements to consider.

Separate APsThe only perfect solution would seem to be isolating the SSIDs on different APs. Notably, however, they did demonstrate attacks against different APs sharing the same distribution network. Piecemeal won't cut it.

Separate internal/virtual bridgesAt a step short of that, the DD-WRT and Open-WRT deployments tested demonstrated resilience against several elements of the attack by isolating the different SSIDs on separate internal bridges. I expect that, or something very similar, will feature prominently in how the other vendors approach resolving many of these elements.

Rogue detectionAs a detective control, rogue AP detection would be

effective here. I'm not seeing any significant portion of the attack chain that can be carried out without a rogue AP. That's not practical for (most) home deployments, but it's a common feature in enterprise tooling.veryWPA3 Enterprise Public KeyI

WPA3 enterprise in public key mode is safe, but I'd need to go over it in more detail to say that for certain.thinkThey explicitly note that the data link attack primitives won't work there directly.

The demonstrated a pivot from an attack on guest SSID to an attack on an Enterprise SSID specifically attacked the RADIUS setup. And I can't think of a way to do the equivalent for a PubKey setup.

(edit: spelling, clarity in final paragraph)The AirSnitch MITM works best when targeting a victim on the same SSID (and likely VLAN), but separate SSIDs/VLANs may not be enough depending on how the WAP handles the traffic, and even with VLAN isolation an attacker can still drop frames into the victim VLAN, even if they can't do a full MITM.

WAPs handle VLAN tags (typically by SSID), but not the same way as a physical ethernet switch; there isn't a physical port to lock a client to. The AirSnitch bugs let an attacker stuff traffic into the "port" for a target client. The bidirectional MITM might be trickier to across SSIDs or VLANs, but its likely going to depend on the specific device behavior.

Separate from the MITM, there are other ways to abuse the injection issue. An attacker can inject a UDP request for something like NetBIOS/mDNS/SSDP/SNMP that bounces a response back to the internet, instead of to the attacker's wireless client, and be able to extract useful data this way.

Reference: https://www.ndss-symposium.org/wp-content/uploads/2026-f1282-paper.pdf, p1-2