CVE-2026-61539: Remote Code Execution via Llama3 Tool Parser Eval Injection in Xinference

Xinference is an open-source inference API framework designed for serving Large Language Models (LLMs), speech models, and multimodal models. In deployments running Llama3 models with tool calling enabled, the framework is exposed to a critical security flaw. Specifically, the component parsing model outputs handles tool call data unsafely.

The attack surface is accessible via the standard chat completion endpoints. When client requests prompt the model to invoke tools, the application processes the generated assistant response to extract tool arguments. Because the framework does not sanitize the string generated by the LLM before interpreting it, this architectural pattern creates an indirect pathway for executing operating system commands.

The vulnerability is classified under CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code. This issue allows unauthenticated remote attackers who can influence the LLM's output—either via direct API access or downstream prompt injection—to achieve code execution within the security context of the Xinference server process.

The root cause of CVE-2026-61539 resides in the dynamic interpretation of structured text using Python's built-in eval() function. When processing Llama3 tool calls, Xinference attempts to parse the text representation of a Python dictionary returned by the model. The application invokes eval(model_output, {}, {}) with the intent of converting the string into a native dictionary object.

While the developers passed empty dictionaries as the globals and locals arguments to restrict execution, this implementation does not establish a secure sandbox in Python. Python's runtime environment allows standard object attributes to be traversed to retrieve the built-in namespace. For example, expressions can utilize property accessors on basic literal objects, such as ().__class__.__bases__[0].__subclasses__(), to locate and invoke dangerous classes like subprocess.Popen or direct file handles.

Since Large Language Models generate text based on input prompts, the string passed to eval() is not entirely under the developer's control. An attacker can craft conversational inputs that influence or override the system instructions of the model. By manipulating the LLM into generating a Python expression containing malicious system calls instead of a valid JSON dictionary, the attacker triggers immediate execution of that payload when the server evaluates the generated string.

The vulnerable logic was present in two locations within the codebase: extract_tool_calls in xinference/model/llm/tool_parsers/llama3_tool_parser.py and _eval_llama3_chat_arguments in xinference/model/llm/utils.py. In both cases, the raw model output was evaluated directly using the native eval() sink.

Below is the vulnerable implementation in llama3_tool_parser.py:

# Vulnerable code pattern
def extract_tool_calls(self, model_output: str):
    try:
        # DANGEROUS: Executes arbitrary code contained within model_output
        data = eval(model_output, {}, {})
        return [(None, data["name"], data["parameters"])]
    except Exception:
        return [(model_output, None, None)]

The corresponding patch replaces the dynamic interpreter sink with a secure parsing sequence using json.loads as the primary mechanism, and falling back to ast.literal_eval for Python-specific dictionary literals.

# Patched code implementation
try:
    # Try JSON first (most common LLM output format)
    data = json.loads(model_output)
except (json.JSONDecodeError, TypeError):
    try:
        # Fall back to ast.literal_eval for Python literal formats
        # Unlike eval(), ast.literal_eval() only parses literal structures
        data = ast.literal_eval(model_output)
    except (ValueError, SyntaxError):
        return [(model_output, None, None)]

Using ast.literal_eval secures the application because the Abstract Syntax Tree parser processes only standard Python constants (such as strings, numbers, tuples, lists, dictionaries, booleans, and None). If the input contains a function call, class instantiation, or module import, the parser raises a ValueError immediately instead of compiling and executing the code.

Exploitation of this vulnerability requires the attacker to submit a request to the chat completion API that forces the LLM to output a malicious Python expression. The endpoint /v1/chat/completions must be configured to utilize tools, which registers the Llama3 tool parser as the active parser for the session.

The attacker constructs a system or user message using prompt injection techniques designed to bypass the model's instructions. The objective is to instruct the model to ignore its tool formatting constraints and output a specific Python command string. A conceptual payload instruction might command the model to generate a response like __import__('os').system('id') instead of the expected dictionary.

When the LLM yields the malicious response, the Xinference server intercepts the string and passes it directly to extract_tool_calls. The server then executes the string via eval(). Because the execution occurs under the permissions of the Xinference daemon, this leads to system command execution on the host container or server, facilitating unauthorized access or control.

The security impact of CVE-2026-61539 is categorized as critical, receiving a CVSS v3.1 base score of 10.0. The exploit allows unauthenticated network-based attackers to execute arbitrary system commands, compromising the confidentiality, integrity, and availability of the host operating system.

Because the scope is changed (S:C), an exploit not only compromises the logical environment of the Python application but also allows the attacker to execute commands in the underlying container or host operating system. This capability permits attackers to access sensitive data, including model weights, API keys for upstream services, and database credentials stored on the server.

Furthermore, if the Xinference container is deployed with high privileges or lacks proper network isolation, attackers can leverage the initial foothold to pivot into internal networks, escalate privileges on the host system, or disrupt inference services entirely.

The primary mitigation for this vulnerability is upgrading the Xinference installation to version 2.7.0 or later. This release replaces the vulnerable dynamic evaluation patterns with a safe combination of json.loads and ast.literal_eval, neutralizing the execution path entirely.

If upgrading is not immediately possible, administrators can apply manual modifications to llama3_tool_parser.py and utils.py by replacing the eval() statements with the safe parsing implementation shown in the patch details. Additionally, organizations should implement defense-in-depth measures to limit the potential impact of similar flaws.

API endpoints should be shielded from the open internet using reverse proxies and robust access control policies such as API keys or JWT authentication. Finally, the Xinference service must run under a dedicated, unprivileged operating system user account, and the container should use a read-only root file system with minimal system binaries to limit the impact of arbitrary command execution.