django-allauth EUVD-2026-86517

Requires a django-allauth deployment (before 65.19.4) whose failed-login rate limiting is enabled and where login identifiers (username/email) accept diacritics/accented characters that are not normalized before the throttle counter is applied - the description scopes this to 'some common configurations.' Limiting factors: high attack complexity (AC:H), the attack only degrades throttling rather than granting access directly (still requires an underlying weak/guessable credential to succeed), and it depends on the specific normalization/config behavior rather than working against all default setups.

This is a low-severity, defense-in-depth weakness, not a directly exploitable breach. The CVSS 3.1 base score is 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N): network-reachable and unauthenticated, but high attack complexity and only Low integrity impact with no confidentiality or availability impact. CWE-180 (incorrect ordering of canonicalization vs. validation) accurately captures the root cause - the failed-login rate limiter counts attempts against the raw submitted identifier before diacritics are normalized, so accented variants create separate counters and inflate the effective attempt ceiling. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' Signals are consistent rather than conflicting: low CVSS, no exploitation telemetry, and an available vendor patch all point to a real-but-minor hardening fix. The one nuance worth stating explicitly is that the tag 'Information Disclosure' does not match the mechanics - the flaw weakens brute-force throttling (integrity/control bypass, I:L), it does not disclose data (C:N). Priority is low: patch on normal maintenance cadence unless the deployment relies heavily on allauth's login rate limiting as a primary brute-force control.

An attacker running an online password-guessing campaign against a Django site using django-allauth submits login attempts using diacritic variants of a target username or email (e.g., 'admín' alongside 'admin'). Because the throttle counts each variant separately before normalization, the attacker gets substantially more guesses than the configured limit before lockout, improving brute-force odds. No public exploit code is identified, and high attack complexity plus dependence on common-but-specific configurations limits reliability.