We ran CodeSlick across run-llama/LlamaIndexTS — 3,813 findings across 498 files. Prototype pollution and command injection appear across the codebase. The Postgres KV store has SQL injection in production code. Here is what the leading TypeScript RAG and agent framework looks like from a security scanner.
LlamaIndex is the most widely used framework for building RAG pipelines and agent workflows in TypeScript. If you are building AI applications with Cursor or Claude, there is a good chance LlamaIndex is somewhere in your dependency tree. The framework abstracts over vector stores, document loaders, query engines, and LLM providers — which means a single vulnerability pattern in the framework propagates across every application that uses it. We cloned run-llama/LlamaIndexTS at the latest commit and ran codeslick scan --all. 498 files. 3,813 findings. Here is what the scanner found.
Prototype pollution appears in 82 locations across two files: the bundled RAKE keyword extraction library at packages/llamaindex/src/internal/deps/rake-modified.js and the memfs in-memory filesystem implementation at packages/env/src/fs/memfs/index.js. Both are vendored dependencies — third-party code that the LlamaIndex team pulled in and ships as part of the package.
Prototype pollution lets an attacker inject properties into Object.prototype, which then appear on every object in the JavaScript runtime. In a RAG pipeline, this is not abstract: if user-supplied document content reaches one of these code paths — and document loaders exist precisely to accept user-supplied content — an attacker could manipulate behavior in the query engine, the retriever, or any object that checks for property existence using patterns likeobj.hasOwnProperty orkey in obj. The concentration in vendored dependencies means upstream patches will not reach these files automatically.
Command injection appears in 10 locations. Four are in the end-to-end smoke test harness at e2e/node/smoke.e2e.ts — test infrastructure, not shipped production code, though test runners with access to CI secrets are still an attack surface. The more relevant finding is inpackages/core/src/node-parser/markdown.ts at line 29, flagged by the static analyzer as a potential command injection finding (CWE-78) in the markdown node parser. The scanner applies conservative pattern matching for this check class, so manual review is needed to confirm exploitability in context. Five additional findings live in the vendored memfs implementation (packages/env/src/fs/memfs/index.js), where child_process.exec() calls appear with inputs that are not sanitized before execution.
For applications that accept documents from external sources and pass them through the MarkdownNodeParser, the risk is direct: malformed markdown could reach the parser with content crafted to exploit pattern-matching behavior. The memfs findings matter specifically in server-side Node.js deployments where the in-memory filesystem is used for document staging.
The PostgresKVStore implementation at packages/providers/storage/postgres/src/PostgresKVStore.ts has two SQL injection findings at lines 130 and 144. The get() and getAll() methods construct SQL queries using template literals that interpolate this.schemaName andthis.tableName directly into the query string:
// PostgresKVStore.ts line 130 — flagged as SQL injection
const sql = `SELECT * FROM ${this.schemaName}.${this.tableName} WHERE key = $1`;The parameterized $1 and $2 bindings protect the key and collection values — but schemaName and tableName are injected via string interpolation. If those values come from application configuration that accepts user input — a multi-tenant RAG deployment where callers supply their own schema or table name — this is a textbook SQL injection vector. The scanner is correct to flag it: schema and table identifiers cannot be parameterized using standard pg bindings, and the fix requires explicit identifier sanitization using a library like pg-format or hardcoded values validated against an allowlist.
The OpenAI live session provider at packages/providers/openai/src/live.ts has two SSRF findings at lines 45 and 62. Both build fetch URLs from the caller-supplied baseURL parameter in the constructor config. If an application accepts a configurable base URL and does not validate it against an allowlist, an attacker can redirect the LLM provider calls to an internal service — a metadata endpoint, an internal API, or a local Redis instance — instead of the OpenAI API. The constructor defaults to https://api.openai.com/v1/realtime, but the baseURL field accepts arbitrary values with no validation.
Three hardcoded credential findings across the monorepo:
packages/providers/vllm/src/llm.ts:22 — hardcoded credential in the vLLM provider.docs/src/components/ProtectedContent.jsx:3 — hardcoded credential in the documentation component. Documentation code shipped in the same monorepo is a credential exposure path that gets ignored precisely because it lives outside the main packages.e2e/node/vector-store/pg-vector-store.e2e.ts:67 — Heroku API key pattern matched in test infrastructure. Lower priority for triage (test file, not production), but a real pattern match included for completeness.These findings are in the framework code, not your application code. Some represent inherited risk — vulnerabilities in a library you call that could affect your application depending on how inputs are passed. Others indicate patterns that propagate into application code through API design choices or example code that developers copy.
The SQL injection in PostgresKVStore is the most actionable: if you use the Postgres storage provider in a multi-tenant setup and your application code supplies the schema or table name from request parameters, you need to add identifier sanitization before those values reach the KV store constructor. The prototype pollution findings in vendored files require manual patching — a npm update will not fix them because the affected code is copied into the repository, not installed as a dependency.
The practical question is not whether LlamaIndex has security issues — every large codebase does — but whether you know what you are inheriting when you add it to your stack. Running a scan takes under a minute. Not running one means you find out at incident time.
The scanner also flagged 49 instances of unsafe JSON parsing (JSON.parse() without try/catch error handling) — these are quality issues that can cause unhandled exceptions when upstream data is malformed, but are generally lower priority than the injection categories above.
We cloned run-llama/LlamaIndexTS at the latest commit and ran codeslick scan --all— the same command any developer can run in under a minute. No custom configuration, no false-positive filtering beyond CodeSlick's built-in precision layer. All findings in this report are from the default scan.
Run the same analysis on your codebase or any npm package. No account required.
Try CodeSlick Free