AnythingLLM EUVD-2026-33069

Three specific conditions must all be true simultaneously: (1) the AnythingLLM instance was previously operated in single-user mode and at least one mobile device token was approved during that period, (2) the instance has since been migrated to multi-user mode without applying the 1.13.0 patch, and (3) the attacker possesses the pre-migration mobile device token (i.e., they were the approved mobile user in single-user mode). PR:H in the CVSS vector confirms that prior credential acquisition (the approved token) is required. Exploitation is limited by the narrow migration-window precondition - instances deployed directly in multi-user mode, instances with no prior mobile device approvals, or instances where all mobile tokens were manually revoked post-migration are not exploitable. UI:R and AC:H further bound the realistic attacker population.

The official CVSS 3.1 base score is 2.0 (Low), with vector AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N. Every severity modifier suppresses the score: High Attack Complexity (AC:H) reflects the narrow exploitation window requiring a prior migration event; High Privileges Required (PR:H) means the attacker must already possess a previously approved mobile device token; User Interaction is required (UI:R); and the confidentiality impact is Low (C:L) with no integrity or availability impact. No EPSS score data was provided in the input. The CVE is not listed in CISA KEV, and no POC exploit is identified. Real-world risk is genuinely low: exploitation requires a specific sequence of events - attacker had a mobile token approved in single-user mode, the instance was later migrated to multi-user mode, and the token was never revoked. Deployments that have never run in single-user mode or have never issued mobile tokens are not affected. The CVSS PR:H designation is somewhat contextually unusual since the 'privilege' is a legacy token rather than an active credential, but the signal is directionally correct: not just any network attacker can exploit this.

An attacker who had a mobile device approved during an AnythingLLM single-user deployment retains their token after the administrator migrates the instance to multi-user mode. Using that token - which is still accepted by the mobile authentication middleware due to the null userId not being rejected - the attacker submits API requests that fall through to unscoped data-access branches, allowing them to enumerate workspaces assigned to other users and read chat thread metadata and message content that they are not authorized to access. No public exploit code is required; the condition is triggered by normal mobile API usage with the stale token.