CVE-2026-21484: 
Homebrew vulnerability analysis and mitigation

CVE-2026-21484 is a username enumeration vulnerability in AnythingLLM, an open-source application that converts content into LLM-usable context. The password recovery endpoint (/api/system/recover-account) returns subtly different error messages depending on whether a submitted username exists in the system, allowing unauthenticated attackers to enumerate valid usernames. All versions prior to the fix introduced in commit e287fab56089cf8fcea9ba579a3ecdeca0daa313 (corresponding to version 1.10.0) are affected. The vulnerability was published on January 3, 2026, and carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-203 (Observable Discrepancy) and CWE-204 (Observable Response Discrepancy). The recoverAccount function in server/utils/PasswordRecovery/index.js returned "Invalid recovery codes" (without a trailing period) when a user existed but provided invalid codes, and "Invalid recovery codes." (with a trailing period) when the username did not exist — a one-character difference that leaks user existence. The fix (commit e287fab) standardizes both code paths to return the same error string with a trailing period, eliminating the discrepancy. No authentication or special privileges are required to exploit this endpoint, and the attack is executable remotely over the network with low complexity (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated attacker to determine which usernames are registered in an AnythingLLM instance by analyzing the subtle difference in error message responses. This information can be leveraged to facilitate targeted credential stuffing, brute-force attacks, phishing campaigns, or account takeover attempts against identified users. There is no direct integrity or availability impact; the confidentiality impact is limited to user account existence disclosure (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, consisting of simple curl commands targeting the /api/system/recover-account endpoint. There is no evidence of active in-the-wild exploitation at this time. The EPSS score is approximately 0.028% (0.000280), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. A Nuclei detection template was added to the ProjectDiscovery nuclei-templates repository, further lowering the barrier for automated scanning (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing AnythingLLM instances (e.g., via Shodan or Censys searching for the default port 3001 or known AnythingLLM UI signatures).
2. Prepare username list: Compile a list of candidate usernames to test (e.g., admin, user, root, common names).
3. Send enumeration requests: For each candidate username, send a POST request to the password recovery endpoint with an intentionally invalid recovery code:

   curl -X POST "http://<target>:3001/api/system/recover-account" \
     -H "Content-Type: application/json" \
     -d '{"username":"admin","recoveryCodes":["xxx"]}'

4. Analyze responses: Compare the error message in the JSON response body:
   • "Invalid recovery codes" (no trailing period) → username exists
   • "Invalid recovery codes." (with trailing period) → username does not exist
5. Build valid username list: Record all usernames that return the "exists" variant for use in subsequent credential attacks, phishing, or brute-force campaigns (GitHub Advisory).

• Network: High volume of POST requests to /api/system/recover-account from a single IP or rotating IP range, especially with varied username values and identical invalid recoveryCodes.
• Logs: Application or web server access logs showing repeated hits to the /api/system/recover-account endpoint with different usernames in rapid succession; automated tooling may produce consistent User-Agent strings or request timing patterns.
• Behavioral: Requests containing obviously invalid or placeholder recovery codes (e.g., ["xxx"], ["test"]) paired with systematic username variations suggest automated enumeration activity.

Upgrade AnythingLLM to version 1.10.0 or later, which includes the fix introduced in commit e287fab56089cf8fcea9ba579a3ecdeca0daa313. The fix standardizes the error response from the password recovery endpoint so that both the "user exists" and "user does not exist" code paths return identical messages, eliminating the observable discrepancy. As an additional defense-in-depth measure, implement rate limiting on the /api/system/recover-account endpoint to reduce the feasibility of automated enumeration attacks even on unpatched instances (GitHub Advisory, Patch Commit).

The vulnerability was reported by security researcher DenizParlak and published by AnythingLLM maintainer timothycarambat via GitHub's security advisory process on January 2, 2026. The issue received coverage from automated vulnerability tracking services including INCIBE-CERT and ENISA's EUVD. A Nuclei detection template was subsequently contributed to ProjectDiscovery's nuclei-templates repository, indicating community interest in automated detection (GitHub Advisory).