LlamaIndex Download Integration exec() Code Injection
LlamaIndex versions before 0.10.38 have a code loading feature that builds and runs Python code using an attacker-supplied class name. If that class name contains injected code, LlamaIndex executes it. This rule looks for command lines that show this exploit actually being run.
How the attack works
An attacker crafts a 'class_name' value that isn't just a class name but includes chained Python statements, such as a semicolon followed by import, exec, eval, os.system, or subprocess calls. They pass this value through LlamaIndex's download or integration loading path (download_loader, download/integration, module_utils), which is vulnerable because it uses exec() to dynamically import classes without validating the input. When LlamaIndex processes this value, the injected code runs with the same privileges as the LlamaIndex process, giving the attacker arbitrary code execution on the host.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3a9c2e-4b6d-4a1f-9c3e-8d2f5b7a1e60
- Severity
- Critical
Why it matters
Successful exploitation gives an attacker arbitrary code execution on the machine running the vulnerable LlamaIndex application, which can lead to data theft, lateral movement, or full host compromise.
What you can do
- →Upgrade llama_index to 0.10.38 or later, which removes this exec()-based loading behavior.
- →Audit any code that calls download_loader or similar dynamic-import functions with user- or externally-supplied input, and remove or sandbox that path if untrusted input can reach it.
- →Treat command lines that reference llama_index download machinery alongside exec/eval/os.system/subprocess as high-priority alerts, but confirm with your team before escalating if it matches known internal QA or scanner activity.
- →Restrict the privileges of the process running LlamaIndex so a successful exec() injection has limited blast radius.
Known benign look-alikes
- Internal QA or regression tests that intentionally reproduce the CVE PoC against a patched build to confirm a fix, reusing the same command-line shape as the public exploit
- Security tooling (SAST/DAST scanners, fuzz harnesses) that spawns processes with literal exec()/os.system()/eval() strings embedded in test payloads while probing the download_loader/module_utils code path
- Developers grepping, printing, or piping the vulnerable source file (download/integration.py, module_utils.py) together with example exploit strings while writing a patch, advisory, or blog post about this CVE