CVE-2024-3033: Mintplexlabs AnythingLLM Auth Bypass Flaw

CVE-2024-3033 Overview

An improper authorization vulnerability exists in the mintplex-labs/anything-llm application, specifically within the /api/v/ endpoint and its sub-routes. This flaw allows unauthenticated users to perform destructive actions on the VectorDB, including resetting the database and deleting specific namespaces, without requiring any authorization or permissions. The issue affects all versions up to and including the latest version, with a fix introduced in version 1.0.0. Exploitation of this vulnerability can lead to complete data loss of document embeddings across all workspaces, rendering workspace chats and embeddable chat widgets non-functional. Additionally, attackers can list all namespaces, potentially exposing private workspace names.

Critical Impact

Unauthenticated attackers can completely destroy Vector Database contents, causing total loss of document embeddings and rendering all workspace chats and embeddable widgets non-functional while also exposing private workspace names.

Affected Products

• mintplexlabs anythingllm (all versions prior to 1.0.0)

Discovery Timeline

• 2024-06-06 - CVE CVE-2024-3033 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-3033

Vulnerability Analysis

This vulnerability represents a classic improper authorization flaw (CWE-863) where critical API endpoints were exposed without any authentication or authorization checks. The /api/v/:command endpoint acts as a direct interface to the VectorDB class, allowing any external request to invoke methods on the database. This design flaw enables unauthenticated users to execute destructive operations including database resets and namespace deletions.

The vulnerability is particularly severe because Vector databases store document embeddings that are essential for the core functionality of LLM applications. Once destroyed, these embeddings cannot be recovered without re-processing all original documents. The exposure of namespace names further compounds the risk by potentially revealing information about private workspaces and their organizational structure.

Root Cause

The root cause of this vulnerability lies in the placement of a debug/development endpoint in production-accessible code without any authentication middleware. The /api/v/:command route was designed to allow direct invocation of any method on the VectorDb class by simply specifying the method name as a URL parameter. This "catch-all" pattern, combined with the complete absence of authorization checks, created a direct pathway for attackers to manipulate the vector database.

Attack Vector

The attack vector is network-based and requires no user interaction or authentication. An attacker can send HTTP POST requests directly to the /api/v/:command endpoint, where :command represents any method available on the VectorDb class. By enumerating available commands through error responses, attackers can identify destructive operations like database reset or namespace deletion functions. The attack can be executed remotely against any publicly accessible AnythingLLM instance.

// Vulnerable code removed in security patch (server/index.js)
// Source: https://github.com/mintplex-labs/anything-llm/commit/bf8df60c02b9ddc7ba682809ca12c5637606393a

apiRouter.post("/v/:command", async (request, response) => {
  try {
    const VectorDb = getVectorDbClass();
    const { command } = request.params;
    if (!Object.getOwnPropertyNames(VectorDb).includes(command)) {
      response.status(500).json({
        message: "invalid interface command",
        commands: Object.getOwnPropertyNames(VectorDb),
      });
      return;
    }

    try {
      const body = reqBody(request);
      const resBody = await VectorDb[command](body);
      response.status(200).json({ ...resBody });
    } catch (e) {
      console.error(JSON.stringify(e));
      response.status(500).json({ error: e.message });
    }
    return;
  } catch (e) {
    console.log(e.message, e);
    response.sendStatus(500).end();
  }
});

Source: GitHub Commit bf8df60

Detection Methods for CVE-2024-3033

Indicators of Compromise

• Unexpected HTTP POST requests to /api/v/ endpoints with various command parameters
• Sudden loss of document embeddings or non-functional workspace chats
• Web server logs showing sequential requests to /api/v/:command probing for available methods
• Error responses revealing VectorDb method names to external IP addresses

Detection Strategies

• Monitor web application logs for any requests to /api/v/ endpoints from external sources
• Implement alerting on unauthorized access attempts to vector database management endpoints
• Review access logs for enumeration patterns where multiple /api/v/:command requests are made in succession
• Set up integrity monitoring for vector database contents to detect unexpected deletions or modifications

Monitoring Recommendations

• Enable verbose logging for all API endpoints in AnythingLLM deployments
• Implement network-level monitoring for unusual traffic patterns to the application server
• Deploy Web Application Firewall (WAF) rules to block requests to /api/v/ endpoints from untrusted sources
• Establish baseline metrics for vector database size and alert on significant reductions

How to Mitigate CVE-2024-3033

Immediate Actions Required

• Upgrade AnythingLLM to version 1.0.0 or later immediately
• Restrict network access to AnythingLLM instances using firewall rules until patching is complete
• Review web server logs for evidence of exploitation attempts against /api/v/ endpoints
• If exploitation is suspected, restore vector database from backups and re-process document embeddings

Patch Information

The vulnerability has been addressed in commit bf8df60c02b9ddc7ba682809ca12c5637606393a. The fix removes the vulnerable /api/v/:command endpoint from production code, restricting it to development environments only. Users should upgrade to version 1.0.0 or later which includes this security patch. For detailed information about the fix, refer to the GitHub Commit and the Huntr Bounty Report.

Workarounds

• Place AnythingLLM behind a reverse proxy with authentication requirements for all API endpoints
• Implement network segmentation to prevent direct external access to the application
• Configure firewall rules to block all requests to /api/v/* endpoints from external networks
• Use a Web Application Firewall to block requests matching the vulnerable endpoint pattern

# Example nginx configuration to block vulnerable endpoint
location ~ ^/api/v/ {
    deny all;
    return 403;
}