SQL Injection via ref_doc_id in DuckDBVectorStore Delete

How the attack works

An application using llama_index calls delete() on a document, passing a ref_doc_id that came from user input. Because the value is concatenated into the SQL string rather than bound as a parameter, an attacker crafts a ref_doc_id containing extra SQL. That injected SQL can invoke DuckDB's file-handling features — ATTACH DATABASE, COPY, read_csv/read_parquet/read_json, glob, or loading the httpfs extension — to read or write files on the server. This can escalate to remote code execution.

Netzilo detection

Why it matters

An attacker can read sensitive files, write new files (including ones that lead to code execution), or otherwise abuse the host running the vector store, all through a single malicious delete request.

What you can do

• →Upgrade llama_index past the vulnerable DuckDBVectorStore version (affected: v0.12.19) or patch delete() to use parameterized queries.
• →Validate and restrict ref_doc_id input to expected formats (e.g. UUID or hash patterns) before it reaches the database layer.
• →Restrict or disable DuckDB's httpfs extension and file-reading functions (read_csv, read_parquet, ATTACH DATABASE, COPY) in production if not required.
• →Review logs for delete requests containing SQL keywords like ATTACH, UNION SELECT, COPY, or read_csv/read_parquet inside the ref_doc_id field.

Known benign look-alikes

• Administrative or backup scripts that legitimately pair a ref_doc_id filter with COPY ... TO / EXPORT DATABASE to produce CSV or Parquet snapshots of vector store documents.
• Regression or security test suites that submit UNION SELECT / quote-breakout payloads containing ref_doc_id to confirm the vulnerable code path has been patched.
• Database maintenance sessions running PRAGMA database_list or ATTACH DATABASE against the same DuckDB instance while an unrelated ref_doc_id value happens to appear elsewhere in the same logged request or command line.