CVE-2026-21484
Username Enumeration in AnythingLLM Password Recovery Endpoint
Publication date: 2026-01-03
Last updated on: 2026-02-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| mintplexlabs | anythingllm | to 1.10.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-204 | The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere. |
| CWE-203 | The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a username enumeration issue in the AnythingLLM application's password recovery endpoint. The endpoint returns subtly different error messages depending on whether the submitted username exists or not. Specifically, the difference is a trailing period in the error message when the username does not exist. This allows attackers to programmatically determine valid usernames by observing these differences, which can be exploited for targeted attacks. [1]
How can this vulnerability impact me? :
The vulnerability allows attackers to enumerate valid usernames on the system by analyzing subtle differences in error messages during password recovery attempts. This can facilitate targeted attacks such as phishing, brute force, or social engineering against known user accounts. Although the impact on confidentiality is rated as low and there is no impact on integrity or availability, the exposure of valid usernames increases the risk of further attacks. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending POST requests to the password recovery endpoint `/api/system/recover-account` with different usernames and recovery codes, then observing subtle differences in the error messages returned. Specifically, when submitting a valid username with invalid recovery codes, the response is "Invalid recovery codes" without a trailing period, whereas for a non-existent username, the response is "Invalid recovery codes." with a trailing period. This difference can be detected programmatically. Example commands using curl are available to demonstrate this behavior. [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized actors to enumerate valid usernames through subtle differences in error messages during password recovery. This can increase the risk of targeted attacks and potentially lead to unauthorized access attempts. Such exposure of user existence information may negatively impact compliance with standards like GDPR and HIPAA, which require protection of personal data and user privacy by minimizing information leakage that could facilitate attacks. However, the provided resources do not explicitly discuss compliance impacts. [1]
What immediate steps should I take to mitigate this vulnerability?
There are no patched versions available to fix this vulnerability. Since the issue is that the password recovery endpoint returns subtly different error messages allowing username enumeration, immediate mitigation steps include monitoring for suspicious activity targeting the password recovery endpoint and implementing additional rate limiting or CAPTCHA to reduce automated enumeration attempts. Additionally, consider customizing or standardizing error messages in your deployment to avoid revealing username validity. However, no official fix or patch is currently provided. [1]