CVE-2025-1793: LlamaIndex SQL injection

CISO Take

Critical SQL injection (CVSS 9.8) in llama_index vector store integrations allows unauthenticated attackers to read and write data across tenant boundaries in any web application built on this framework. If your RAG pipelines or AI agents use llama_index with SQL-backed vector stores and are internet-exposed, treat this as an active breach risk now. Upgrade to llama_index 0.12.28 immediately and audit all SQL-backed vector store configurations.

What is the risk?

CVSS 9.8 with no authentication, no user interaction, and network-level exploitation makes this the highest-priority patch in any llama_index deployment. EPSS of 0.0002 indicates no confirmed active exploitation yet — but the attack surface is large and the technique is trivial. Blast radius is deployment-dependent: multi-tenant SaaS platforms using llama_index face severe cross-tenant data exposure risk, while internal single-tenant deployments face reduced but non-zero exposure. Both read and write capability means full data compromise and RAG poisoning are within scope of a single exploit.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LlamaIndex	pip	< 0.12.28	`0.12.28`
50.2K 238 dependents Pushed 4d ago 87% patched ~50d to patch Full package profile →

Do you use LlamaIndex? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 43% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

5 steps

IMMEDIATE

Upgrade llama-index to >= 0.12.28 (pip install 'llama-index>=0.12.28'). Verify with pip show llama-index.
AUDIT

Identify all llama_index deployments using SQL-backed vector stores — check VectorStoreIndex configurations for PostgreSQL, MySQL, or other SQL backends.
DETECTION

Review database logs for anomalous SQL patterns, UNION-based queries, or unexpected cross-user data access around the exposure window.
WORKAROUND (if patch not immediately possible): Place llama_index API endpoints behind authentication and restrict access to trusted users only; deploy WAF rules targeting SQL injection patterns on AI query endpoints.
POST-PATCH: Audit vector store contents for injected or tampered entries that could poison RAG retrieval.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Data Leakage Supply Chain Framework RAG AML.T0010.001 - AI Software AML.T0025 - Exfiltration via Cyber Means AML.T0049 - Exploit Public-Facing Application AML.T0070 - RAG Poisoning AML.T0085.000 - RAG Databases

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.6.2.8 - Information security for AI systems

NIST AI RMF

MANAGE 2.2 - Risk Treatment — AI Risks Addressed

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2025-1793?

Critical SQL injection (CVSS 9.8) in llama_index vector store integrations allows unauthenticated attackers to read and write data across tenant boundaries in any web application built on this framework. If your RAG pipelines or AI agents use llama_index with SQL-backed vector stores and are internet-exposed, treat this as an active breach risk now. Upgrade to llama_index 0.12.28 immediately and audit all SQL-backed vector store configurations.

Is CVE-2025-1793 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-1793, increasing the risk of exploitation.

How to fix CVE-2025-1793?

1. IMMEDIATE: Upgrade llama-index to >= 0.12.28 (pip install 'llama-index>=0.12.28'). Verify with pip show llama-index. 2. AUDIT: Identify all llama_index deployments using SQL-backed vector stores — check VectorStoreIndex configurations for PostgreSQL, MySQL, or other SQL backends. 3. DETECTION: Review database logs for anomalous SQL patterns, UNION-based queries, or unexpected cross-user data access around the exposure window. 4. WORKAROUND (if patch not immediately possible): Place llama_index API endpoints behind authentication and restrict access to trusted users only; deploy WAF rules targeting SQL injection patterns on AI query endpoints. 5. POST-PATCH: Audit vector store contents for injected or tampered entries that could poison RAG retrieval.

What systems are affected by CVE-2025-1793?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, agent frameworks, LLM application frameworks, multi-tenant AI platforms.

What is the CVSS score for CVE-2025-1793?

CVE-2025-1793 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.58%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasesagent frameworksLLM application frameworksmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0025 Exfiltration via Cyber Means

AML.T0049 Exploit Public-Facing Application

AML.T0070 RAG Poisoning

AML.T0085.000 RAG Databases

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.8

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Multiple vector store integrations in run-llama/llama_index version v0.12.21 have SQL injection vulnerabilities. These vulnerabilities allow an attacker to read and write data using SQL, potentially leading to unauthorized access to data of other users depending on the usage of the llama-index library in a web application.

Exploitation Scenario

An unauthenticated attacker targeting a multi-tenant RAG platform built on llama_index sends a crafted query containing SQL injection payloads to the application's document search or retrieval endpoint. The malicious input passes through llama_index's vector store integration unsanitized and is interpolated directly into a SQL query. Using UNION-based SQL injection, the attacker dumps the full contents of the vector store — including document chunks indexed for other tenants — exfiltrating proprietary data, PII, or credentials embedded in indexed documents. In a second phase, the attacker uses the write path to inject poisoned document chunks into the vector store, causing the RAG system to return attacker-controlled content to victim users and silently manipulating AI-generated outputs.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.