CVE-2026-72917 in AnythingLLM
Summary
by MITRE • 08/11/2026
AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. From 1.0.0 to 1.15.0, AnythingLLM's unauthenticated account-recovery flow in server/utils/PasswordRecovery/index.js uses recoverAccount() to deduplicate the raw recoveryCodes values before trimming them, so one valid code submitted twice with different surrounding whitespace can satisfy the two-code check. Each normalized value can also match the same stored hash instead of consuming a distinct hash. An attacker who knows the target username and one recovery code can call POST /api/system/recover-account in multi-user mode, receive a password-reset token, and use POST /api/system/reset-password to take over the account, including an administrator account.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability in AnythingLLM versions 1.0.0 through 1.15.0 stems from a critical flaw in the account recovery mechanism that undermines the security of the authentication system. The issue resides in the server/utils/PasswordRecovery/index.js file where the recoverAccount() function processes recovery codes without proper validation of their uniqueness. This flaw creates a deduplication vulnerability that allows attackers to exploit the system's handling of whitespace characters in recovery code inputs.
The technical implementation error occurs during the processing of raw recoveryCodes values where the application trims whitespace but fails to properly validate that each code is consumed exactly once. When an attacker submits a valid recovery code twice with different surrounding whitespace, the system treats these as distinct values due to the deduplication logic, allowing both instances to be validated against stored password hash values. This creates a scenario where a single valid recovery code can satisfy multiple validation checks within the account recovery process.
The operational impact of this vulnerability is severe and directly enables unauthorized account takeover in multi-user environments. An attacker who knows a target username and possesses one valid recovery code can exploit the flaw by making a POST request to /api/system/recover-account endpoint, which returns a password reset token. This token can then be used to make a subsequent POST request to /api/system/reset-password, ultimately allowing complete account compromise including administrative privileges. The vulnerability effectively bypasses the intended two-factor security mechanism that should require multiple distinct recovery codes for account access.
This security flaw aligns with CWE-284 Access Control Issues and specifically manifests as an authentication bypass vulnerability in the password recovery workflow. The weakness creates an opportunity for privilege escalation attacks as outlined in the MITRE ATT&CK framework under T1078 Valid Accounts and T1531 Account Access Removal, where adversaries can gain unauthorized access to privileged accounts through legitimate recovery mechanisms.
The mitigation strategy requires implementing proper validation of recovery code uniqueness before processing, ensuring that each code hash is consumed exactly once during the account recovery process. Additionally, the application should normalize input values consistently without allowing whitespace variations to affect validation outcomes. Implementing rate limiting on recovery attempts and requiring additional verification steps beyond simple code submission would further strengthen the authentication system against similar exploitation patterns. The fix must ensure that normalized values are properly tracked and validated to prevent any form of code reuse within the same recovery session, maintaining the intended security controls that protect against unauthorized access.