llama_index CVE-2025-7707
HIGHSeverity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local account needed (AV:L, PR:L) to write the world-writable shared dir; tamper-to-execution in a victim's context yields full C/I/A, though C:H assumes the priv-esc chain succeeds.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
2DescriptionNVD
The llama_index library version 0.12.33 sets the NLTK data directory to a subdirectory of the codebase by default, which is world-writable in multi-user environments. This configuration allows local users to overwrite, delete, or corrupt NLTK data files, leading to potential denial of service, data tampering, or privilege escalation. The vulnerability arises from the use of a shared cache directory instead of a user-specific one, making it susceptible to local data tampering and denial of service.
AnalysisAI
Local privilege escalation and denial of service in llama_index 0.12.33 arising from its default configuration of a world-writable, shared NLTK data directory inside the codebase. The flaw requires a multi-user host with a local unprivileged account able to write to that shared path (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8, CWE-377); an attacker can overwrite, delete, or corrupt NLTK data files, causing tampering or DoS, with escalation to higher-privileged processes possible if a more privileged user or service later loads the poisoned data. No confirmed active exploitation (not in CISA KEV), though publicly available exploit code exists and an upstream fix commit is published; EPSS is low at 0.19% (8th percentile), and the risk is genuine but context-limited rather than a remotely exploitable emergency.
Technical ContextAI
llama_index is a Python framework for building LLM/RAG applications that depends on NLTK for tokenization and text preprocessing. Per CWE-377 (Insecure Temporary File) the root cause is unsafe handling of a shared, writable data location: version 0.12.33 points NLTK's data directory (NLTK_DATA) at a subdirectory of the llama_index codebase rather than a per-user or permission-restricted path. On multi-user systems this location is world-writable, so any local account can place, replace, or remove NLTK corpus/model files that a different process will later load. The CPE entry cpe:2.3:a:llamaindex:llamaindex:*:*:*:*:*:*:*:* indicates the package identifier covers the affected library; the fix is an upstream commit that changes how the NLTK data directory is selected. Because the tampered artifacts are consumed as trusted data rather than executable input, impact manifests first as data tampering and denial of service, and can extend to privilege escalation only when a higher-privileged invocation of llama_index loads the attacker-controlled files.
RemediationAI
Upgrade llama_index to a release containing the upstream fix; the vendor-provided patch is the commit at https://github.com/run-llama/llama_index/commit/98816394d57c7f53f847ed7b60725e69d0e7aae4 (referenced by NVD), and the vulnerability report at https://huntr.com/bounties/3fe2c8ab-6727-4aef-a0ef-4d2818e48803 documents the affected default configuration - confirm the exact patched release version with the vendor or PyPI before deployment, since only the commit SHA is provided here. If upgrading immediately is not possible, set the NLTK_DATA environment variable to a per-user directory (for example under the invoking user's home) or a path writable only by the owning account and root, and ensure the default in-codebase directory is not world-writable; the trade-off is that each user or service account must maintain its own NLTK corpora, which increases disk usage and may alter application startup behavior or fail if the corpora are missing. On multi-user hosts, remove write permission for other users on any shared llama_index/NLTK data location (chmod/chown) and treat the corpora as trusted, root-owned assets, accepting that unprivileged application users can no longer self-download or update NLTK data. Additionally, avoid running llama_index workloads as privileged accounts on shared hosts, since the escalation path depends on a higher-privileged process loading tampered NLTK files.
More in Llamaindex
View allA SQL injection vulnerability exists in the `duckdb_retriever` component of the run-llama/llama_index repository, specif
A vulnerability in the FinanceChatLlamaPack of the run-llama/llama_index repository, versions up to v0.12.3, allows for
SQL injection in llama_index DuckDB vector store v0.12.19. PoC and patch available.
Critical SQL injection vulnerability affecting run-llama/llama_index v0.12.21 and potentially other versions, present in
A command injection vulnerability exists in the run-llama/llama_index repository, specifically within the safe_eval func
LlamaIndex (aka llama_index) through 0.9.34 allows SQL injection via the Text-to-SQL feature in NLSQLTableQueryEngine, S
An issue in llama_index v.0.7.13 and before allows a remote attacker to execute arbitrary code via the `exec` parameter
A command injection vulnerability exists in the RunGptLLM class of the llama_index library, version 0.9.47, used by the
Denial-of-service in LlamaIndex (run-llama/llama_index) versions up to and including 0.12.2 lets remote unauthenticated
Arbitrary code execution in LlamaIndex (run-llama/llama_index) versions up to and including 0.11.6 occurs when BGEM3Inde
A critical deserialization vulnerability exists in the run-llama/llama_index library's JsonPickleSerializer component, a
A Denial of Service (DoS) vulnerability has been identified in the KnowledgeBaseWebReader class of the run-llama/llama_i
Same weakness CWE-377 – Insecure Temporary File
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today