WPA3 Denial of Service: SAE Resource Exhaustion

Exploring availability attacks against WPA3-SAE, from the early Dragonblood research to lesser-known attacks that remain highly relevant today

Introduction

WPA3 was designed to address several long-standing weaknesses in WPA2, and one of the most important changes in WPA3-Personal is the use of Simultaneous Authentication of Equals (SAE). One of SAE's major security improvements is its resistance to passive offline password cracking. With WPA2-Personal, an attacker who captures the required authentication material can test password candidates offline without interacting with the target network again. SAE changes this model: its password-authenticated key exchange does not expose equivalent reusable material for a passive offline dictionary attack, so each password guess requires interaction with the authentication protocol. This is a substantial cryptographic improvement, but stronger authentication does not automatically mean stronger availability.

In fact, SAE introduces an interesting Denial of Service (DoS) attack surface. Before an Access Point (AP) can determine whether a station is legitimate, it may already have to perform non-trivial cryptographic processing and maintain authentication state. An attacker does not necessarily need to break SAE or recover the network password. For a DoS attack, forcing the AP to perform enough work can be sufficient.

This article revisits Dragon Drain, one of the earliest publicly demonstrated resource-exhaustion attacks against WPA3-SAE, and then focus on Cookie Guzzler, together with the broader family of DoS attacks described by Efstratios Chatzoglou, Georgios Kambourakis and Constantinos Kolias in their paper How is your Wi-Fi connection today? DoS attacks on WPA3-SAE.

Dragon Drain is particularly useful historically because it shows that the DoS problem was visible during WPA3's earliest deployment phase. Cookie Guzzler is interesting for a different reason: it abuses the Anti-Clogging Mechanism that is itself intended to make SAE resistant to resource-exhaustion attacks.

Why SAE Is Interesting from a DoS Perspective

WPA3-Personal uses SAE, a password-authenticated key exchange derived from the Dragonfly family of protocols. At a high level, SAE authentication is composed of two important exchanges:

1. Commit
2. Confirm

During the Commit exchange, both peers exchange cryptographic material that includes a scalar and an element associated with the selected group. The Confirm exchange then proves that both sides derived the same shared secret.

This design provides important security properties, but it also creates an asymmetry that matters for availability: some amount of processing happens before the peer has been authenticated.

This leads to a simple but important question:

How much work can an unauthenticated station force an AP to perform?

That question is at the heart of most SAE resource-exhaustion attacks.

 

 

 

The SAE Anti-Clogging Mechanism

SAE includes an Anti-Clogging Mechanism (ACM) specifically intended to mitigate this class of problem.

When an AP determines that too many SAE exchanges are pending, it can stop immediately accepting new expensive authentication attempts and instead require the station to return an anti-clogging token. Conceptually, the token acts as a lightweight challenge that allows the AP to avoid committing excessive resources to arbitrary unauthenticated peers.

This is an important protection because a simple flood of arbitrary SAE Commit frames should otherwise allow an attacker to continuously trigger expensive operations.

However, introducing a defensive state machine does not make the DoS problem disappear. The Anti-Clogging Mechanism itself has behavior, state, validation logic, retransmission rules and resource costs. All of those become part of the attack surface.

 

 

 

Dragon Drain: The Early Warning

Dragon Drain was released as part of Mathy Vanhoef and Eyal Ronen's Dragonblood research, one of the earliest major security analyses of WPA3's SAE handshake.

The idea behind Dragon Drain is straightforward: forge SAE Commit messages so that the target AP repeatedly performs expensive SAE processing. If enough authentication work is generated, CPU usage can increase significantly and the AP may become unable to properly serve legitimate clients.

Importantly, this is not a password-recovery attack. The attacker is not trying to complete a valid SAE exchange. The objective is simply to make the victim spend resources.

Dragon Drain was discovered during the early days of WPA3, when implementations were still relatively immature and vendors were adapting their products to SAE. That historical context matters today.

In 2026, Dragon Drain should not be considered a universal WPA3 DoS technique. Most actively maintained devices have had years to receive fixes or implementation changes that prevent the original attack from working as described. In practice, modern and properly maintained equipment will very often not be vulnerable.

However, that does not make Dragon Drain irrelevant.

Wireless infrastructure has notoriously long deployment cycles. Consumer routers, embedded devices and vendor-specific Wi-Fi implementations can remain in service for many years, and not every vendor has done its homework equally well. Old firmware, abandoned products, incomplete fixes and unusual SAE implementations still make it possible to encounter devices where Dragon Drain remains effective. More importantly, practical testing in 2026 has shown that at least some currently maintained vendor equipment can still be affected even when running up-to-date 2026 firmware. This is a particularly relevant finding: in those cases, the problem cannot simply be attributed to users failing to install updates, but suggests that some vendors have still not adequately addressed a weakness disclosed during WPA3's earliest security research.

Therefore, Dragon Drain today can be seen less as a universal WPA3 attack and more as a useful indicator of implementation quality. If a current device is still vulnerable to an attack disclosed during the first wave of WPA3 research, that says something important about the maintenance of its wireless stack.

Dragon Drain in Practice and Hardware Limitations

The original Dragon Drain implementation has an additional practical limitation: it relies on the ath_masker kernel module and was implemented specifically for Atheros wireless adapters. The reason is that the attack needs the wireless card to acknowledge frames sent to spoofed MAC addresses, and the original researchers implemented that functionality for Atheros hardware.

In addition to the original Dragon Drain repository, a third-party plugin is available for the wireless auditing framework airgeddon. The plugin integrates the attack into airgeddon's workflow, making it considerably easier to launch without having to manually reproduce the setup required by the original proof of concept. It also extends the original hardware support beyond Atheros-based adapters, reducing one of the main practical limitations of the initial implementation. The adapted implementation adjusts the injection bitrate according to the detected chipset to improve reliability.

When an Atheros chipset is detected, the plugin preserves the requirements of the original approach and checks whether the ath_masker kernel module is available. If it is missing, the plugin can perform the required installation and kernel-module loading steps and then validate that the module is correctly available before proceeding. For non-Atheros adapters, the modified implementation does not depend on ath_masker.

The following screenshot shows a real Dragon Drain test launched through the airgeddon Dragon Drain plugin against a WPA3 access point. In this particular test, the target was running up-to-date vendor firmware from 2026 and was still affected by the attack, illustrating that the issue cannot always be dismissed as a consequence of outdated firmware. The wireless adapter used in this example is based on an Atheros chipset, so the screenshot also illustrates the detection and validation path described above: airgeddon identifies the chipset and verifies that ath_masker is available before launching the attack. The plugin is nevertheless no longer restricted to Atheros hardware.

 

This is a useful example of what happens when an academic PoC becomes easier to execute: hardware and implementation barriers that once limited exploitation can disappear over time.

Beyond Dragon Drain

Dragon Drain received significant attention because it appeared during the initial wave of WPA3 security research. However, it is far from the only DoS technique that has been demonstrated against SAE.

In the paper How is your Wi-Fi connection today? DoS attacks on WPA3-SAE, Chatzoglou, Kambourakis and Kolias performed a much broader empirical study of Denial of Service conditions affecting SAE. Their work used real Wi-Fi 6 equipment, including both certified and non-certified devices, as well as hostapd-based implementations.

The authors describe a set of generic attacks as well as more than a dozen vendor-dependent issues. Among the generic attacks discussed in the paper are:

- Doppelganger
- Cookie Guzzler
- PMK Gobbler
- Memory Omnivore
- Double-Decker
- Amplification
- Open Authentication abuse

The reported effects range from temporary loss of Internet connectivity to complete disconnection of associated stations.

This distinction is important. Some failures come from vendor-specific implementation bugs and may be relatively straightforward to patch. Others arise from assumptions, state handling or resource-management behavior around SAE itself and require more careful changes.

Cookie Guzzler

Cookie Guzzler is one of the most interesting attacks in the paper because it targets the SAE Anti-Clogging Mechanism itself.

The attack is described in two variants:

1. Muted Peer
2. Hasty Peer

Both variants take advantage of the way the AP handles SAE Commit processing and anti-clogging behavior.

A relevant detail is that an SAE Commit does not contain arbitrary opaque values. It carries cryptographic values associated with the finite cyclic group selected for the SAE exchange, including a Scalar and a Finite Field Element. These values must satisfy the mathematical constraints of that group before the AP can meaningfully continue processing the Commit.

When an elliptic-curve group is used, the Finite Field Element represents a point on the selected elliptic curve, while the Scalar is an integer constrained by the order of that group. The AP can therefore perform basic mathematical validation before proceeding with the more expensive SAE processing. A malformed element that does not represent a valid point for the selected group, or a Scalar outside the permitted range, can be rejected early. Consequently, simply filling these fields with random bytes is not equivalent to supplying valid SAE Commit material.

Cookie Guzzler gets around this validation barrier by reusing Scalar and Finite Field Element values obtained from a mathematically well-formed SAE Commit. Importantly, the authentication attempt from which these values are obtained does not need to succeed. A legitimate station can initiate SAE using an incorrect password and still generate Scalar and Element values that satisfy the mathematical constraints of the selected group. The password mismatch prevents both peers from ultimately deriving the same secret and completing authentication, but it does not make the transmitted Commit values malformed. This allows suitable Scalar and Element values to be collected without knowing the network password.

These values can then be reused in SAE Commit frames sent from multiple spoofed source MAC addresses. Because the cryptographic fields are mathematically acceptable, the AP cannot discard the frames as trivially malformed input and is driven further into the SAE processing path, which is precisely the resource-consumption condition exploited by Cookie Guzzler.

The goal is not to authenticate. The goal is to force the AP to process and respond to a growing amount of attacker-controlled SAE state.

Muted Peer

In the Muted Peer variant, the attacker sends SAE Commit messages containing valid Scalar and Finite Field Element values but does not complete the corresponding exchange.

According to the behavior analyzed in the paper, an AP may retransmit messages and retain state for these incomplete exchanges. When this is repeated across multiple spoofed peers, a relatively small amount of attacker-generated traffic can cause substantially more work on the AP side.

This creates an amplification effect in terms of processing and protocol state: the attacker initiates an exchange cheaply, while the AP performs the more expensive part and keeps the corresponding state alive.

Hasty Peer

Hasty Peer follows the same general idea but interacts more aggressively with the Anti-Clogging Mechanism.

Instead of simply becoming silent after provoking an AP response, the attacker continues the protocol interaction in a way that causes additional SAE processing.

The interesting property of both variants is that the anti-clogging defense does not simply terminate the attack. The attacker is feeding the AP inputs that are valid enough to make the defensive state machine continue doing work.

That turns a mechanism designed to protect the AP from clogging into part of the resource-consumption path.

Why Cookie Guzzler Matters More Today

This is where the situation becomes very different from Dragon Drain.

Dragon Drain was published during the first major wave of WPA3 research and became widely known. Vendors had strong incentives and several years to modify affected implementations. As a result, testing Dragon Drain today often produces no impact against maintained hardware.

Cookie Guzzler and several of the other generic DoS techniques described in the 2022 paper never received the same amount of practical attention.

The paper itself discusses possible mitigations and explicitly notes that the generic attacks can be mitigated by correcting or improving the relevant weaknesses. However, as of this writing, No public evidence of widespread vendor remediation specifically targeting Cookie Guzzler across WPA3 implementations has been identified as of this writing.

That does not prove that no vendor has implemented a private or undocumented mitigation. It does mean that the situation is very different from Dragon Drain, where patched behavior is now common and expected.

There is another reason why this deserves renewed attention: exploitability has changed.

For several years, Cookie Guzzler was mostly something you encountered by reading an academic paper. Understanding the attack was possible, but reproducing it required enough protocol knowledge and custom tooling that very few people were likely to test it against real equipment.

That barrier has recently become much lower.

A Cookie Guzzler implementation is now publicly available as an airgeddon plugin. It can capture the required SAE Scalar and Finite Field Element using a secondary adapter, or reuse values obtained previously, and then automate the crafted traffic needed for the attack (the current plugin implements the Muted Peer variant).

The following screenshot shows a real Cookie Guzzler attack launched through the airgeddon plugin. The plugin automates the Muted Peer variant described above, making an attack that previously required custom tooling considerably easier to reproduce during practical WPA3 security testing.

This transition is particularly interesting from a security-research perspective. The vulnerability did not suddenly appear. The paper has been public for years. What changed is accessibility.

An attack that previously required a researcher to study the SAE state machine, reproduce the paper and build custom packet-generation logic can now be launched through readily available tooling.

It remains to be seen how the WPA3 ecosystem will react to that change.

Will vendors begin treating Cookie Guzzler and the related SAE DoS techniques as practical vulnerabilities that need concrete fixes? Will mitigations start appearing in firmware and open-source implementations? Or will these attacks remain largely unaddressed even after the exploitation barrier has been reduced enough that almost any wireless-security tester can reproduce them?

This change in accessibility is one of the main reasons why the subject deserves renewed attention.

Mitigation and Defensive Considerations

Keeping the firmware of Wi-Fi infrastructure fully updated is one of the most important defensive measures against known WPA3 implementation flaws. This is particularly relevant for older attacks such as Dragon Drain: maintained devices have had years to receive fixes and implementation changes, so current firmware will often prevent the original attack from succeeding.

Cookie Guzzler presents a different situation. As of this writing, no generally available mitigation specifically preventing the attack has been identified. The attack does not depend on recovering the Wi-Fi password, so using a stronger password does not address the problem.

In practical terms, hardware with greater processing capacity may appear more resistant because more resources are available before SAE processing begins to affect legitimate clients. A device with a substantially more powerful CPU may therefore require a longer or more intensive attack before service degradation becomes noticeable.

This should not be confused with a real mitigation. Increasing computational resources changes the amount of pressure required to exhaust the device; it does not remove the underlying resource-exhaustion condition. A sufficiently sustained attack may still consume the available processing capacity.

Until implementations introduce effective protections against this behavior, the defensive options for Cookie Guzzler remain limited compared with mature attacks such as Dragon Drain.

Conclusion

WPA3 is a substantial security improvement over WPA2, but it does not eliminate Denial of Service from Wi-Fi.

Dragon Drain demonstrated very early that SAE's computational cost could be turned against an AP. Because the attack was disclosed during the early WPA3 era, it has received years of attention and is now commonly mitigated on maintained products, although outdated or poorly maintained vendor implementations can still be vulnerable.

Cookie Guzzler represents a more current and arguably more interesting problem.

Rather than simply overwhelming the cryptographic operation, it abuses behavior around the Anti-Clogging Mechanism itself. The attack uses valid SAE material to remain inside the AP's expected processing path and turns authentication state into a resource-exhaustion primitive.

The broader research also shows that Cookie Guzzler is not an isolated curiosity. SAE exposes several interesting DoS conditions involving state management, retransmissions, PMK handling and implementation-specific behavior.

What makes the current moment especially relevant is not that these attacks are new. It is that at least one of them has become dramatically easier to reproduce.

Security history repeatedly shows that public PoCs change how vulnerabilities are perceived. A weakness that exists only as a section in an academic paper is easy for the industry to ignore. The same weakness packaged into practical tooling is much harder to dismiss.

It will be interesting to see whether Cookie Guzzler follows the same path as Dragon Drain: first research, then practical exploitation, and finally widespread mitigation.

Until then, the right question when evaluating WPA3-SAE is not only:

"Can an attacker authenticate without knowing the password?"

but also:

"How much work can an attacker force the AP to perform before proving that they know it?"

About the Author

My name is Óscar Alfonso Díaz, I am a cybersecurity researcher passionate about the field of cybersecurity, with a particular focus on 802.11 wireless technology. Among my personal projects are the creation of the widely used wireless security auditing tool airgeddon, collaboration with the Wi-Fi security certification program Certified WifiChallenge Professional (CWP), and participation in the development of the red team tool Evil-WinRM.

References, tools and sources:

Simultaneous Authentication of Equals (SAE)
How is your Wi-Fi connection today? DoS attacks on WPA3-SAE
Dragonblood: A Security Analysis of WPA3's SAE Handshake
Original Dragon Drain and Dragon Time implementation
airgeddon official website
airgeddon GitHub
Dragon Drain WPA3 airgeddon plugin
Cookie Guzzler airgeddon plugin