CVE-2025-7647: LlamaIndex Core insecure /tmp dir,

Q: Is CVE-2025-7647 actively exploited?

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

Q: How to fix CVE-2025-7647?

1. Upgrade llama-index-core to 0.13.0 or later (patch relocates cache to a user-specific XDG directory). 2. Immediate workaround pre-patch: set LLAMA_INDEX_CACHE_DIR environment variable to a user-owned path (e.g., ~/.cache/llama_index) in all process environments running llama-index. 3. Audit existing /tmp/llama_index directories on shared systems for unauthorized reads or modified embedding files. 4. On shared systems lacking immediate patch capability: enforce directory permissions via ACLs or restrict /tmp via a dedicated tmpfs mount with noexec and per-user isolation. 5. Detection: monitor /tmp/llama_index for cross-user access patterns using auditd rules (e.g., -w /tmp/llama_index -p rwa -k llamaindex_access) or inotifywait alerts.

Q: What systems are affected by CVE-2025-7647?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, agent frameworks, embedding pipelines, model serving.

Q: What is the CVSS score for CVE-2025-7647?

CVE-2025-7647 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.13%.

CISO Take

Any multi-user Linux system running llama-index is exposed to local cache theft and embedding poisoning via the predictable /tmp/llama_index path. Upgrade to llama-index-core 0.13.0 immediately; containerized or single-user cloud deployments carry minimal risk. Shared research clusters, JupyterHub environments, and multi-tenant ML platforms are the highest priority for remediation.

What is the risk?

Risk is medium-high for multi-user Linux environments (HPC clusters, JupyterHub, shared ML workstations) but low for containerized deployments where each container runs as a single user. CVSS 7.3 reflects high confidentiality and integrity impact offset by a local-only attack vector. EPSS of 0.00017 indicates no active exploitation at CVE publication, but exploitation is trivial once local access is obtained—no AI/ML expertise required. Organizations running llama-index on shared infrastructure should treat this as a high-priority patch given the sensitivity of cached AI artifacts.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LlamaIndex Core	pip	< 0.13.0	`0.13.0`
50.2K 1.2K dependents Pushed 4d ago 100% patched ~50d to patch Full package profile →

Do you use LlamaIndex Core? You're affected.

How severe is it?

CVSS 3.1

7.3 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 3% 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 Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A Low

What should I do?

5 steps

Upgrade llama-index-core to 0.13.0 or later (patch relocates cache to a user-specific XDG directory).
Immediate workaround pre-patch: set LLAMA_INDEX_CACHE_DIR environment variable to a user-owned path (e.g., ~/.cache/llama_index) in all process environments running llama-index.
Audit existing /tmp/llama_index directories on shared systems for unauthorized reads or modified embedding files.
On shared systems lacking immediate patch capability: enforce directory permissions via ACLs or restrict /tmp via a dedicated tmpfs mount with noexec and per-user isolation.
Detection: monitor /tmp/llama_index for cross-user access patterns using auditd rules (e.g., -w /tmp/llama_index -p rwa -k llamaindex_access) or inotifywait alerts.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Data Extraction Model Poisoning Supply Chain Framework RAG AML.T0007 - Discover AI Artifacts AML.T0020 - Poison Training Data AML.T0035 - AI Artifact Collection AML.T0037 - Data from Local System AML.T0048.004 - AI Intellectual Property Theft

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9.3 - Information security in AI system lifecycle

NIST AI RMF

MANAGE-2.2 - Mechanisms to sustain the value of AI systems

OWASP LLM Top 10

LLM03 - Supply Chain

Frequently Asked Questions

What is CVE-2025-7647?

Any multi-user Linux system running llama-index is exposed to local cache theft and embedding poisoning via the predictable /tmp/llama_index path. Upgrade to llama-index-core 0.13.0 immediately; containerized or single-user cloud deployments carry minimal risk. Shared research clusters, JupyterHub environments, and multi-tenant ML platforms are the highest priority for remediation.

Is CVE-2025-7647 actively exploited?

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

How to fix CVE-2025-7647?

1. Upgrade llama-index-core to 0.13.0 or later (patch relocates cache to a user-specific XDG directory). 2. Immediate workaround pre-patch: set LLAMA_INDEX_CACHE_DIR environment variable to a user-owned path (e.g., ~/.cache/llama_index) in all process environments running llama-index. 3. Audit existing /tmp/llama_index directories on shared systems for unauthorized reads or modified embedding files. 4. On shared systems lacking immediate patch capability: enforce directory permissions via ACLs or restrict /tmp via a dedicated tmpfs mount with noexec and per-user isolation. 5. Detection: monitor /tmp/llama_index for cross-user access patterns using auditd rules (e.g., -w /tmp/llama_index -p rwa -k llamaindex_access) or inotifywait alerts.

What systems are affected by CVE-2025-7647?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, agent frameworks, embedding pipelines, model serving.

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

CVE-2025-7647 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.13%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesagent frameworksembedding pipelinesmodel serving

MITRE ATLAS Techniques

AML.T0007 Discover AI Artifacts

AML.T0020 Poison Training Data

AML.T0035 AI Artifact Collection

AML.T0037 Data from Local System

AML.T0048.004 AI Intellectual Property Theft

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.9.3

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

The llama-index-core package, up to version 0.12.44, contains a vulnerability in the `get_cache_dir()` function where a predictable, hardcoded directory path `/tmp/llama_index` is used on Linux systems without proper security controls. This vulnerability allows attackers on multi-user systems to steal proprietary models, poison cached embeddings, or conduct symlink attacks. The issue affects all Linux deployments where multiple users share the same system. The vulnerability is classified under CWE-379, CWE-377, and CWE-367, indicating insecure temporary file creation and potential race conditions.

Exploitation Scenario

On a shared HPC cluster running JupyterHub, an attacker with a low-privilege account discovers /tmp/llama_index is world-readable. They enumerate cached embedding files from a co-tenant's RAG pipeline, extracting vectors that encode sensitive internal document content. In a more aggressive variant, the attacker pre-creates /tmp/llama_index as a symlink to a victim-writable sensitive directory before the victim initializes llama-index, causing subsequent cache writes to corrupt target files. In the most impactful scenario, the attacker replaces cached embedding files with adversarially crafted vectors designed to alter RAG retrieval behavior—silently poisoning the victim's AI assistant to surface attacker-controlled content in responses, with no observable errors from the application layer.

Weaknesses (CWE)

CWE-378 Creation of Temporary File With Insecure Permissions Primary

CWE-378 — Creation of Temporary File With Insecure Permissions: Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.

[Requirements] Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.
[Implementation] Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process that owns the file.

Source: MITRE CWE corpus.