---

If you're tinkering with open-source LLM projects, there's a good chance you may have heard about Anything-LLM. It's a promising codebase for interfacing large language models (LLMs) with various knowledge sources. However, in September 2023, researchers discovered a critical vulnerability in this repository that could compromise your data and backend if you run it unpatched. This vulnerability, officially tracked as CVE-2023-4899, is a classic yet harmful _SQL Injection_ found in Anything-LLM versions prior to ..1.

Let's break down what happened, why it matters, and how an attacker could exploit it, using simple language and clear code examples.

What is SQL Injection?

Before diving into the specifics, here's a quick refresher: SQL Injection happens when a web app takes user input, inserts it into an SQL query without proper validation, and then executes that query. This means a clever (or malicious) user can sneak extra commands into places where only safe user data was meant to go. It's one of the oldest and most dangerous vulnerabilities on the web.

Where's the Bug in Anything-LLM?

The issue stemmed from the handling of user input in API endpoints dealing with data retrieval and search.

Without any sanitization or safe database access patterns (like using parameterized queries), the application would directly interpolate variables from client requests into its SQL statements.

Here's a simplified snippet inspired by the original vulnerable code

// ./server/routes/api.js

app.post('/api/search', async (req, res) => {
  const searchTerm = req.body.query;
  // VULNERABLE: Direct interpolation of user input
  const sql = SELECT * FROM documents WHERE content LIKE '%${searchTerm}%';

  try {
    const results = await db.query(sql);
    res.json({ results });
  } catch (err) {
    res.status(500).json({ error: "Database error" });
  }
});

What's wrong here?
By not using prepared statements or escaping user input, an attacker can craft inputs that mess with the SQL, leading the server to run commands it shouldn't.

Suppose the endpoint above is live. An attacker can send something like this in the JSON body

{
  "query": "%' OR 1=1; -- "
}

The SQL statement becomes

SELECT * FROM documents WHERE content LIKE '%%' OR 1=1; -- %'

- OR 1=1 always evaluates to true, so the query will return all documents—even those that were meant to stay secret!
- The -- starts an inline comment in SQL, which tells the database to ignore the rest of the line, breaking out of whatever structure the original query expected.

More Sinister Attacks

Depending on the database privileges, an attacker might not just read data—they could update or even delete it:

{
  "query": "%'; DROP TABLE users; -- "
}

Now the SQL would become

SELECT * FROM documents WHERE content LIKE '%%'; DROP TABLE users; -- %'

This would delete your users table if the SQL engine ran both statements (some setups allow it, some don't).

The Fixed Version

The maintainers fixed this as of release ..1 by switching to parameterized queries or using an ORM that automatically escapes input.

Here's a safe version using placeholder syntax with db.query

// SAFE: Using parameterized queries
app.post('/api/search', async (req, res) => {
  const searchTerm = %${req.body.query}%;
  const sql = SELECT * FROM documents WHERE content LIKE ?;

  try {
    const results = await db.query(sql, [searchTerm]);
    res.json({ results });
  } catch (err) {
    res.status(500).json({ error: "Database error" });
  }
});

Bottom line: User input is never directly embedded into SQL. It's passed as a parameter and the database handles escaping, defeating injection.

Upgrade immediately to v..1 or later:

Release ..1 on GitHub

If you build web apps:

Always use parameterized queries or ORM libraries for database operations. Never interpolate untrusted input directly.

GitHub Security Advisory:

https://github.com/mintplex-labs/anything-llm/security/advisories/GHSA-9fjx-gg9g-vw2p

Official CVE:

NVD CVE-2023-4899

Release Note Fix:

https://github.com/mintplex-labs/anything-llm/releases/tag/..1

OWASP SQL Injection Cheat Sheet:

https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Final Thoughts

CVE-2023-4899 shows that even exciting new projects can make classic mistakes. If you ever see SQL built from user-controlled input, stop and refactor—no exceptions. Security is everyone's responsibility—even in the AI era.

Timeline

Published on: 09/12/2023 00:15:00 UTC
Last modified on: 09/13/2023 03:51:00 UTC