CVE-2026-47713: AnythingLLM Pre-Migration Token Privilege Escalation & Data Exposure

Technical summary

The vulnerability stems from improper state management during single-user to multi-user migration in AnythingLLM. Mobile authentication tokens created in single-user mode contain a userId field set to null when the device record is initially created. During migration, these tokens are not invalidated or re-scoped. The mobile authentication middleware in multi-user mode accepts these legacy tokens, but because no user is bound to the request context, downstream handlers fall back to unscoped data-access code paths that bypass per-user content filtering. This permits unauthorized enumeration and retrieval of workspace metadata and chat thread content belonging to other users. The flaw maps to improper authorization (CWE-285) and insufficient per-user data access controls (CWE-639).

Business impact

Organizations running multi-user AnythingLLM deployments are at risk if they have migrated from single-user mode and have users who held approved mobile devices before the migration. An attacker who retained a pre-migration mobile token could enumerate workspaces assigned to other users and exfiltrate sensitive chat histories and conversation metadata. The severity is limited by the need for prior legitimate device approval and an explicit single-user to multi-user migration event, but the impact—unauthorized access to private LLM interactions—could expose confidential information, proprietary prompts, or sensitive business conversations stored in chat threads.

Affected systems

AnythingLLM releases prior to version 1.13.0 are affected. The vulnerability is specific to deployments that have transitioned from single-user mode to multi-user mode and where mobile devices were provisioned before the migration. Single-user-only deployments and deployments that have never used mobile authentication are not at risk. Multi-user deployments that are freshly installed (never used single-user mode) are not affected because tokens are issued correctly in a scoped context from the start.

Exploitability

Exploitation requires moderate preconditions: an attacker must have held a legitimate, approved mobile device token before the single-user to multi-user migration, and the environment must have undergone that specific migration. The CVSS vector (AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N) reflects high attack complexity and high privilege requirements—the attacker needs high privileges to have originally approved the mobile device, and user interaction is required (likely device unlock or app launch). The confidentiality impact is low, affecting only data visibility. The scenario is plausible in managed environments where administrators provision shared or test devices, but unlikely in typical end-user deployments.

Remediation

Organizations should upgrade AnythingLLM to version 1.13.0 or later, which fixes the token-scoping issue and likely invalidates or re-issues mobile tokens during migration. After upgrading, verify that mobile devices re-authenticate and receive properly scoped tokens in the multi-user environment. For defense-in-depth, review access logs for unusual cross-user workspace access or token reuse patterns, and consider re-provisioning mobile devices in multi-user mode to ensure correct scoping from the outset.

Patch guidance

Upgrade AnythingLLM to version 1.13.0 or later. Review the vendor's release notes for any migration-specific steps or token reset procedures. If the application was recently migrated from single-user to multi-user mode, prioritize this upgrade and verify post-patch that mobile devices successfully re-authenticate. No interim mitigations are available; patching is the primary fix. Verify against the vendor advisory (mintplexlabs/anythingllm) for any additional guidance or deprecation timelines for older mobile tokens.

Detection guidance

Monitor for suspicious patterns: (1) mobile API requests with null or missing userId fields in logs; (2) cross-user workspace access or content retrieval by a single mobile device token; (3) access to private workspaces by tokens that predate the single-user to multi-user migration; (4) anomalous token reuse across user contexts. Review mobile authentication middleware logs for tokens accepted despite lacking a bound user identity. Audit mobile device provisioning records and compare issue dates against your migration date to identify potentially affected tokens.

Why prioritize this

Although the CVSS score is low (2.0), this vulnerability should not be dismissed. It requires specific preconditions (prior device provisioning and an actual migration event), but if those conditions are met, the impact—unauthorized access to private chat content and workspace metadata—is substantive. Prioritize this if you operate a multi-user AnythingLLM deployment that has recently migrated from single-user mode, or if you have mobile devices provisioned and cannot definitively confirm they were issued post-migration. For single-user-only or freshly installed multi-user deployments, priority is lower.

Risk score, explained

The CVSS score of 2.0 (Low severity) reflects the high barriers to exploitation: high attack complexity, high privilege requirement (to have approved the device initially), and user interaction needed. However, the low score does not capture the sensitivity of the data at risk (private LLM conversations). The true organizational risk depends on whether your deployment matches the vulnerable configuration (migrated from single-user mode with pre-migration mobile devices). Organizations in that scenario should treat this as a medium priority patch.

Frequently asked questions