LlamaIndex SQL Injection in Vector Stores - CVE-2025-1793
CVE-2025-1793 is a Critical SQL injection in LlamaIndex, in the llama-index package's vector store integrations. Multiple integrations fail to sufficiently sanitize or escape user-controllable input before it is incorporated into SQL commands, so an attacker can execute arbitrary SQL - reading or modifying data, and accessing other users' data when the library backs a web application. The weakness is classed as CWE-89 and tracked as GHSA-v3c8-3pr6-gr7p. It affects llama-index below 0.12.28, was observed in v0.12.21, and is fixed in 0.12.28. This advisory covers what the flaw exposes, why a RAG data framework is an agentic-endpoint risk, and how Anomity surfaces and governs the agents that drive it.
What happened
LlamaIndex is a data framework for retrieval-augmented generation and AI agents. It indexes documents into a vector store and retrieves relevant chunks at query time, and its many vector store integrations translate a retrieval request into calls against the backing database. Those integrations are where the trust boundary breaks in this advisory.
In affected versions, several vector store integrations do not sufficiently sanitize or escape user-controllable input before incorporating it into SQL commands. That lets an attacker supply a crafted value that is interpreted as SQL rather than data. The result is arbitrary SQL execution: an attacker can read or modify data, and where the library backs a multi-tenant web application, reach other users' data across what should be an isolation boundary.
The flaw is not confined to a single class. It spans multiple vector store integrations, so exposure depends on which integration a given service imports rather than on one obvious call site. The advisory does not enumerate the specific class names, so the reliable way to scope it is by package and version, not by guessing which store an agent uses.
| Detail | Value |
|---|---|
| Identifier | CVE-2025-1793 (GHSA-v3c8-3pr6-gr7p) |
| Type | SQL injection (CWE-89), user input incorporated into SQL |
| Severity | Critical |
| Package | llama-index (pip) |
| Component | Multiple vector store integrations |
| Affected | llama-index < 0.12.28 (observed in v0.12.21) |
| Fixed in | 0.12.28 |
Why this is an agentic-endpoint risk
LlamaIndex is a core RAG and AI-agent data framework, and its vector store integrations sit directly between the agent and the databases it queries. A RAG agent's whole job is to take a natural-language request and turn it into a retrieval query, so when that input reaches the SQL layer without sanitization, the agent itself becomes the path that carries the injection. The same tool argument or user prompt that looks like an ordinary question can carry SQL that reads or modifies data, or crosses tenant boundaries.
That reachability is the risk. The injection is driven by the request: an agent passing an unsanitized value through an affected vector store integration, whether by an ordinary user's input, through a poisoned tool definition, or as a deliberate attack, can steer a benign-looking retrieval into arbitrary SQL. Application and database controls see the query, but cannot tell you which agents on which endpoints depend on an affected llama-index build, or which retrieval paths run through the vulnerable integrations.
This is the same artifact-layer blind spot we track across the framework cluster, from unsafe deserialization in LangChain to agent code injection in Flowise and the proxy URL SSRF in Gradio. The injection-to-SQL pattern also mirrors the pre-auth SQL injection in LiteLLM at the gateway layer. The framework is one node in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping a framework flaw like this one. For the full cluster context, see the pillar on securing AI agent frameworks.
How Anomity surfaces and governs it
Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2025-1793 that means the AI agents and CLIs that depend on llama-index are catalogued alongside the endpoints they run on, so you can answer "which agents import LlamaIndex, and which endpoints still run a build below 0.12.28" from the fleet inventory instead of grepping repositories by hand.
On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a retrieval or tool call routed through an unvetted vector store path can be denied or logged in line rather than discovered after an injected query has already run. Anomity collects metadata only and redacts secrets on the endpoint, so the content of a query and any credentials it touches never pass through Anomity.
Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents ran retrieval, when, and through which endpoints. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.
Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them. It adds the agentic-endpoint layer those tools cannot see. See how it works and how Anomity compares for where it fits.
What to check across your fleet
- Identify every service, agent, and endpoint that imports llama-index and record the exact version; treat anything below 0.12.28 as affected.
- Upgrade llama-index to 0.12.28 or later everywhere, prioritizing any deployment that backs a multi-tenant or internet-facing web application.
- Enumerate which vector store integrations each RAG pipeline uses, and confirm none run on an affected build now that class names are not published.
- Trace how user and agent input reaches the vector store layer, and ensure retrieval parameters are parameterized rather than concatenated into SQL.
- Review database logs for anomalous or cross-tenant queries originating from RAG retrieval paths during the affected window.
- Enumerate which AI agents and CLIs can trigger retrieval through the affected framework, using a fleet-wide AI artifact inventory.
- Confirm hook-based allow/deny/log enforcement is active on agents that drive LlamaIndex retrieval, so an unvetted query path can be blocked before it runs.
- Restrict the database credentials used by RAG services to the least privilege each pipeline needs, limiting the blast radius of any injected SQL.
CVE-2025-1793 turns an ordinary RAG retrieval into an arbitrary-SQL primitive that can cross tenant boundaries, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing AI agent frameworks. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.
Frequently asked questions
What is CVE-2025-1793 in LlamaIndex?
CVE-2025-1793, tracked as GHSA-v3c8-3pr6-gr7p, is a Critical SQL injection (CWE-89) in the llama-index package. Several of its vector store integrations do not sufficiently sanitize or escape user-controllable input before incorporating it into SQL commands. An attacker can execute arbitrary SQL, which can read or modify data and access other users' data when the library backs a web application. The issue affects llama-index below 0.12.28 and was observed in v0.12.21. It is fixed in 0.12.28, so upgrading to 0.12.28 or later is the primary remediation. Until then, treat any RAG query path that reaches an affected vector store as an untrusted SQL surface.
Which versions of llama-index are affected?
The flaw affects llama-index below version 0.12.28, and the issue was observed in v0.12.21. It is fixed in 0.12.28. Because the weakness lives in multiple vector store integrations rather than a single class, the safest approach is to pin every service and endpoint that imports llama-index to 0.12.28 or later, not just the ones you believe are exposed. The advisory does not enumerate the specific integration class names, so inventory by package and version rather than by trying to guess which store a given agent uses.
Why does a RAG SQL injection matter for AI agents?
LlamaIndex is a core framework for retrieval-augmented generation and AI agents, and its vector store integrations sit between the agent and the database. A RAG agent turns a natural-language request into a retrieval query, and if that input reaches the SQL layer without sanitization, the agent becomes the delivery path for injection. The same prompt or tool argument that looks like a benign question can carry SQL that reads or modifies data or crosses tenant boundaries. That makes the injection an agentic-endpoint problem, not just an application bug, because the agent is what carries untrusted input into the query.
How does Anomity help with a framework flaw like this?
Anomity inventories the AI agents, CLIs, and other AI artifacts on each managed endpoint, so you can find which agents depend on llama-index and which endpoints still run a build below 0.12.28. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, so a retrieval call routed through an unvetted vector store path can be denied or logged in line. Every decision lands in a queryable 90-day audit trail, and Anomity collects metadata only, so the content of a query is never stored by Anomity while you still get the timeline to scope exposure.
