Wi-Fi Attacks From WEP to FragAttacks: A Defender's History

Wi-Fi security has broken in a repeating pattern: WEP fell to RC4 key scheduling weaknesses published in 2001, TKIP and the WPS PIN fell to design shortcuts, WPA2 fell to key reinstallation (KRACK, 2017), early WPA3 leaked passwords through side channels (Dragonblood, 2019), and FragAttacks (2021) showed that frame aggregation and fragmentation had been exploitable since 1997. Almost every fix was a software update, not new hardware.

For a defender, that history turns into a short list of actions. Run WPA3 with Protected Management Frames (PMF), or WPA3 transition mode only while old clients still need it. Turn WPS off. Patch access points and clients on both sides of the link. Validate the server certificate on 802.1X. Treat the wireless stack (hostapd, wpa_supplicant, drivers and firmware) as software you patch on a schedule. This post goes one level deeper than our KRACK explainer and our guide to how attackers intercept traffic, with every date checked against the original paper, CERT/CC, the Wi-Fi Alliance or the hostapd advisories listed under Sources.

Key takeaways

• WEP failed by design. Fluhrer, Mantin and Shamir showed RC4 is "completely insecure" in WEP's mode of use, where a fixed key is joined to a known per-packet IV. By 2007 a 104-bit WEP key could be recovered from under 40,000 frames in half of all attempts, collected in under a minute.
• TKIP was a firmware patch for WEP hardware. It added per-packet key mixing, the Michael integrity check and a sequence counter. In 2008 Beck and Tews showed a practical attack that decrypts a short packet in about 12 to 15 minutes and injects a handful of forged ones. WPA3 networks disallow it.
• The WPS PIN collapses to 11,000 guesses. CERT/CC (VU#723755, 27 December 2011) explains that the protocol tells an attacker when the first half of the 8-digit PIN is right and that the last digit is a checksum. The only reliable fix is to turn WPS off.
• KRACK broke WPA2 without breaking its cryptography. Replaying handshake message 3 made clients reinstall an in-use key and reset nonces, so encryption reused keystream. It was fixed by software updates on clients and access points, published on 16 October 2017.
• Dragonblood hit WPA3 before it shipped widely. Transition mode downgrades, group downgrades, timing and cache side channels in the SAE (Dragonfly) handshake, and a denial of service from as few as 16 forged commit frames per second. The longer term fix is the hash-to-element password derivation.
• FragAttacks hit every generation. Three design flaws in aggregation and fragmentation plus a set of implementation bugs; the researcher found every tested product had at least one. Disclosure on 11 May 2021 followed a 9-month coordinated effort.
• Rogue access points are a credential problem. Anyone who knows a shared WPA2 or WPA3-Personal password can stand up a convincing clone. 802.1X with strict server certificate checks is the control that actually authenticates the network.
• The fixes keep needing fixes. hostapd published an advisory on 31 July 2024 for incomplete downgrade protection in SAE hash-to-element, and five more advisories in 2026. Wireless code is ordinary software with an ordinary patch cycle.

A dated timeline of Wi-Fi attacks and fixes

Dates come from the papers themselves, CERT/CC, the Wi-Fi Alliance, IETF RFCs and the hostapd security advisory pages listed under Sources. Where a primary source gives only a month or year, the table does too.

The attacks side by side

This is the table to keep. It separates design flaws (in the standard, so every correct implementation is affected) from implementation flaws (in specific code), because the two need different responses.

Why did WEP fail?

WEP (Wired Equivalent Privacy) used the RC4 stream cipher. A stream cipher turns a key into a long pseudorandom keystream, and encryption is a simple XOR of keystream and plaintext. That design has one hard rule: never encrypt two messages under the same keystream, because XORing the two ciphertexts cancels the keystream and leaves the XOR of the two plaintexts.

To get a fresh keystream per packet, WEP prepended a 24-bit initialisation vector (IV) to a long-lived shared key and fed the result to RC4. The IV travelled in the clear in every frame. That gives an attacker two things for free: the first three bytes of every per-packet RC4 key, and a way to sort frames by IV.

The 2001 Fluhrer, Mantin and Shamir paper, in concept

The paper studied RC4's key scheduling algorithm (KSA), the step that turns a key into RC4's initial internal state. The authors found large classes of weak keys in which a few key bits determine many state and output bits with useful probability. They then showed that WEP's mode of operation, "a fixed secret key is concatenated with known IV modifiers," makes RC4 completely insecure: some IV values put the cipher into a state where the first output byte leaks information about one byte of the secret key. Collect enough frames with those IVs, combine the statistical hints, and the secret key falls out one byte at a time. The paper describes the attack as passive and ciphertext-only, with work that grows only linearly with key length. A longer key did not help.

The defender's lesson is subtle. RC4's design was not the whole problem; the way WEP derived per-packet keys from a fixed key and a visible counter was. The same cipher fed through a proper key derivation function would have failed far more slowly.

Worked example: how small is a 24-bit IV space?

A 24-bit IV allows 2 to the power 24, or 16,777,216, distinct values. That sounds large until you count frames. An access point sending 1,000 frames per second would cycle through every possible IV in about 16,777 seconds, roughly 4.7 hours, and on a busy network, because of the birthday effect, repeats start far sooner when IVs are chosen at random. Every repeat with the same shared key is a keystream reuse. WEP had no mechanism to rekey automatically, so a key could stay in service for months.

Worked example: from FMS to PTW

The 2007 paper by Tews, Weinmann and Pyshkin, "Breaking 104 bit WEP in less than 60 seconds," recovered a 104-bit WEP key using fewer than 40,000 frames in 50 percent of cases, with randomly chosen IVs. The computing cost was about 2 to the power 20 RC4 key setups, which the authors called negligible on a desktop CPU. On an 802.11g network the frames could be gathered by re-injection in under a minute. Put those numbers next to the 4.7 hours above: the attacker no longer needed to wait for IVs to repeat at all.

Integrity was broken too

WEP appended a CRC-32 checksum, the ICV, to each packet before encryption, as the 2008 Beck and Tews paper describes. CRC-32 is linear: flipping bits in the message flips predictable bits in the checksum. Because the checksum was encrypted with the same XOR keystream, an attacker could flip bits in a ciphertext and fix up the checksum without knowing the key. WEP therefore failed at confidentiality, integrity and key management at the same time. Beck and Tews also note WEP made every client and access point share up to four static keys, which is clearly a poor fit for networks where users come and go.

Lesson for defenders. There is no safe WEP configuration. If a device can only do WEP, it belongs on an isolated network with no route to anything that matters, or in recycling.

What did WPA and TKIP fix, and why were they deprecated?

WPA, with the Temporal Key Integrity Protocol (TKIP), was the stopgap that let existing WEP hardware be upgraded by firmware. Beck and Tews summarise its design: TKIP keeps RC4 but uses a more sophisticated key mixing function so that every packet gets a different RC4 key, adds a 64-bit message integrity check named Michael to stop the CRC-32 tricks, and adds a sequence counter (TSC) to block simple replays. If more than two Michael failures occur within 60 seconds, the countermeasures shut communication down and renegotiate all keys after a 60 second penalty period.

That was a large step forward. It was also boxed in by the hardware it had to run on: RC4 had to stay, and Michael had to be cheap enough for old chips, which meant it was not designed to be cryptographically strong.

The 2008 Beck and Tews attack, in concept

Published on 8 November 2008, the paper described what the authors called the first practical attack on WPA beyond dictionary attacks on weak passphrases. It worked against networks using TKIP with quality of service (QoS) enabled. Conceptually, the attacker takes a short packet whose content is mostly predictable, such as an ARP request, and guesses its unknown bytes one at a time, using the network's own reaction to integrity failures as the signal. QoS gives several traffic channels with separate sequence counters, so a replay that would be rejected on one channel can be accepted on a quieter one. Waiting at least 60 seconds between failures avoids triggering the shutdown countermeasure.

The paper reports that an attacker with about 12 to 15 minutes of access could decrypt an ARP request or response and then send 7 packets with chosen content. Because Michael is reversible once a packet's plaintext and MIC are known, the attacker also recovers the Michael key for one direction of traffic.

Why TKIP was retired

The Beck and Tews result did not reveal passwords or decrypt bulk traffic, but it proved TKIP's integrity layer could be defeated in practice, and later attacks built on the same ideas. KRACK made the point sharper in 2017: its authors explain that with TKIP, nonce reuse lets an attacker forge and inject packets, not just decrypt them. The successor, CCMP (AES in counter mode with CBC-MAC), shipped with WPA2 and does not share TKIP's RC4 heritage.

Today the Wi-Fi Alliance says WPA3 networks "disallow outdated legacy protocols." The hostapd configuration reference describes the Transition Disable indication as telling clients to stop using WEP, TKIP (including as the group cipher) and connections without PMF. In practice, "WPA2 with TKIP" or "WPA/WPA2 mixed" in a router menu is a setting to remove, not a compatibility feature to keep.

Why is WPS weak, and why should it be off?

Wi-Fi Protected Setup (WPS) was a Wi-Fi Alliance certification program meant to make it easy for home users to join devices to a protected network. Viehböck's 26 December 2011 paper quotes the Alliance's own description of the program as launched in January 2007 and notes that WPS was turned on by default on every device he had access to.

WPS has several methods. The weak one is the external registrar PIN method, where a device proves it knows the access point's 8-digit PIN and in return receives the network credentials.

The design flaw, in concept

CERT/CC's VU#723755, published 27 December 2011, explains it in two parts. First, when PIN authentication fails, the access point sends an EAP-NACK in a way that tells the attacker whether the first half of the PIN was correct. Second, the last digit of the PIN is a checksum of the others. So the attacker does not search one 8-digit space; they search a 4-digit space and then a 3-digit space.

Worked example: from 100 million to 11,000

That is roughly a 9,000-fold reduction. CERT/CC adds that many routers had no lockout after failed attempts, and that some crashed under the brute force and needed a reboot. Once the PIN is found, the attacker can retrieve the network password, change the access point's configuration or cause a denial of service. Changing the Wi-Fi password does not help, because the PIN hands out whatever the current password is.

The fix

At the time, CERT/CC said it was unaware of a practical solution and recommended disabling WPS, specifically the external registrar or router PIN feature. That advice has aged well. In hostapd, wps_state defaults to 0, which means WPS disabled, and you have to turn it on deliberately. On consumer routers, check both the WPS toggle and any separate "PIN" option, and confirm after firmware updates that WPS has not come back on.

Lesson for defenders. A convenience feature that skips the password is a second password, usually a weaker one. Inventory every way a device can join the network, not just the one in the setup guide.

KRACK (2017): how did key reinstallation break WPA2?

KRACK, short for key reinstallation attacks, was disclosed on 16 October 2017 by Mathy Vanhoef of KU Leuven. The researcher's site is blunt that the weaknesses were in the Wi-Fi standard itself, so any correct implementation of WPA2 was likely affected, across personal and enterprise networks and including networks that used only AES. CERT/CC tracked it as VU#228519 with ten CVEs, CVE-2017-13077 to CVE-2017-13082, CVE-2017-13084 and CVE-2017-13086 to CVE-2017-13088.

The mechanism, in concept

When a client joins a WPA2 network, it runs the 4-way handshake to confirm both sides know the credentials and to derive a fresh session key. The client installs that key when it receives message 3 of the handshake. Because radio frames get lost, the access point retransmits message 3 if it does not hear back, so a client can legitimately receive message 3 more than once.

The flaw was what happened on the second copy. Each time the client processed message 3, it reinstalled the same key and reset the associated counters: the transmit packet number (the nonce) and the receive replay counter. An attacker in a man in the middle position on the channel could hold back and replay message 3 to force those resets. With the nonce reset, the encryption protocol reuses keystream, exactly the WEP mistake in a new form. The hostapd advisory describes the two outcomes: on the receive side, replay protection is broken; on the transmit side, nonce reuse makes it significantly easier to decrypt frames and, for TKIP, to recover parts of the keys.

The impact varied by cipher and platform. With AES-CCMP the attacker could decrypt and replay; with TKIP or GCMP they could also forge. The researcher singled out Linux and Android 6.0 or later, where a remark in the standard about clearing the key from memory led the client to install an all-zero key instead of reinstalling the real one, which made decryption trivial. The same technique applied to the group key handshake, PeerKey, TDLS and the fast BSS transition (802.11r) handshake.

Why did security proofs miss it?

The 4-way handshake and CCMP had both been formally proven secure. The KRACK paper explains that the proofs established that the negotiated key stays secret, but did not model when and how often the key is installed. Both properties held; the gap was the state machine around them.

How the patches fixed it

The fix was a software update, as the Wi-Fi Alliance noted when it added KRACK testing to its certification program in October 2017: a key should be installed once, and retransmitted handshake messages must not reset nonces or replay counters for a key already in use. The updates did not change interoperability.

Two practical details matter for defenders:

1. Patch both ends. The researcher's guidance was that patching the access point does not protect vulnerable clients, and patching clients does not protect a vulnerable access point. On the access point side, the researcher noted that only access points supporting the fast BSS transition (802.11r) handshake could be vulnerable.
2. An access point side workaround exists for clients you cannot patch. hostapd's wpa_disable_eapol_key_retries=1 stops retransmitting EAPOL-Key messages so the attacker cannot replay a delayed one into a station. The configuration reference warns this can make key negotiation less reliable under heavy load, and it is off by default.

The researcher also answered the most common bad instinct directly: do not fall back to WEP while waiting for patches. Keep WPA2 and update.

Lesson for defenders. KRACK is the clearest case for treating wireless stacks as software with a patch cycle. The protocol was broken everywhere at once, the fix was code, and the devices that stayed vulnerable were the ones nobody updated.

Dragonblood (2019): what went wrong in early WPA3 SAE?

The Wi-Fi Alliance introduced WPA3 on 25 June 2018. Its press release describes WPA3 networks as using the latest security methods, disallowing outdated legacy protocols and requiring PMF. WPA3-Personal replaced the WPA2 pre-shared key exchange with Simultaneous Authentication of Equals (SAE), the Wi-Fi name for the Dragonfly password-authenticated key exchange documented in RFC 7664 (November 2015). The promise was that capturing a handshake no longer lets an attacker test password guesses offline.

In April 2019, Mathy Vanhoef and Eyal Ronen published Dragonblood. The hostapd advisory 2019-1 is dated 10 April 2019, and the Wi-Fi Alliance said the issues affected "a limited number of early implementations of WPA3-Personal." The full paper was presented at the IEEE Symposium on Security and Privacy in 2020.

The five problems, in concept

The Dragonblood site groups them into downgrade attacks and weaknesses in SAE itself:

1. Downgrade against WPA3 transition mode. Transition mode lets WPA2-only and WPA3 clients share one network and one password. An attacker can set up a rogue WPA2-only network with the same name and push WPA3-capable clients onto it. The partial WPA2 handshake captured that way supports ordinary offline password guessing. No man in the middle position is needed.
2. Security group downgrade. In SAE, the client proposes an elliptic curve or finite field group and the access point can decline it. A forged decline pushes the client to a weaker group both sides happen to support.
3. Timing side channel. With NIST elliptic curves, which every WPA3 device must support, the response time leaked nothing. With Brainpool curves or MODP groups, how long the access point took to answer a commit frame depended on the password, which turns timing into a dictionary attack.
4. Cache side channel. If an attacker can observe memory access patterns on the victim's device while it builds a commit frame, for example from another app, those patterns leak information about the password. The researchers judged this a flaw in the specification, because it gave no guidance on preventing such leaks.
5. Denial of service. SAE commit processing is computationally expensive, especially with side channel defences in place. The site reports that as few as 16 forged commit frames per second could overload an access point, because the anti-clogging cookie was easy to bypass.

The researchers estimated that the side channel leaks were enough to brute force the largest known password dictionaries for about 1 US dollar of cloud computing. They also found authentication bypasses in EAP-pwd implementations, which use the same Dragonfly handshake in some enterprise networks.

Round two: the first fixes leaked too

In August 2019 the researchers reported that the Wi-Fi Alliance's private recommendations, which said Brainpool curves were safe if the quadratic residue test was implemented without leaks, still left a second leak. The password encoding loop, called hunting and pecking, searches for a hash output smaller than the curve's prime. With NIST curves it almost always succeeds first time; with Brainpool curves it often takes several iterations, and the number of iterations depends on the password and the client's MAC address. That became CVE-2019-13377. The researchers confirmed it against the then-current hostapd and noted that one vendor's Wi-Fi firmware ran only a fixed minimum of 8 iterations, which made attacks harder but did not prevent them.

Hash-to-element and the other fixes

The hostapd project responded in several layers. Advisory 2019-1 recommended updating to version 2.8 or newer. The 2019-6 patch set switched comparisons to constant time functions and added a patch titled "dragonfly: Disable use of groups using Brainpool curves." The Dragonblood researchers reported that, as a result of their work, both the Wi-Fi standard and EAP-pwd were being updated with a more secure password derivation that prevents most of the attacks but is not backward compatible with the first WPA3 deployments.

That derivation is hash-to-element (H2E). Instead of looping until a hash lands on the curve, which leaks timing, it maps the password to a curve point in a fixed number of steps. In hostapd it is controlled by sae_pwe: 0 means hunting and pecking only, 1 means hash-to-element only, and 2 enables both. The configuration reference notes the default is expected to move from 0 to 2 once H2E gets more interoperability testing, and that H2E is always used with SAE password identifiers.

H2E did not end the story. hostapd advisory 2024-2, published 31 July 2024, describes incomplete downgrade protection for group negotiation in the H2E rejected groups logic of hostapd and wpa_supplicant 2.10. It required H2E plus more than one SAE group, and hostapd enables only group 19 by default, while wpa_supplicant enables 19, 20 and 21. The fix is version 2.11 or two backported commits.

The Wi-Fi Alliance also added certification testing, and its April 2019 update pointed implementers to its WPA3 security considerations guidance.

Lesson for defenders. Backward compatibility is where WPA3 was weakest. Transition mode is a migration tool with an end date, and the Transition Disable indication exists so you can enforce that end date once your clients are ready.

FragAttacks (2021): how did fragmentation and aggregation break every generation?

FragAttacks, short for fragmentation and aggregation attacks, was disclosed on 11 May 2021 by Mathy Vanhoef, then at New York University Abu Dhabi. The Wi-Fi Alliance's statement the same day lists 12 CVEs and thanks the researcher and ICASI, which coordinated the industry response. The research site says security updates were prepared during a 9-month coordinated disclosure.

The headline finding is uncomfortable: three of the flaws are in the standard and some of them have existed since Wi-Fi's release in 1997, so even WEP is affected. Experiments indicated every Wi-Fi product had at least one of the vulnerabilities, and most had several.

Two features that were rarely studied

• Aggregation (A-MSDU) bundles several small frames into one larger frame to raise throughput. A flag in the frame header says whether the encrypted payload holds one frame or several.
• Fragmentation splits one large frame into fragments to improve reliability on a noisy channel. The receiver reassembles them.

The three design flaws, in concept

The researcher explains why the aggregation defence was never adopted: it was likely only considered a theoretical vulnerability when it was designed.

The implementation flaws were the bigger risk

The design flaws are hard to abuse, because they need user interaction or uncommon settings. The research site says that in practice the larger concern was the programming mistakes, several of which were trivial to exploit. The plaintext injection bugs include devices that accept unencrypted data frames on a protected network (CVE-2020-26140), accept plaintext fragments (CVE-2020-26143), accept plaintext broadcast fragments as full frames (CVE-2020-26145), or accept plaintext aggregated frames that start like a handshake message (CVE-2020-26144). Others include an access point forwarding EAPOL frames from a client that has not authenticated yet (CVE-2020-26139) and reassembling fragments with non-consecutive packet numbers (CVE-2020-26146).

The research site reports that two of four tested home routers accepted plaintext frames on a protected network. Against a router, injection can bypass the NAT and firewall to reach devices inside; the demonstration took over an outdated desktop machine and switched a smart plug. That is why the researcher considered the biggest practical risk to be attacks on rarely updated smart home and IoT devices, for which Wi-Fi security is the last line of defence.

How it was fixed and what to do if a device cannot be patched

The Wi-Fi Alliance said the issues are mitigated through routine device updates and that it added certification testing. For devices still unpatched, the research site's advice is to make sure the websites and apps you use run over HTTPS, which stops data exfiltration, and to keep every device on the network updated, which is the only real defence against the NAT bypass. Some IoT devices never get updates; those belong on a separate network segment.

Lesson for defenders. FragAttacks shows why "every Wi-Fi product had at least one" is not a reason to despair but a reason to inventory. The design flaws were rarely exploitable; the implementation flaws were fixed by ordinary updates, and the devices left exposed were the ones nobody knew to update.

Evil twin and rogue access points: what do WPA3 and 802.1X stop?

An evil twin is an access point that copies a legitimate network's name (SSID) so clients connect to it instead. A rogue access point is any unauthorised access point on your premises or network, often plugged in by an employee for convenience. NIST SP 800-153 treats both as monitoring problems and recommends a wireless intrusion detection and prevention system (WIDPS) with sensors that watch the bands and channels in use.

What the protocols stop depends on how the network authenticates.

Why 802.1X is only as good as the client's certificate check

With 802.1X, the client and an authentication server run an EAP method inside a TLS tunnel. If the client does not check who is on the other end of that tunnel, a cloned network can terminate the tunnel itself and collect whatever the client sends inside. The wpa_supplicant configuration reference shows the two settings that matter: ca_cert, the CA that must have issued the server certificate, and domain_suffix_match or domain_match, which pin the server's name in its certificate. A public CA alone is not enough, because anyone can obtain a certificate from one; the name constraint is what ties the certificate to your server. Our 802.1X and EAP explainer covers the EAP methods in more depth.

What PMF and beacon protection add

The Wi-Fi Alliance describes Protected Management Frames as protecting unicast management action frames against eavesdropping and forgery and multicast ones against forgery. In practice PMF stops an outsider from forging the deauthentication frames that used to knock clients off a real network and onto a clone. PMF is required for WPA3 and for all new certified devices.

Beacon protection extends integrity checks to beacon frames. In hostapd it is beacon_prot=1 and depends on PMF being enabled. The 2024 SSID Confusion paper by Héloïse Gollier and Mathy Vanhoef (CVE-2023-52424) found that, because of a design flaw in 802.11, the SSID is not always authenticated, so a client can be tricked into joining a different protected network that shares credentials, while its interface shows the intended name. Every device they tested was vulnerable. Their proposed defences include a modified form of beacon protection and avoiding credential reuse across SSIDs, and they note that from Wi-Fi 7 (802.11be), access points must support beacon protection. Our Wi-Fi 7 MLO security post covers the Wi-Fi 7 side.

What none of this stops

No Wi-Fi setting stops a user from joining an open network with the same name as your guest network in a café, and no Wi-Fi setting protects traffic once it leaves the access point. The defences above narrow the window; HTTPS, VPNs with proper certificate checks and endpoint updates cover what remains. The researchers behind KRACK and FragAttacks both pointed to HTTPS as a mitigation while patches rolled out.

How do you audit your own network?

This walkthrough covers firmware levels, WPA3 transition mode, PMF and WPS. It uses read-only commands; nothing here changes a device until you edit a configuration file and restart a service, and those steps are marked. Run scans only against networks you own or are authorised to test.

Step 1: inventory every access point and client class

List each access point, controller and router with its model, firmware version and the date of its last update. Do the same for client classes: laptops, phones, printers, cameras, IoT devices. The goal is to know which devices could still be carrying the KRACK, Dragonblood or FragAttacks bugs. For a Linux based access point or client, the versions of the wireless daemons are a good first signal:

# Versions of the user space wireless stack (Linux)
hostapd -v
wpa_supplicant -v
uname -r          # kernel, which carries mac80211 and most drivers

Compare against the hostapd and wpa_supplicant advisories: 2.8 or later for the first Dragonblood fixes, 2.11 or later for advisory 2024-2, and check the 2026 advisories on w1.fi for the current list.

Step 2: see what your network actually advertises

From a Linux laptop, scan and read the RSN element for your SSID:

# Requires root for an active scan; replace wlan0 with your interface
sudo iw dev wlan0 scan | less
# In the output, find your SSID and read the "RSN:" block:
#   Group cipher, Pairwise ciphers  -> want CCMP (or GCMP), never TKIP
#   Authentication suites           -> SAE for WPA3, PSK for WPA2, both for transition mode
#   Capabilities                    -> MFP-capable or MFP-required

A quicker summary with NetworkManager:

nmcli -f SSID,BSSID,CHAN,SECURITY dev wifi list

On Windows, netsh wlan show networks mode=bssid lists the authentication and cipher for each nearby access point, and netsh wlan show interfaces shows what the current connection negotiated. On macOS, system_profiler SPAirPortDataType reports the security mode of the current network.

What to look for:

Step 3: turn WPS off

In a router or controller interface, disable WPS, including any separate "PIN" or "external registrar" option. On a hostapd based access point, make sure the configuration either omits wps_state (default 0) or sets it explicitly:

# hostapd.conf: WPS disabled
wps_state=0

Re-check after every firmware update, then confirm with the scan in step 2 that the access point no longer advertises WPS.

Step 4: configure WPA3 transition mode properly, then end it

Transition mode is right while you still have WPA2-only clients. Configure it so WPA3 clients always use PMF and the safer password derivation. This hostapd example uses option names from the hostapd configuration reference; back up your current file before editing, and test on one access point first.

# hostapd.conf: WPA3-Personal transition mode
wpa=2
wpa_key_mgmt=WPA-PSK SAE
rsn_pairwise=CCMP
ieee80211w=1            # PMF optional, so WPA2 clients can still join
sae_require_mfp=1       # but any client using SAE must negotiate PMF
sae_pwe=2               # allow both hunting-and-pecking and hash-to-element
beacon_prot=1           # needs PMF and driver support
ocv=1                   # operating channel validation

Once your client inventory shows every device supports WPA3, move to WPA3 only:

# hostapd.conf: WPA3-Personal only
wpa=2
wpa_key_mgmt=SAE
rsn_pairwise=CCMP
ieee80211w=2            # PMF required
sae_pwe=1               # hash-to-element only
transition_disable=0x01 # tell clients to stop using WPA2-Personal for this network

transition_disable=0x01 matters because clients remember a network's security settings. Without it, a client that once connected in transition mode may still accept a WPA2-only impostor. Leave sae_groups at its default unless you have a reason to change it; advisory 2024-2 only applied when more than one group was enabled.

Restart hostapd after editing, then repeat step 2 to confirm the new RSN element. Commercial access points expose the same choices under names like "WPA3 transition," "PMF required" and "WPA3-SAE only."

Step 5: harden 802.1X clients

For enterprise networks, check every managed client profile for a CA and a server name constraint. In wpa_supplicant terms:

network={
    ssid="corp"
    key_mgmt=WPA-EAP
    eap=PEAP
    ca_cert="/etc/ssl/certs/corp-radius-ca.pem"
    domain_suffix_match="radius.corp.example"
    ieee80211w=2
}

On managed laptops and phones, push the same constraint through your device management profiles and make sure users cannot click past a certificate warning. A profile without a server name check is the single most common 802.1X weakness.

Step 6: segment and monitor

NIST SP 800-153 recommends standardised configurations for access points and clients, logically separate WLANs for guest and internal use with no device-to-device path between them, and policies on dual-connected devices that sit on wired and wireless networks at once. Put IoT devices that cannot be patched for FragAttacks style bugs on their own segment. Use a WIDPS or your controller's rogue detection to spot unknown access points broadcasting your SSIDs.

Step 7: put the wireless stack on a patch schedule

Subscribe to your access point vendors' advisories and the hostapd advisory page. The hostapd list runs from 2014 to five entries in 2026 alone, including missing multi-link parsing validation, PMKSA cache context checks, SAE commit handling, mesh message bounds checks and RADIUS Message-Authenticator validation. If you build images that ship hostapd, wpa_supplicant or a kernel, track those as dependencies like any other.

Common mistakes

• Leaving transition mode on forever. It is a migration aid. Dragonblood showed it keeps the WPA2 offline guessing path open for any client that can be pushed onto a rogue WPA2-only clone.
• Turning off WPS in the interface but not the PIN. Some interfaces separate push-button and PIN methods. The PIN is the dangerous one.
• Patching only the access points after KRACK. Clients were the main target. Both ends need updates.
• Assuming WPA3 means rogue access points are solved. Anyone with a shared WPA3-Personal password can still impersonate the network.
• 802.1X without a server name constraint. A trusted CA list alone lets any certificate from that CA through.
• Keeping TKIP "for old devices." It weakens the group cipher for every client on the network. Put the old device on its own SSID or retire it.
• Changing sae_groups without a reason. More groups added complexity and, with H2E on version 2.10, opened a downgrade path.
• Treating "no evidence of exploitation" as "no need to patch." The Wi-Fi Alliance said that about KRACK, Dragonblood and FragAttacks, and each still needed updates on every device.
• Forgetting devices without screens. Printers, cameras, thermostats and plugs were the FragAttacks demo targets because they rarely get updates.
• Reusing one password across several SSIDs. The SSID Confusion research shows credential reuse lets a client be steered to the wrong network while showing the right name.

FAQ

Is WEP still crackable today?

Yes. The 2007 research recovered a 104-bit WEP key from under 40,000 frames in half of attempts, gathered in under a minute on an 802.11g network. There is no WEP setting that changes that. Replace or isolate WEP-only devices.

Is WPA2 still safe to use after KRACK?

WPA2 with AES-CCMP on patched clients and access points is still widely used, and the KRACK researcher's advice was to keep WPA2 and patch rather than fall back to anything older. WPA3 is better: it resists offline password guessing and requires PMF. Plan the move, and use transition mode as a bridge.

Should I turn off WPS on my router?

Yes. CERT/CC found that a design flaw cuts the WPS PIN search from 100 million guesses to 11,000, and that many routers lacked lockouts. Its recommended workaround was to disable WPS. Check again after firmware updates.

What is the difference between WPA3 transition mode and WPA3-only?

Transition mode advertises both WPA2-Personal (PSK) and WPA3-Personal (SAE) with the same password so old clients can still join. WPA3-only advertises SAE alone and requires PMF. Transition mode is exposed to the Dragonblood downgrade; WPA3-only is not.

Does WPA3 stop evil twin attacks?

Only partly. SAE stops an outsider who does not know the password, and PMF stops forged deauthentication frames. Anyone who knows a shared WPA3-Personal password can still run a convincing clone. WPA3-Enterprise with strict server certificate validation is what authenticates the network itself.

Was FragAttacks ever exploited in the wild?

The Wi-Fi Alliance said in May 2021 there was no evidence the vulnerabilities had been used against Wi-Fi users maliciously. The researcher considered the design flaws hard to abuse but several implementation flaws trivial to exploit, so devices without updates remain at risk.

What is hash-to-element in WPA3?

Hash-to-element (H2E) is a newer way for SAE to turn a password into an elliptic curve point in a fixed number of steps, instead of the hunting and pecking loop whose run time leaked information in Dragonblood. In hostapd it is set with sae_pwe (1 for H2E only, 2 for both methods).

What is PMF and should I turn it on?

Protected Management Frames add integrity protection, and for unicast frames confidentiality, to management action frames. It stops forged disconnection frames. WPA3 requires it, and the Wi-Fi Alliance requires it for all new certified devices. Turn it on as optional on mixed networks and required where every client supports it.

How do I check whether my Wi-Fi uses TKIP?

On Linux, run sudo iw dev wlan0 scan and read the pairwise and group cipher lines in the RSN block for your network. On Windows, netsh wlan show networks mode=bssid lists the cipher per access point. If you see TKIP anywhere, switch the access point to CCMP only.

Do I need new hardware to fix these attacks?

Usually not. KRACK, Dragonblood and FragAttacks were all fixed by software and firmware updates, according to the Wi-Fi Alliance statements for each. You need new hardware when a device only supports WEP or TKIP, or when its vendor has stopped shipping updates.

Where Safeguard fits

Safeguard does not configure access points, run a wireless IDS, scan firmware, manage devices or protect endpoints, and none of the controls in this post depend on it. The honest link is narrower. hostapd, wpa_supplicant, the Linux kernel and many drivers are open source components, and the advisory list above shows they need the same patch tracking as any library. If your team builds router images, embedded Linux or container images that include them, you can describe those components in an SBOM and scan it, or scan the repositories and images you build, with Safeguard (safeguard scan --sbom <file>, --dir . or --image <name>). Safeguard matches components against vulnerability databases, ranks findings with reachability analysis, shows which projects contain a given component and version, and evaluates your policies and gates before a build ships. It cannot see the firmware inside an access point you bought; that fix has to come from the vendor.

Every major Wi-Fi fix in this history arrived as a software update to an open source or vendor wireless stack, and the devices left exposed were the ones nobody tracked. The steps below apply to the open source components and container images you build and ship, even though they cannot reach the firmware in hardware you bought.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and coding assistant workflows, not Wi-Fi configuration or monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real CLI session: install, open the interactive terminal with safeguard, ask it to fix a lodash CVE, and watch it read the finding and advisory, ask before each command, edit package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing. The same approval flow applies if your repository builds an embedded Linux or router image and you need to move a pinned hostapd or wpa_supplicant version after an advisory like 2024-2.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. If you build access point or gateway images on a lab machine, the local runner scans those repositories and SBOMs on that machine.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask which of your projects carry a given component and version, for example a wpa_supplicant build older than 2.11, and get answers from your own Safeguard data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Fluhrer, Mantin and Shamir: Weaknesses in the Key Scheduling Algorithm of RC4 (paper PDF)
• Tews, Weinmann and Pyshkin: Breaking 104 bit WEP in less than 60 seconds (IACR ePrint 2007/120)
• Beck and Tews: Practical attacks against WEP and WPA (8 November 2008, PDF)
• Viehböck: Brute forcing Wi-Fi Protected Setup (26 December 2011, PDF)
• CERT/CC VU#723755: WiFi Protected Setup PIN brute force vulnerability
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks
• NIST SP 800-153 full text (PDF)
• IETF RFC 7664: Dragonfly Key Exchange
• IETF RFC 8110: Opportunistic Wireless Encryption
• KRACK Attacks: Breaking WPA2 by forcing nonce reuse
• Vanhoef and Piessens: Key Reinstallation Attacks, CCS 2017 (PDF)
• CERT/CC VU#228519: WPA2 key reinstallation vulnerabilities
• hostapd advisory 2017-1: WPA packet number reuse with replayed messages and key reinstallation
• Wi-Fi Alliance: Security Update October 2017
• Wi-Fi Alliance: Wi-Fi CERTIFIED WPA3 introduction, 25 June 2018
• Dragonblood: Analysing WPA3's Dragonfly Handshake
• Wi-Fi Alliance: Security Update April 2019
• hostapd advisory 2019-1: SAE side-channel attacks
• hostapd advisory 2019-6: SAE/EAP-pwd side-channel attack update (patch set)
• hostapd advisory 2024-2: SAE H2E and incomplete downgrade protection for group negotiation
• hostapd advisory 2026-2: Missing network context validation for PMKSA caching
• hostapd and wpa_supplicant security advisories index
• FragAttacks: Security flaws in all Wi-Fi devices
• Vanhoef: Fragment and Forge, USENIX Security 2021 (PDF)
• Wi-Fi Alliance: security update, 11 May 2021
• Gollier and Vanhoef: SSID Confusion, ACM WiSec 2024 (PDF)
• Wi-Fi Alliance: Security (WPA3, Enhanced Open, Protected Management Frames)
• IEEE SA: IEEE 802.11-2020
• hostapd.conf configuration reference (AOSP mirror of the hostap project file)
• wpa_supplicant.conf configuration reference (AOSP mirror of the hostap project file)

Last reviewed: 24 October 2026. Wireless advisories are still being published; check the hostapd advisory page and your vendors' notices for the current list.