CVE-2026-47713
Description
AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. Prior to 1.13.0, an approved mobile device token created in single-user mode can survive single-user -> multi-user migration even when the device record has userId = null. In multi-user mode, that stale token is still accepted by the mobile authentication middleware. Because no user is attached to the request, downstream mobile handlers fall back to unscoped data-access branches and return workspaces and workspace content without per-user filtering. This permits a pre-migration mobile token to enumerate a workspace assigned only to another user and retrieve victim-owned thread metadata and chat content in multi-user mode. This vulnerability is fixed in 1.13.0.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Stale mobile device tokens from single-user mode survive migration to multi-user mode, allowing unauthorized enumeration of other users' workspaces and chat content.
Vulnerability
In AnythingLLM prior to version 1.13.0, mobile device tokens created during single-user mode are stored with userId = null [1]. When the instance is migrated to multi-user mode, these tokens remain valid because the validDeviceToken middleware does not verify that a user is associated with the device [1]. The affected versions include 1.12.1 and any earlier releases containing the same mobile-device validation and migration logic [1].
Exploitation
An attacker who possesses a previously approved mobile device token obtained while the instance was in single-user mode can exploit this flaw after migration [1]. The attacker sends HTTP requests to mobile endpoints such as POST /api/mobile/send/workspaces or POST /api/mobile/send/workspace-content with the stale token [1]. The middleware accepts the token even though response.locals.user is absent, causing downstream handlers to fall back to unscoped data-access branches that return workspaces and content without per-user filtering [1].
Impact
A successful attack allows the bearer of a stale mobile token to enumerate workspaces assigned to other users and retrieve thread metadata and chat content belonging to those users [1]. This violates confidentiality in multi-user mode, potentially exposing sensitive conversation data. No further privileges are required beyond possession of the token.
Mitigation
The vulnerability is fixed in AnythingLLM version 1.13.0, released May 2026 [1]. The fix includes a migration function migrateDevicesToMultiUser that assigns all orphaned mobile devices (with userId = null) to the new admin user when enabling multi-user mode [2]. Users should upgrade to 1.13.0 or later. No workarounds are documented for unpatched versions.
AI Insight generated on May 28, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2(expand)+ 1 more
- (no CPE)
- (no CPE)range: <1.13.0
Patches
19d714f95c124Update DeviceTokens to already-admin user on MUM migration (#5655)
2 files changed · +23 −0
server/endpoints/system.js+2 −0 modified@@ -50,6 +50,7 @@ const { const { SlashCommandPresets } = require("../models/slashCommandsPresets"); const { EncryptionManager } = require("../utils/EncryptionManager"); const { BrowserExtensionApiKey } = require("../models/browserExtensionApiKey"); +const { MobileDevice } = require("../models/mobileDevice"); const { chatHistoryViewable, } = require("../utils/middleware/chatHistoryViewable"); @@ -620,6 +621,7 @@ function systemEndpoints(app) { multi_user_mode: true, }); await BrowserExtensionApiKey.migrateApiKeysToMultiUser(user.id); + await MobileDevice.migrateDevicesToMultiUser(user.id); await AgentSkillWhitelist.clearSingleUserWhitelist(); await updateENV( {
server/models/mobileDevice.js+21 −0 modified@@ -225,6 +225,27 @@ const MobileDevice = { return []; } }, + + /** + * Migrates all mobile devices with null userId to the specified user. + * Called during multi-user mode enablement to assign orphaned devices to the new admin. + * @param {number} userId - The admin user ID to assign devices to + * @returns {Promise<void>} + */ + migrateDevicesToMultiUser: async function (userId) { + try { + await prisma.desktop_mobile_devices.updateMany({ + where: { userId: null }, + data: { userId: userId }, + }); + console.log("Successfully migrated mobile devices to multi-user mode"); + } catch (error) { + console.error( + "Error migrating mobile devices to multi-user mode:", + error + ); + } + }, }; module.exports = { MobileDevice };
Vulnerability mechanics
Root cause
"Mobile device tokens created in single-user mode with userId=null are not revoked or reassigned when the instance migrates to multi-user mode, so the authentication middleware still accepts them and downstream handlers serve unscoped data."
Attack vector
An attacker who possesses an approved mobile device token obtained before single-user-to-multi-user migration can reuse that token against multi-user mobile endpoints [ref_id=1]. The middleware `validDeviceToken` accepts the device even though its `userId` is null [ref_id=1]. Because no user is attached to `response.locals.user`, downstream handlers such as `POST /api/mobile/send/workspaces` and `POST /api/mobile/send/workspace-content` fall back to unscoped data-access branches that return workspaces and content without per-user filtering [ref_id=1]. This allows the stale token to enumerate workspaces assigned only to another user and retrieve that victim's thread metadata and chat content [ref_id=1].
Affected code
The vulnerability spans `server/endpoints/mobile/index.js`, `server/models/mobileDevice.js`, and `server/endpoints/mobile/middleware/index.js` [ref_id=1]. The root cause is in `MobileDevice` model records where `userId` remains null after migration, and in the `validDeviceToken` middleware that accepts such records [ref_id=1]. The patch modifies `server/models/mobileDevice.js` (adding `migrateDevicesToMultiUser`) and the system endpoints file that triggers migration [patch_id=3014230].
What the fix does
The patch adds a `migrateDevicesToMultiUser` method to the `MobileDevice` model and calls it during the multi-user mode enablement flow [patch_id=3014230]. The method uses `prisma.desktop_mobile_devices.updateMany` to assign all devices with `userId: null` to the new admin user's ID [patch_id=3014230]. This ensures that after migration every mobile device has a valid owning user, so the authentication middleware will attach a user to the request and downstream handlers will apply per-user workspace scoping [ref_id=1].
Preconditions
- authAttacker must possess an approved mobile device token that was created while the instance was in single-user mode.
- configThe AnythingLLM instance must have been migrated from single-user mode to multi-user mode after the token was approved.
- networkAttacker must be able to reach the AnythingLLM server's mobile API endpoints.
Reproduction
1. Start a fresh single-user instance. Call `GET /api/mobile/connect-info` and extract the temporary registration token from the returned `connectionUrl`. 2. Register a mobile device with `POST /api/mobile/register` (Authorization: Bearer `<REG_TOKEN>`, body `{"deviceOs":"android","deviceName":"legacy-android"}`). 3. Approve the device with `POST /api/mobile/update/:id` (body `{"approved":true}`). 4. Enable multi-user mode with `POST /api/system/enable-multi-user`. 5. Create a normal multi-user account (e.g. `victimuser`), create a workspace assigned only to that user, create a thread and chat in that workspace. 6. Reuse the pre-migration approved mobile device token on `GET /api/mobile/auth` (header `x-anythingllm-mobile-device-token: <LEGACY_DEVICE_TOKEN>`). 7. Reuse the same token on `POST /api/mobile/send/workspaces` and `POST /api/mobile/send/workspace-content` (body `{"workspaceSlug":"victim-space"}`) to enumerate and read victim-owned content [ref_id=1].
Generated on May 28, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.