Account Enumeration.

Account enumeration exploits differences in how an application behaves when an account exists versus when it does not — distinct error messages on login, registration, or password reset flows, timing variations, or differing HTTP status codes. By probing many candidate identifiers, an attacker builds a list of valid accounts that can then be targeted by phishing, credential stuffing, or password spraying.

The vulnerability is common in login forms ("unknown user" vs "wrong password"), password reset ("check your email" vs "no account found"), and signup ("email already registered"). It is rarely the end goal: enumeration is a reconnaissance step that sharpens later attacks by removing guesswork. A concrete recent example is CVE-2025-69413 in Gitea (fixed in 1.25.2): the /api/v1/user endpoint returned distinguishable responses for valid versus invalid usernames, letting attackers map real accounts before credential stuffing or spear-phishing.

Even when error strings are uniform, timing can leak: systems that hash the supplied password only when the user exists answer measurably faster for unknown accounts. Robust defences therefore combine generic, identical messages; constant-time code paths (always run a dummy hash); generic password-reset and signup notifications; per-IP and per-account rate limiting; CAPTCHA on abuse; and MFA to blunt downstream attacks. OWASP's WSTG-IDNT-04 test case codifies how to check for it.

flowchart TD
  A[Attacker submits candidate identifier] --> B{Does account exist?}
  B -->|Yes| C["Distinct signal:<br/>wrong-password / slow hash / 200"]
  B -->|No| D["Distinct signal:<br/>unknown-user / fast reply / 404"]
  C --> E[Mark identifier VALID]
  D --> F[Mark identifier invalid]
  E --> G[Build valid-account list]
  G --> H[Credential stuffing / phishing / password spraying]
  C -.uniform message + constant time.-> I[Signals identical: enumeration blocked]
  D -.uniform message + constant time.-> I