CVE-2026-61539

The CVSS 10 score for CVE-2026-61539 is technically accurate but analytically obscuring. What matters isn't whether an attacker manipulates the LLM through prompts or crafts malformed tool call JSON — it's that Xinference passes model-generated output directly to eval() in the first place. That's not a parsing edge case; it's a trust boundary violation baked into the architecture. The vulnerability lives in the tool call pipeline: Llama3 model output flows through restful_api.py into core.py's handle_chat_result_non_streaming(), then _post_process_completion(), where eval() executes the function call. An unauthenticated user sending a request to /v1/chat/completions with a tools field can trigger this. The 'attacker-influenced' language in the CVE masks what is fundamentally an architectural choice: treating LLM output as implicitly trusted Python rather than unvalidated external input. The multi-tenant context is what elevates this from application RCE to infrastructure compromise. Xinference serves as a shared inference layer where multiple organizations run models behind a single API. Successful exploitation doesn't just compromise one user's session — it compromises the host itself, affecting every active model serving session across all tenants. That's lateral blast radius that the CVSS vector doesn't capture. The version jump from 2.5.0 directly to 2.7.0 is informative. Either the fix required touching multiple code paths (suggesting eval() removal rather than surgical validation patching), or 2.6.0 was a failed fix attempt that got yanked. Either interpretation points toward an architectural fix rather than a one-line validation patch. What you should do: verify whether your Xinference deployment exposes the /v1/chat/completions endpoint to unauthenticated users and upgrade to 2.7.0 immediately. More importantly, audit other tool parsers in xinference/model/llm/tool_parsers/ — if this eval() pattern existed in the Llama3 parser, it likely exists in adjacent parsers awaiting discovery. The genotype that produced this bug (convenient-but-unsound eval() on model output) is a recurring pattern across the LLM tooling ecosystem, not a one-off oversight.

Reviewed through automated stages and approved by a human before publication.