Critical SQL Injection Vulnerability in LlamaIndex (CVE-2025-1793) – Advisory and Analysis
The critical SQL injection vulnerability in LlamaIndex shows how LLMs can be a backdoor into your vector store
The critical SQL injection vulnerability in LlamaIndex shows how LLMs can be a backdoor into your vector store
The critical SQL injection vulnerability in LlamaIndex shows how LLMs can be a backdoor into your vector store
.png)
The critical SQL injection vulnerability in LlamaIndex shows how LLMs can be a backdoor into your vector store
The critical SQL injection vulnerability in LlamaIndex shows how LLMs can be a backdoor into your vector store
LlamaIndex, a widely used framework for building LLM-powered applications, recently disclosed a critical vulnerability, an SQL injection flaw tracked as GHSA-v3c8-3pr6-gr7p. Now patched in different versions of eight vector-store-specific packages, all released together with LlamaIndex 0.12.28, this issue has far-reaching consequences for any deployment where user inputs pass through an LLM into one of the affected vector store integrations.
In this post, we walk through how the vulnerability works, what makes it dangerous in LLM-centric architectures, and what developers and teams should do next.
What Happened?
Security researchers disclosed a vulnerability via Huntr, along with a proof of concept that showed how basic SQL payloads could be used to compromise vector store operations within LlamaIndex.
At the heart of the issue are methods like vector_store.delete(), which could receive unvalidated inputs, sometimes originating from LLM prompts, and ultimately result in the construction of unsafe SQL queries.
How the Vulnerability Works
Traditionally, SQL injection happens when unsanitized user inputs are inserted into query strings. In this case, however, the LLM acts as a translator between user input and the database, which opens up new attack vectors.
Consider this simplified flow:
- A benign user would submit prompts like "Remove all documents related to project X" to the LLM.
- The LLM generates a call to vector_store.delete("project:X").
- Without input sanitization, this is translated into a raw SQL query.
- A malicious user who is interacting with the chatbot or agent may be able to submit a prompt to the LLM that results in a malicious API call such as vector_store.delete("project:X' OR 1=1 --"). When such strings are executed, they can lead to unintended data exposure, modification, or deletion.
Patch Details
The issue was addressed in LlamaIndex v0.12.28, where sanitization logic was added across several vector store integrations, covering ClickHouse, Couchbase, DeepLake, Jaguar, Lantern, Nile, OracleDB, and SingleStoreDB.
Patch PR: GitHub PR #18316
However, the implementation of the sanitization mechanisms varies from one vector store to the other. Some changes are more rigorous like that for OracleDB (e.g., a whitelist of characters), while others are less rigorous like that for Jaguar (blacklist of characters).
Exploitation in Practice
The PoC provided on Huntr directly calls vector_store.delete(), ignoring the API layer, and then injects it with basic SQL payloads like:
' OR '1'='1
'; DROP TABLE documents; --
Vector stores usually aren’t exposed to users, but that doesn’t mean they’re safe. In a typical RAG setup, the LLM builds the query that hits the vector store. And here’s the catch: a user can give harmless-looking input that tricks the LLM into generating a malicious query. It’s like SQL injection, but the LLM does the dirty work. If your system isn’t built carefully, with things like input sanitization or safe query methods, you might have a serious security hole without realizing it.
The danger becomes acute in pipelines where:
- LLMs act as agents capable of modifying data stores
- Users control input to LLMs without strong filtering
- LLM-generated outputs are executed without strict parsing or validation
Impact Analysis
This vulnerability impacts a wide range of use cases:
- Customer-facing chatbots that allow free-form input from users.
- Autonomous agents using LLMs to orchestrate workflows, especially where deletion or updates to vector stores are permitted.
- Multi-tenant applications where tenants share a common vector store or database backend.
If exploited:
- Sensitive or proprietary data could be exposed.
- Vector indexes could be deleted or poisoned.
- Application functionality may be disrupted due to corrupted retrieval pipelines.
Perhaps most concerning is the invisibility of the attack path. Any applications don't log how an LLM interprets a user's prompt into backend commands, making detection after-the-fact difficult.
Mitigation and Recommendations
1. Upgrade Immediately
The SQLi has been fixed in vector-store-specific packages (e.g., llama-index-vector-stores-jaguar@0.31). Update the respective versions as communicated in the Changelog.
2. Harden Your Application
- Validate inputs that pass through LLMs before reaching any vector store or database layer.
- Use parameterized queries where possible.
- Limit LLM permissions: ensure they cannot directly perform destructive actions or construct raw queries.
Reference: OWASP SQL Injection Prevention Cheat Sheet
3. Monitor and Audit
- Implement application-layer firewalls and SQL activity monitoring.
- Add logging around vector store access and LLM-generated actions.
- Regularly test using tools like Payloadbox SQLi Payload List.
Key Takeaway: LLMs are Attack Surfaces
This vulnerability illustrates a growing security theme: LLMs are not just passive responders, they can become active participants in an attack chain.
Prompt injection is now capable of indirect SQL injection, a form of adversarial programming where the attacker convinces the LLM to generate malicious inputs for the rest of your stack.
The increasing availability of MCP servers, which make new and existing functionality available to LLM-based agents, will accentuate the risk of unsanitized inputs -- expect security researchers to find more and more of such vulnerabilities, and design your systems with such attack vectors in mind.
