CVE-2026-32717: Mintplexlabs AnythingLLM Auth Bypass

CVE-2026-32717 Overview

AnythingLLM is an application that transforms various content types into contextual references that large language models (LLMs) can utilize during interactive chat sessions. A broken access control vulnerability exists in versions 1.11.1 and earlier that allows suspended users to maintain access through browser extension API keys.

In multi-user mode, AnythingLLM correctly blocks suspended users when they attempt to authenticate via the normal JWT-backed session path. However, the application fails to validate user suspension status when requests are made through the browser extension API key path. If a user possesses a valid brx-... browser extension API key prior to suspension, that key continues to function after the user's account is suspended.

Critical Impact

Suspended users can bypass access controls to read workspace metadata, upload content, and perform embed operations using pre-existing browser extension API keys.

Affected Products

• Mintplexlabs AnythingLLM versions 1.11.1 and earlier
• AnythingLLM multi-user deployments with browser extension functionality enabled

Discovery Timeline

• 2026-03-16 - CVE-2026-32717 published to NVD
• 2026-03-16 - Last updated in NVD database

Technical Details for CVE-2026-32717

Vulnerability Analysis

This vulnerability is classified under CWE-863 (Incorrect Authorization), representing a broken access control flaw in the application's authentication architecture. The core issue stems from the presence of two separate authentication pathways that do not share a unified suspension validation mechanism.

When administrators suspend a user account, the application correctly invalidates JWT-based session tokens, preventing standard authenticated requests. However, the browser extension API key authentication flow operates independently and does not query the user's current suspension status. This architectural oversight creates a security gap where pre-issued API keys remain functional despite the user being administratively disabled.

The impact allows a suspended user to continue accessing browser extension endpoints, potentially reading workspace metadata and executing upload or embed operations that should be restricted.

Root Cause

The root cause is the lack of a unified user status verification across all authentication pathways. The browser extension API key validation logic does not include a check against the user's suspension status in the database. When an API request arrives with a valid brx-... key, the system authenticates the key itself without verifying whether the associated user account remains in good standing.

Attack Vector

An attacker with a previously-issued browser extension API key can exploit this vulnerability through the following scenario:

1. A legitimate user obtains a browser extension API key (brx-... format) while their account is active
2. The administrator suspends the user's account due to policy violations or other security concerns
3. The suspended user continues making API requests using their pre-existing browser extension key
4. The application processes these requests, allowing access to workspace metadata, upload functionality, and embed operations

The vulnerability requires network access and high privileges (an existing authenticated user with a browser extension key), but no user interaction is required for exploitation.

// Security patch in server/endpoints/admin.js - Enforce user suspension check on browser extension API key path
 const { ApiKey } = require("../models/apiKeys");
+const { BrowserExtensionApiKey } = require("../models/browserExtensionApiKey");
 const { Document } = require("../models/documents");
 const { EventLogs } = require("../models/eventLogs");
 const { Invite } = require("../models/invite");

Source: GitHub Commit Reference

The patch adds the BrowserExtensionApiKey model to the admin endpoints, enabling proper key revocation when users are suspended.

// Security patch in server/models/browserExtensionApiKey.js - Enforce user suspension check on browser extension API key path
    }
  },

+  /**
+   * Deletes all browser extension API keys for a user.
+   * Should be called when a user is deleted to revoke all their keys.
+   * @param {number} userId - The user ID whose keys should be deleted
+   * @returns {Promise<{success: boolean, error: string|null}>}
+   */
+  deleteAllForUser: async function (userId) {
+    try {
+      if (!userId) return { success: false, error: "User ID is required" };
+      await prisma.browser_extension_api_keys.deleteMany({
+        where: { user_id: parseInt(userId) },
+      });
+      return { success: true, error: null };
+    } catch (error) {
+      console.error(
+        "Failed to delete browser extension API keys for user",
+        error
+      );
+      return { success: false, error: error.message };
+    }
+  },

+  /**
+   * Gets browser keys by params
+   * @param {object} clause

Source: GitHub Commit Reference

This patch introduces the deleteAllForUser function that automatically revokes all browser extension API keys when a user is suspended or deleted.

Detection Methods for CVE-2026-32717

Indicators of Compromise

• API requests from browser extension keys (brx-... prefix) associated with suspended user accounts
• Workspace metadata access patterns from users who should no longer have system access
• Upload or embed operations occurring after user suspension timestamps
• Authentication logs showing successful API key validation for disabled accounts

Detection Strategies

• Implement logging that correlates browser extension API key usage with user account status
• Create alerts for any API activity from accounts flagged as suspended in the user database
• Monitor for workspace access patterns that don't align with active user sessions
• Review audit logs for discrepancies between JWT-based authentication failures and successful API key authentications for the same user

Monitoring Recommendations

• Enable comprehensive API request logging including the authentication method used
• Correlate browser extension API key activity with user account status changes
• Implement real-time alerting for suspended users attempting any form of authentication
• Conduct periodic audits of active browser extension API keys against user account status

How to Mitigate CVE-2026-32717

Immediate Actions Required

• Upgrade AnythingLLM to a version containing commit a207449 or later
• Review all currently suspended user accounts and manually revoke their browser extension API keys
• Audit recent API activity from suspended users to identify any unauthorized access
• Temporarily disable browser extension functionality until the patch is applied in high-security environments

Patch Information

Mintplex Labs has addressed this vulnerability in commit a207449095158f28c7e16acf113356b336c87803. The fix introduces proper browser extension API key revocation when users are suspended or deleted. Organizations should apply this patch by updating to the latest version of AnythingLLM.

For detailed patch information, refer to the GitHub Security Advisory and the GitHub Commit Reference.

Workarounds

• Manually delete browser extension API keys from the database when suspending users
• Implement a scheduled job to cross-reference API keys with suspended user accounts
• Restrict browser extension API endpoint access at the network/firewall level until patched
• Consider disabling the browser extension feature entirely in multi-user deployments until the update is applied

# Configuration example
# Query to identify browser extension API keys for suspended users
# Run in your AnythingLLM database to find orphaned keys

# For PostgreSQL/MySQL:
# SELECT beak.* FROM browser_extension_api_keys beak
# INNER JOIN users u ON beak.user_id = u.id
# WHERE u.suspended = true;

# Manual key revocation (use with caution):
# DELETE FROM browser_extension_api_keys 
# WHERE user_id IN (SELECT id FROM users WHERE suspended = true);