CVE-2025-7707

What it actually does

The library configures NLTK data to a shared subdirectory of the installation that is world-writable on multi-user systems, allowing any local user to overwrite, delete or corrupt cached NLTK resources and thereby trigger denial of service, data tampering or privilege escalation when the library later loads those resources.

Why it matters to the business

Applications built on llama_index running in shared or multi-tenant environments face service interruptions, corrupted model behavior, and possible lateral movement, increasing operational risk on shared infrastructure even though the flaw is not known to be exploited in the wild.

How an attack unfolds

An attacker with a local account on the same system locates the world-writable NLTK cache directory used by llama_index, replaces or deletes NLTK data files with malicious or empty content, and waits for any process using llama_index to load the tampered data, resulting in crashes, incorrect outputs or escalated privileges.

How to fix it

Upgrade run-llama/llama_index to commit 98816394d57c7f53f847ed7b60725e69d0e7aae4 or later; SUSE Linux Enterprise Server 12-LTSS and SAP Application 12 customers must apply kgraft-patch-SLE12_Update_16 version 6-2.1 or newer. Until patches are deployed, configure NLTK data to a user-specific directory outside the shared installation tree.

How to confirm the fix worked

Confirm the installed llama_index commit is at or beyond 98816394d57c7f53f847ed7b60725e69d0e7aae4, verify that NLTK_DATA or the internal cache path resolves to a per-user location, and test that non-privileged users cannot write to the directory used by the library.

Typical attack path

1. Obtain a local shell on a multi-user host running an affected version of llama_index
2. Discover the NLTK data path under the library installation directory
3. Overwrite or delete NLTK resource files with attacker-controlled content
4. Trigger any application that imports llama_index so it loads the corrupted data
5. Observe denial of service, tampered outputs, or attempt privilege escalation via the resulting process behavior

How to detect it

Review file-integrity monitoring logs for unexpected changes inside the NLTK data directory under the llama_index installation; inspect process execution and library import logs for sudden failures or altered behavior after local user activity; correlate with authentication events showing multiple users on the same host.

What your security team should do

• Immediately schedule upgrade of all llama_index deployments to the fixed commit
• Audit shared hosts and containers for world-writable cache directories under Python package paths
• Enforce per-user NLTK data directories via environment variables in all production workloads
• Add package-version checks to CI/CD pipelines to block vulnerable releases