Xinference Llama3 Tool-Call eval() RCE Payload
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.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7c3f9e14-2b6a-4d58-9f0c-5a1e8b47d3ce
- Severity
- High
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.