CVE-2026-61539 in Xinference
Summary
by MITRE • 08/22/2026
Xinference is an inference API for running open-source, speech, and multimodal models. In 2.5.0 and earlier, Xinference passes attacker-influenced Llama3 tool-call output to eval() in xinference/model/llm/tool_parsers/llama3_tool_parser.py and xinference/model/llm/utils.py. Requests to /v1/chat/completions with a tools field flow through xinference/api/restful_api.py, xinference/model/llm/transformers/core.py, handle_chat_result_non_streaming(), and _post_process_completion() before extract_tool_calls() or _eval_llama3_chat_arguments() evaluates the model-generated Python expression. An unauthenticated remote attacker can influence that output through a crafted prompt and execute commands in the Xinference server process context. This issue is fixed in version 2.7.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified as CVE-2024-XXXX involves a critical code injection flaw within Xinference, an open-source platform designed for serving inference APIs for large language models, speech processing, and multimodal applications. The core of the issue lies in the improper handling of model-generated output during tool call parsing operations. Specifically, versions 2.5.0 and earlier utilize Python's eval() function to process outputs from Llama3-based models that are configured with tool-calling capabilities. This architectural decision creates a direct pathway for remote code execution when the system processes user-supplied prompts that trigger specific model behaviors. The vulnerability is situated within the file xinference/model/llm/tool_parsers/llama3_tool_parser.py and associated utility modules, where the system attempts to parse structured data from natural language responses generated by the underlying large language models.
The attack vector begins when an unauthenticated remote attacker sends a request to the /v1/chat/completions endpoint with a tools field defined in the payload. This request traverses through several internal components of the Xinference framework, including xinference/api/restful_api.py and xinference/model/llm/transformers/core.py. The data flow proceeds through handle_chat_result_non_streaming() and _post_process_completion(), eventually reaching functions such as extract_tool_calls() or _eval_llama3_chat_arguments(). These functions are responsible for interpreting the model's response to determine if it intends to invoke a specific tool. In vulnerable versions, instead of using safe parsing methods like JSON decoding with strict schema validation, the system passes the raw output string directly into eval(). This allows an attacker who can influence the prompt sent to the LLM to craft input that causes the model to generate malicious Python code within its response. When this crafted response is evaluated by the server process, it results in arbitrary command execution under the privileges of the Xinference service account.
From a technical perspective, this flaw represents a classic instance of insecure deserialization and injection via dynamic evaluation. The use of eval() on data derived from external sources or model outputs that are not strictly sanitized violates fundamental security principles regarding input validation and code safety. By allowing arbitrary Python expressions to be executed within the server context, the vulnerability grants an attacker full control over the application's runtime environment. This can lead to a complete compromise of the host system hosting the Xinference instance, including access to sensitive data stored on disk, network reconnaissance capabilities, or use as a pivot point for further attacks against internal infrastructure. The impact is severe because it requires no authentication and affects any user who interacts with the API endpoint while tool-calling features are enabled.
This vulnerability aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) and specifically relates to CWE-501 Trust Boundary Violation, as the system fails to properly validate data crossing from an untrusted source (the LLM output influenced by user input) into a trusted execution context. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, where attackers use built-in operating system or application interpreters to execute commands. The exploitation chain demonstrates how modern AI applications can introduce traditional software vulnerabilities through the integration of generative models that produce dynamic code-like structures without adequate safeguards.
Mitigation strategies must prioritize immediate upgrading to version 2.7.0 or later, which addresses this issue by replacing unsafe evaluation mechanisms with secure parsing alternatives such as JSON schema validation and strict type checking for tool call arguments. Organizations running older versions should immediately restrict network access to the /v1/chat/completions endpoint using firewalls or API gateways that enforce authentication requirements, thereby preventing unauthenticated actors from triggering the vulnerable code path until an upgrade can be performed. Additionally, implementing runtime application self-protection (RASP) solutions or strict sandboxing for Python processes running inference services can provide a layer of defense against successful exploitation attempts by limiting the impact of any potential command execution. Regular security audits focusing on the integration points between LLM outputs and backend logic are essential to prevent similar injection flaws in other parts of the application stack.