CVE-2026-55611: 
MinimOS 脆弱性の分析と軽減

CVE-2026-55611 is a cross-tenant IDOR (Insecure Direct Object Reference) deletion vulnerability in AnythingLLM, an open-source LLM application platform by Mintplex-Labs. It represents an incomplete fix for a prior advisory (GHSA-p5rf-8p88-979c): while that fix added userId/workspaceId ownership scoping to parsed-file read/delete paths, the POST /api/workspace/:slug/embed-parsed-file/:fileId flow still deletes files by primary key alone inside finally{} blocks that execute unconditionally — even when the ownership-checked read fails. Affected versions span from 1.11.1 through versions before 1.14.1; the vulnerability is fixed in 1.14.1. It carries a CVSS v3.1 base score of 0.0 (Low) as scored by the vendor, though the practical impact is data loss in multi-tenant deployments (GitHub Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). In server/models/workspaceParsedFiles.js, the moveToDocumentsAndEmbed() function correctly scopes the get() call with userId and workspaceId, but the finally{} block calls this.delete({ id: parseInt(fileId) }) with no ownership constraints. A parallel unscoped finally{} block exists in server/endpoints/workspacesParsedFiles.js. Because finally{} blocks execute regardless of whether the preceding ownership check throws an exception, an attacker can supply any integer fileId — independent of the workspace slug in the URL — and the target file will be deleted even though the server returns { "success": false, "error": "File not found" }. The route is gated by flexUserRoleValid([ROLES.admin, ROLES.manager]) and validWorkspaceSlug, but these controls only validate the attacker's own workspace membership, not ownership of the target fileId (GitHub Advisory, Patch Commit).

A malicious or compromised manager or admin in a multi-user AnythingLLM deployment can silently delete any other user's parsed (chat-uploaded) files across all workspaces — including workspaces they have no membership in — by enumerating sequential integer fileId values. This causes cross-tenant data loss and disrupts other users' document and RAG (Retrieval-Augmented Generation) workflows. There is no confidentiality impact (file contents are not exposed), but availability and integrity of other tenants' document data are directly affected (GitHub Advisory).

A proof-of-concept script (server/poc-finding2.js) was included in the security advisory and verified at runtime against a real Prisma database, confirming exploitability on the main branch at commit 6442ea9. The NVD SSVC assessment classifies exploitation status as "poc" with non-automatable exploitation and partial technical impact. The EPSS score is 0.00236 (~0.24th percentile), indicating low probability of widespread automated exploitation. There is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time (GitHub Advisory, Feedly).

1. Prerequisite: Obtain manager or admin credentials in a multi-user AnythingLLM instance running versions 1.11.1–1.14.0.
2. Enumerate fileIds: Since workspace_parsed_files rows use sequential integer primary keys, iterate integer values (e.g., 1, 2, 3, …) to identify potential victim file IDs. No prior knowledge of the victim's workspace or username is required.
3. Craft the request: Send a POST request to /api/workspace/<attacker-controlled-workspace-slug>/embed-parsed-file/<target-fileId> with a valid Authorization: Bearer <attacker-token> header. The workspace slug must be one the attacker is a member of, but the fileId can belong to any workspace.
4. Trigger deletion: The server's ownership check on the get() call will fail (returning { "success": false, "error": "File not found" }), but the unscoped finally{} block executes WorkspaceParsedFiles.delete({ id: parseInt(fileId) }), permanently deleting the victim's file from the database.
5. Confirm deletion: Query the database or observe that the victim's document/RAG workflow fails, confirming the file has been removed (GitHub Advisory).

• Logs: AnythingLLM server logs showing repeated POST /api/workspace/<slug>/embed-parsed-file/<id> requests returning { "success": false, "error": "File not found" } or { "success": false, "error": "Failed to embed file" } in rapid succession across multiple fileId values from the same authenticated session.
• Database: Unexpected deletions from the workspace_parsed_files table where the deleted record's userId or workspaceId does not match the requesting user's identity or workspace membership.
• Network: Authenticated POST requests to the embed-parsed-file endpoint with sequentially incrementing fileId path parameters originating from a single manager/admin account.
• Application Behavior: Users reporting missing parsed/uploaded files or broken RAG document references without having deleted them themselves (GitHub Advisory).

Upgrade AnythingLLM to version 1.14.1 or later, which scopes both finally{} cleanup deletes by userId and workspaceId (e.g., WorkspaceParsedFiles.delete({ id: parseInt(fileId), userId: user.id, workspaceId: workspace.id })). No configuration-based workaround is available for earlier versions. As an interim measure, restrict the manager role to trusted users only in multi-user deployments until the upgrade can be applied (Patch Commit, GitHub Advisory).

The vulnerability was reported by security researcher m0hx65 and published by AnythingLLM maintainer timothycarambat on June 14, 2026. The advisory explicitly frames this as an incomplete fix for a prior advisory (GHSA-p5rf-8p88-979c), highlighting the risk of partial security patches in complex codebases. No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and standard CVE aggregator entries (GitHub Advisory).