# Xinference Llama3 Tool-Call eval() RCE Payload

- **Severity:** High
- **Signature ID:** `7c3f9e14-2b6a-4d58-9f0c-5a1e8b47d3ce`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM01 (Prompt Injection), LLM05 (Improper Output Handling)

## Summary

Xinference's Llama3 tool-calling feature runs raw model output through Python's eval(), a design flaw that lets an attacker smuggle malicious Python code inside a chat completion request. If the code contains both a way to escape sandboxing and a command to run or data to steal, the server executes it directly on the host.

## How the attack works

An attacker sends a POST request to a /completions inference endpoint that both requests tool-calling (using fields like tools, tool_choice, or function_call) and includes Python escape code such as __import__, __builtins__, or getattr/eval/compile chains. That escape code is paired with a sink that does something harmful — running system commands (os.system, subprocess, pty.spawn), opening sockets, fetching URLs, or reading sensitive files like /etc or /proc. Because the Llama3 tool-call parser evaluates this raw text with eval(), the payload executes on the Xinference server itself, not just in the conversation. A second detectable stage happens after this succeeds: the Xinference process spawns a new command, and if that spawned command is itself a python -c one-liner containing the same escape/sink pattern (including reverse-shell setups using sockets and subprocess), it confirms the exploit worked.

## Why it matters

Successful exploitation gives an attacker unauthenticated remote code execution on the machine running Xinference — enough to run arbitrary commands, exfiltrate data, or pivot further into the network from the inference host.

## What you can do

- Do not run Xinference's Llama3 tool-call parsing on internet-facing endpoints without strict input validation on request bodies.
- Review or disable any code path that calls eval() on raw model or user-supplied text; treat this as an architectural flaw, not just an input filter problem.
- Monitor process execution on inference hosts for python -c invocations containing __import__, getattr/eval/compile chains, or socket+subprocess combinations.
- Restrict outbound network access and file-system permissions for the account running the inference server so a successful eval() cannot pivot into full system compromise.

## Known benign look-alikes

- Authorised security research or patch validation firing the exploit at a lab Xinference instance without any advisory/CVE text in the request body.
- A developer asking a tool-enabled coding assistant to explain, refactor or review Python that genuinely uses __import__ plus subprocess or requests (dynamic plugin loaders, build scripts) - suppressed only when linter/test markers are present.
- Malware-analysis and de-obfuscation workflows pasting captured Python payloads into a tool-calling chat session.
- Notebook or REPL agents that legitimately spawn `python -c` with __import__ for dynamic imports (execute_process branch).
- Incident-response runbooks or SOAR playbooks that embed the exploit string as reference material in an inference request.

## References

- https://github.com/xorbitsai/inference
- https://attack.mitre.org/techniques/T1059/006/
- https://attack.mitre.org/techniques/T1190/
- https://atlas.mitre.org/techniques/AML.T0051
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

---
Source: https://www.netzilo.com/threats/xinference-llama3-toolcall-eval-rce