CVE-2026-55611: AnythingLLM Auth Bypass Vulnerability

CVE-2026-55611 Overview

CVE-2026-55611 is an Insecure Direct Object Reference (IDOR) vulnerability in AnythingLLM, an application that converts content into context for Large Language Model (LLM) references. The flaw affects versions 1.11.1 through 1.14.0 and resides in the parsed-files handling logic. While userId/workspaceId scoping was added to read and delete paths, the POST /api/workspace/:slug/embed-parsed-file/:fileId endpoint still deletes files by primary key without an ownership check. A manager or admin in multi-user mode can enumerate integer fileId values to delete any other user's parsed file in any workspace, including workspaces they do not belong to. The vulnerability is fixed in version 1.14.1.

Critical Impact
Authenticated managers or admins can delete arbitrary parsed files across all workspaces by enumerating integer file identifiers, bypassing workspace membership boundaries.

Affected Products

AnythingLLM versions 1.11.1 through 1.14.0
Multi-user deployments where manager or admin roles exist
Fixed in AnythingLLM 1.14.1

Discovery Timeline

2026-06-24 - CVE-2026-55611 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-55611

Vulnerability Analysis

The vulnerability is classified under [CWE-639] Authorization Bypass Through User-Controlled Key. AnythingLLM added userId and workspaceId scoping to the parsed-files read and delete code paths to enforce ownership. However, the POST /api/workspace/:slug/embed-parsed-file/:fileId route still references the target file solely by its primary key. The deletion occurs inside two finally{} blocks, which Node.js executes regardless of whether the ownership-checked read succeeded or threw an error. The API responds with File not found to the caller, masking the destructive side effect while the file is still removed from the database.

Root Cause

The root cause is missing authorization on the deletion call inside the finally{} cleanup blocks. The WorkspaceParsedFiles.delete({ id: parseInt(fileId) }) query accepts only the integer fileId, with no userId or workspaceId constraint. Because finally{} runs even when the preceding ownership check fails, an attacker who supplies any valid integer fileId triggers an unconditional delete on records they do not own.

Attack Vector

An authenticated manager or admin in multi-user mode issues a POST request to /api/workspace/:slug/embed-parsed-file/:fileId against a workspace they have access to, supplying integer fileId values belonging to other users or workspaces. The ownership-checked read fails, but the finally{} block deletes the targeted file by primary key. Iterating through sequential integer IDs allows mass deletion across the deployment.

javascript

// Patch from server/models/workspaceParsedFiles.js
      console.error("Failed to move and embed file:", error);
      return { success: false, error: error.message, document: null };
    } finally {
-      // Always delete the file after processing
-      await this.delete({ id: parseInt(fileId) });
+      await this.delete({
+        id: parseInt(fileId),
+        ...(user ? { userId: user.id } : {}),
+        workspaceId: workspace.id,
+      });
    }
  },

Source: GitHub Commit 34a42a3. The patch adds userId and workspaceId constraints to the delete query so deletions only succeed when the caller owns the target file.

Detection Methods for CVE-2026-55611

Indicators of Compromise

Sequential POST requests to /api/workspace/:slug/embed-parsed-file/:fileId with incrementing integer fileId values from a single authenticated user.
Application logs returning File not found responses paired with successful DELETE SQL statements against the workspace_parsed_files table.
Unexpected disappearance of parsed files from workspaces where the requesting user is not a member.

Detection Strategies

Audit reverse proxy and application logs for repeated calls to the embed-parsed-file endpoint with non-sequential workspace slugs.
Correlate fileId enumeration patterns against the authenticated user's workspace membership to identify cross-tenant access.
Enable database query logging to flag WorkspaceParsedFiles.delete operations that lack a corresponding workspaceId filter.

Monitoring Recommendations

Alert when a single manager or admin account triggers parsed-file deletions affecting multiple workspaces within a short window.
Track HTTP 404 responses on the embed-parsed-file route, as the patched advisory notes the server returns File not found while still deleting the record on vulnerable versions.
Review role assignments and demote unnecessary manager or admin accounts in multi-user deployments.

How to Mitigate CVE-2026-55611

Immediate Actions Required

Upgrade AnythingLLM to version 1.14.1 or later, which contains the authorization fix.
Audit existing manager and admin accounts in multi-user mode and remove privileges that are not strictly required.
Review parsed-file inventories across workspaces to identify deletions that occurred during the vulnerable window.

Patch Information

The maintainers published patches in commits 34a42a3 and 683fe3d. The fix adds userId and workspaceId constraints to the delete query inside the finally{} block and removes the unconditional delete from the endpoint handler. Full advisory details are available in the GitHub Security Advisory GHSA-r872-gr59-vf5w.

Workarounds

Restrict the multi-user role assignments so that only fully trusted administrators retain manager or admin privileges until the upgrade is applied.
Place the AnythingLLM API behind a reverse proxy that rate-limits or blocks requests to /api/workspace/:slug/embed-parsed-file/:fileId from non-administrative principals.
Take a backup of the parsed-files database tables so deletions performed via this vector can be recovered.

bash

# Upgrade AnythingLLM to the patched release
git fetch --tags
git checkout v1.14.1
yarn install
yarn prisma:setup
yarn dev:server