# LlamaIndex LangChainLLM stream_complete Type-Confusion DoS Invocation

- **Severity:** Medium
- **Signature ID:** `7c3f9a2e-5d41-4b86-9f0c-2ad81e6b47d3`
- **CVEs:** CVE-2024-12704
- **MITRE ATLAS:** AML.T0029 (Denial of AI Service)
- **OWASP:** LLM10 (Unbounded Consumption)

## Summary

A bug in the LlamaIndex LangChainLLM component lets an attacker crash a background thread by passing a wrongly-typed prompt (a list, dict, number, etc. instead of a string) to stream_complete or astream_complete. Because the error is swallowed silently, the application hangs forever, consuming CPU and memory until it is killed.

## How the attack works

An attacker or script calls LangChainLLM.stream_complete() or astream_complete() and passes something other than a string as the prompt argument. Internally, this spawns a worker thread to run the underlying model call; the wrong type makes that thread die immediately, before it can raise a proper exception. The code waiting for a response never learns the thread failed, so it waits indefinitely, and the process never exits. This detection watches for inline command-line executions (like python -c or a heredoc) that contain this exact pattern: a call to stream_complete/astream_complete with a literal non-string argument, which is the one moment the exploit's setup is directly visible.

## Why it matters

A single crafted call can hang an AI service process indefinitely, tying up CPU and memory and denying service to legitimate users until the process is manually restarted.

## What you can do

- Upgrade or patch llama_index to a version that fixes CVE-2024-12704, or validate that all prompt arguments passed to stream_complete/astream_complete are strings before calling.
- Run LLM-serving processes with resource and time limits (e.g., process timeouts, memory caps, watchdogs) so a hung thread cannot consume resources indefinitely.
- Add exception handling and thread-health checks around any code that spawns worker threads for streaming completions, so failures are detected instead of silently hanging.
- Restrict who can invoke inline code execution (python -c, heredocs) against systems that use llama_index, since this is the visible entry point this detection relies on.

## Known benign look-alikes

- AppSec or platform engineers reproducing CVE-2024-12704 by hand with a one-liner to confirm whether a pinned llama_index version is still vulnerable. Suppressed only when the snippet bounds the call (pytest.raises, signal.alarm, asyncio.wait_for) or runs under a recognised test runner; a bare unbounded reproduction WILL report, which is intended - it hangs the host exactly like the attack does.
- Library maintainers or integrators debugging prompt type coercion in LangChainLLM with inline `python -c` while checking what non-string inputs do.
- Fuzzing and property-based harnesses that intentionally pass non-string prompts. Suppressed via the hypothesis/@given and test-runner filters when those markers are on the same command line; a bespoke fuzzer with none of those markers will report.
- Copy-pasted advisory proof-of-concept executed inside a CI security-validation job that does not invoke a recognised runner.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-12704
- https://attack.mitre.org/techniques/T1499/
- https://atlas.mitre.org/techniques/AML.T0029

---
Source: https://www.netzilo.com/threats/llamaindex-langchainllm-stream-complete-dos