The vulnerability in this 2FA plugin is not that rate limiting is absent — it exists and appears functional. The flaw is that the rate-limit bucket is keyed to a session token rather than the user account. Every time the attacker re-authenticates with the victim's password, they receive a fresh session, and the attempt counter resets to zero. This means the attacker can iterate through 2FA codes sequentially without ever triggering the rate limit. The login succeeds each time; only the 2FA verification fails until the correct code is found.
This is a critical distinction in understanding the actual risk. The plugin can demonstrate rate-limiting logic — it logs attempts, it enforces thresholds — yet the protection is trivially bypassed by any attacker who already possesses the victim's password. This false-positive mitigation is often more dangerous than no mitigation at all, because it induces a false sense of security in both administrators and security reviewers who see that 2FA rate limiting is enabled.
The precondition of having the password is significant but not uncommon. Credential reuse, credential-stuffing from prior breaches, or targeted phishing all provide a realistic path to satisfy it. Once the attacker has the password, 2FA degrades from a strong control to a time-delayed one — not because the time cost accumulates, but because it never accumulates at all.
The fix requires tracking second-factor attempts against an identifier the attacker cannot reset: the user account, the second-factor device identifier, or at minimum the combination of username plus 2FA method. Simply changing the tracking key from session token to account is the correct remediation, but consider whether this introduces a denial-of-service surface where an attacker can lock a victim out of their own account by exhausting the attempt quota without needing the password — this is a separate but important tradeoff to evaluate in the patched version.