Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-10T22:17:10.660Z",
  "pubdate": "2026-08-10T22:17:10.660Z",
  "executiveSummary": "AnythingLLM versions 1.0.0 through 1.15.0 suffer from an unauthenticated account-recovery logic flaw in the password recovery mechanism. The vulnerability allows an attacker to bypass multi-code validation checks during the account recovery process.\nThe primary impact of this vulnerability is complete account takeover, including administrative accounts, leading to unauthorized access to sensitive LLM context and system controls.\nThe affected product is AnythingLLM, specifically the unauthenticated account-recovery flow located in server/utils/PasswordRecovery/index.js.\nThe risk implications are severe, as exploitation enables full administrative compromise of the application in multi-user mode without prior authentication.\nAn attacker must possess knowledge of the target username and a single valid recovery code to execute the attack successfully.\nExploitation requirements include network access to the POST /api/system/recover-account and POST /api/system/reset-password endpoints in multi-user mode, alongside the aforementioned target username and recovery code.",
  "technicalDetails": "The root cause of the vulnerability resides in the unauthenticated account-recovery flow implemented via recoverAccount() within server/utils/PasswordRecovery/index.js.\nDuring the recovery process, the application deduplicates the raw recoveryCodes values prior to executing string trimming operations.\nThis improper input normalization logic allows a single valid recovery code, when submitted twice with varying surrounding whitespace, to successfully satisfy the application's multi-code verification requirement.\nFurthermore, each normalized value matches the exact same stored cryptographic hash instead of enforcing the consumption of distinct, unique hashes for each required verification step.\nThe attack flow begins when an attacker, operating in multi-user mode and possessing a target username and a single valid recovery code, issues a crafted HTTP request to POST /api/system/recover-account.\nBy submitting the single valid recovery code twice with differing whitespace padding, the flawed deduplication and trimming routines validate the input successfully.\nUpon successful validation, the endpoint returns a valid password-reset token to the unauthenticated caller.\nThe attacker then utilizes the acquired password-reset token in a subsequent HTTP POST request to POST /api/system/reset-password.\nThis sequence allows the attacker to finalize the password reset process, completely overriding the target user's credentials and achieving full account takeover.\nThe vulnerable component is exposed over the network via standard HTTP/HTTPS protocols, requiring no prior authentication or user privileges beyond possessing the aforementioned username and single recovery code."
}