🛡️ JDP Security Research Archive ⬅️ Back to Vulnerability Disclosures & Technical White Papers

⚠️ SECURITY ADVISORY: Organizations utilizing LlamaIndex (llama-index-core v0.14.19 and below) are operating with a critical, unmitigated Remote Code Execution (RCE) and Permanent Denial of Service (DoS) vulnerability. Despite this finding being initially classified by the vendor as “Not Applicable,” forensic audit confirms an undocumented remediation was executed across v0.14.20 and v0.14.21. Because no formal CVE was issued, legacy deployments remain invisible to enterprise Software Composition Analysis (SCA) scanners (e.g., Snyk, Dependabot), creating a persistent supply chain risk.

SECURITY DISCLOSURE | JDP-2026-003

Infrastructure Compromise: Path Traversal and Code Injection in LlamaIndex — Insecure AI Orchestration

Author: Jeff Ponte, CISSP, CCSP, CEH | Lead Researcher, JDP Security
Series: JDP Security Research Series (Disclosure #3)
Initial Disclosure Date: March 27, 2026
Target: LlamaIndex | llama-index-core (v0.14.19 and below)
Case Number: Huntr ID: bb0b2efb-8069-4642-97ec-7060aed7a7b7 (Report marked ‘N/A’ by vendor - requires Huntr account to view details)
CVSS v3.1 Score: 10.0 (Critical) | Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Status: Officially Disputed / Silently Remediated in v0.14.20 and refined in v0.14.21

Executive Summary

This white paper documents a critical architectural flaw in LlamaIndex, an industry-standard AI orchestration framework. This research highlights a validation deficiency where the framework treats stochastic, untrusted Large Language Model (LLM) output as deterministic, high-privilege system commands—specifically regarding file path resolution.

This oversight culminates in a full-chain vulnerability driven by Path Traversal (CWE-22) leading to Code Injection (CWE-94). I demonstrate how an AI agent can be manipulated into escaping its intended sandbox to physically overwrite its own host application’s source code (referred to internally as the “Library Overwrite” vector).

Despite comprehensive Proof of Concept (PoC) recordings demonstrating unauthenticated, LLM-driven host compromise, the maintainers initially disputed the disclosure, stating that environmental security boundaries are a user-side responsibility. However, forensic analysis of the repository’s git history reveals the vendor subsequently executed a coordinated code migration to remediate the vulnerability without issuing a public security advisory.

This research highlights the risks associated with undocumented remediation in the open-source supply chain: where a vulnerability is mitigated under the guise of routine maintenance without formal disclosure. This practice leaves the community in a “False Negative” state, where security tools fail to alert on active threats because no official CVE has been filed, exposing enterprise deployments to unmitigated risk.

Vulnerability Rating & CVSS Justification

Final Score: 10.0 (Critical) Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

1. The Technical Sink: Unsanitized Path Resolution

The vulnerability lies in the framework’s willingness to accept untrusted strings to define local filesystem directories.

1.1 The Directory Sinks (v0.14.19)

The core vulnerability exists at the directory resolution level within llama-index-core/llama_index/core/download/dataset.py. The SDK performs a direct path cast of local_dir_path without anchoring or validation.

By passing a traversal string (e.g., ../../../../etc/cron.d/), an attacker shifts the base directory. Any files written (including the source_files list) are subsequently deposited into the hijacked system path.

Insufficient Security Boundaries: The Filename Registry

During the disclosure process, it was suggested that the DATASET_CLASS_FILENAME_REGISTRY prevented traversal. This assessment is architecturally inaccurate for the following reasons:

  1. The registry only validates the filename, not the directory path.
  2. The directory sink (local_dir_path) is hijacked BEFORE the registry check occurs.
  3. Even if the filename is strictly forced to rag_dataset.json, the payload can still be written to critical locations (e.g., /etc/cron.d/rag_dataset.json).
  4. The registry does not mitigate directory traversal and fails to act as a secure boundary.

2. Exploitation Mechanics

Verified via forensic .cast recordings in an isolated environment.

2.1 Core Library Overwrite (Permanent DoS/RCE)

By targeting the core library’s __init__.py, the exploit replaces executable Python code with malicious payloads.

2.2 Path Hijack RCE

The source_files primitive allows writing arbitrary code payloads to high-privilege directories (e.g., cron jobs or shell profiles).

Proof of Impact: The Supply Chain Risk

Evidence of Widespread Exposure:

SCA Visibility Gaps:

3. Implications for AI/ML Security

This vulnerability highlights fundamental requirements in AI Orchestration Security:

  1. Insecure Output Handling (OWASP LLM02): Untrusted LLM output must be strictly sanitized before being passed to system-level functions.
  2. Broken Sandbox Model: AI frameworks must assume all LLM output is potentially malicious and enforce strict environmental boundaries.
  3. Supply Chain Amplification (OWASP LLM05): Vulnerable AI orchestration components can introduce persistent flaws across entire ML pipelines.
  4. Undocumented Remediation Undermines Trust: Silent security fixes leave the enterprise community unaware of systemic risks and unable to prioritize patching.

The library overwrite vector illustrates how AI agents can be coerced into altering their own execution environment, creating self-propagating denial conditions.

4. Remediation Timeline & Undocumented Patching Strategy

The remediation timeline reveals a pattern of migrating vulnerable code out of the core library without public acknowledgment, masking the security fix within non-security updates.

5. Disclosure Timeline

Actions Taken:

  1. March 27, 2026: Initial disclosure via Huntr with initial .cast recordings provided.
  2. March 28: Technical rebuttal submitted to clarify the architectural limitations of the filename registry.
  3. April 8: Escalation regarding the observed undocumented repository patches.
  4. April 10: Additional .cast recordings submitted.
  5. April 13: Final notice issued before pursuing independent publication.

Vendor Response:

Appendices

Appendix 1: Forensic Proof & Exploitation Mechanics

The Vulnerability: Architectural Collapse via CWE-22 The flaw is a classic Path Traversal (CWE-22) leading to Code Injection (CWE-94). By injecting traversal sequences (../) into dataset or storage parameters, an unauthenticated attacker can escape the intended directory sandbox and physically overwrite the Python interpreter’s own source code.

The Target: site-packages The primary exploit targets the core integrity of the library itself. By pointing the SDK sink at the host’s site-packages/llama_index/core/, an attacker can overwrite the __init__.py file.

Visual proof of the core library overwrite exploit

Figure 1: Visual proof of the library overwrite exploit. The healthy Python module has been physically replaced with a malicious JSON payload. Any subsequent attempt to import the library results in the immediate execution of the attacker’s code.

Forensic Script Repository The following scripts were uploaded to the project repository and utilized to verify the vulnerability across different stages of the research:

Appendix 2: Manual Remediation & Path Anchoring

If your environment cannot be updated to v0.14.21 (or if you are building custom AI agents), you must implement manual Path Anchoring.

Secure Implementation Pattern:

import os
from pathlib import Path

def get_anchored_path(safe_root: str, user_input: str) -> Path:
    """
    Prevents Path Traversal (CWE-22) by resolving and anchoring the final path.
    """
    base_dir = Path(safe_root).resolve()
    target_path = Path(base_dir, user_input).resolve()
    
    if not str(target_path).startswith(str(base_dir)):
        raise PermissionError(f"CRITICAL: Path Traversal Attempt Blocked! {target_path}")
        
    return target_path

Appendix 3: The Primary Exploit PoC (redemption_poc_v2.py)

# Proof of Concept: Hijacking the source_files primitive
from llama_index.core.download.dataset import download_dataset_and_source_files
from unittest.mock import patch

# TARGET: Escape the sandbox to overwrite host crontab
malicious_dir = "../../../../../etc/cron.d/"
malicious_file = "payload"

with patch("llama_index.core.download.dataset.get_file_content") as mock_get, \
     patch("os.makedirs"), patch("builtins.open", create=True) as mock_open:
    
    mock_get.return_value = ("* * * * * root /usr/bin/python3 /tmp/shell.py", None)
    
    download_dataset_and_source_files(
        local_dir_path="/app/safe_zone",
        source_files_dir_path=malicious_dir, 
        source_files=[malicious_file],       
        dataset_id="exploited",
        dataset_class_name="LabelledRagDataset",
        override_path=True
    )
    
    if mock_open.called:
        print(f"[!] VULNERABILITY CONFIRMED: Writing to {mock_open.call_args[0][0]}")

Appendix 4: Detection & Mitigation Checklist

Detection:

Immediate Mitigation:

  1. Upgrade to llama-index-core >= 0.14.21
  2. Implement path validation wrapper (Appendix 2)
  3. Run AI agents with minimal filesystem permissions.

Appendix 5: Independent Verification

To verify this vulnerability:

  1. Install vulnerable version: 
    pip install llama-index-core==0.14.19

  2. Run the PoC scripts provided in this report (redemption_poc_v2.py, exploit.py)

  3. Check for:
    • JSON written to __init__.py in site-packages
    • /tmp/llamaindex_pwned flag file creation
    • Ability to write to arbitrary directories

Appendix 6: Forensic Recording Demonstration Breakdown (Chronological)

This section serves as the forensic artifacts for the JDP Security disclosure.

1. nuke-llama-core

Supporting Files:

2. llama-nuke-2

Supporting Files:

3. llama-nuke-3

Supporting Files:

4. llama-rce-final2

Supporting Files:

5. llama_final_v1

Supporting Files: