What happened
CVE-2026-42271 covers a command-injection vulnerability in LiteLLM, the open-source LLM proxy that fronts OpenAI-compatible and native LLM APIs. NVD rates the vulnerability CVSS v3.1 8.8 (High). The CWE classifications are CWE-78 (OS Command Injection) and CWE-77 (Command Injection). The vulnerable versions are 1.74.2 through 1.83.6, fixed in 1.83.7. CISA added the CVE to the Known Exploited Vulnerabilities catalog on 8 June 2026 with a remediation due date of 22 June 2026. The vulnerability allows any authenticated user of the LiteLLM proxy, including holders of low-privilege internal virtual keys, to run arbitrary commands on the host.
How it works
The vulnerable code path is in two endpoints that preview an MCP server before saving it, a POST endpoint and a follow-up endpoint. LiteLLM built the preview command line from user-controlled fields without sufficient sanitization; an authenticated user could supply shell metacharacters that were passed through to the OS-level command execution. The fix in 1.83.7 sanitizes the input and changes the preview flow to use a controlled command template. The BerriAI security advisory linked from the KEV entry provides full technical detail, including the affected endpoints and the patch commit.
LiteLLM is widely deployed as a self-hosted proxy in front of OpenAI, Anthropic, and other LLM providers, including in production environments where it sits in the same trust zone as the application backend. The vulnerability is exploitable by any authenticated user, which means the threat model is not external attacker but internal user: a developer with a low-privilege key, a compromised CI service, or a token leaked in a pull request. CWE-78 and CWE-77 are the right classifications because the injection point is the shell-level command, not the LLM prompt, but the operational impact is amplified by the fact that LLMs are now the user-facing surface of many internal tools.
Blast radius
The blast radius of an LLM-proxy command injection is wider than a typical web app command injection, because the proxy is the place where API keys, request bodies, and model responses flow through. A compromised proxy sees every prompt and every response for every team using it, and it sits on a network path that is usually trusted to talk to LLM providers, package registries, and tool integrations. The attacker can read API keys for upstream providers, modify responses on the way back, exfiltrate the request stream, and use the proxy as a foothold into the rest of the internal network. The MCP preview endpoint in particular is reachable from any virtual key in the system, including the cheap per-team keys that are routinely issued to developers and to automation.
Defender actions
Defender actions are mostly straightforward. Upgrade to LiteLLM 1.83.7 or later. Audit the LiteLLM proxy logs for the preview endpoints and look for unusual POST activity from internal keys in the weeks before the upgrade; the CISA KEV note says exploitation has been observed. Rotate any API keys that were stored in or accessible from the proxy host, including upstream LLM provider keys, downstream application keys that the proxy managed, and any tokens used to authenticate the proxy to internal services. The proxy is a high-value target: treat its host as compromised until you can demonstrate otherwise.
Lessons
The wider lesson is that an LLM proxy is a high-value, high-privilege component that is often overlooked in vulnerability management. It is not a regular web app. It is a credentialed gateway to every model call the organization makes, and the user population is internal-by-default in many deployments. The same hardening rules that apply to a CI build server or a secrets manager apply to an LLM proxy: short-lived credentials, hardware-backed authentication, and tight monitoring of the control endpoints that are not part of the normal LLM API surface. CVE-2026-42271 is a good prompt to do that hardening pass before the next command-injection CVE lands in an LLM-adjacent component.