An AI Gateway Lands on the KEV Catalog: CVE-2026-42271 Turns LiteLLM's MCP Preview Into Host Command Execution

The Known Exploited Vulnerabilities catalog is full of VPNs, firewalls, and mobile gateways. On June 8, 2026, CISA added something newer to the list: an AI gateway. CVE-2026-42271 is a command-injection vulnerability in BerriAI's LiteLLM, an open-source proxy server that lets applications call many large-language-model APIs through a single OpenAI-compatible interface. Its appearance in the KEV catalog is a marker of where the attack surface is moving as organizations bolt LLM infrastructure onto production systems.

The National Vulnerability Database rates the flaw with CVSS 4.0, assigning a base score of 8.7, High. The CVSS 4.0 vector — AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N — describes a network-reachable, low-complexity attack requiring only low privileges and no user interaction, with high impact to the confidentiality, integrity, and availability of the vulnerable system and high confidentiality impact to subsequent systems. In plain terms: a low-privileged user can take over the host the proxy runs on.

How a preview feature became a shell

The NVD description lays out the mechanism with unusual clarity. From version 1.74.2 to before 1.83.7, two endpoints meant to preview a Model Context Protocol (MCP) server before saving it — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — “accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport.” MCP's stdio transport works by launching a local process and communicating with it over standard input and output. When these preview endpoints received a stdio configuration, they tried to connect, “which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process.”

That is the entire vulnerability: a feature designed to test a server configuration would dutifully execute whatever command the request named. The flaw is classified under CWE-78 (OS command injection) and CWE-77 (command injection) — the inputs that were meant to describe a benign server became instructions the host obediently ran.

The authorization failure is what makes it severe rather than merely awkward. Per the advisory, “the endpoints were gated only by a valid proxy API key, with no role check.” The consequence is stark: “Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host.” In a typical LiteLLM deployment, internal-user keys are handed out broadly so that teams and applications can route their model traffic through the gateway. The vulnerability collapses the distance between holding one of those routine keys and owning the server, with the privileges of the proxy process, that brokers an organization's AI traffic.

Why an AI gateway is a high-value target

It is worth dwelling on what a LiteLLM host typically holds. An AI gateway is a credential concentrator: it commonly stores or proxies API keys for multiple upstream model providers, sees the prompts and completions flowing through it, and sits inside the trusted network alongside the applications it serves. Code execution on that host is therefore not just a single-server compromise — it is potential access to provider credentials, to sensitive data transiting the proxy, and to a pivot point deeper into the environment. The CVSS 4.0 vector's high subsequent-system confidentiality impact (SC:H) reflects exactly that downstream reach.

CISA's catalog entry carries a note that broadens the warning beyond LiteLLM itself: the vulnerability “affects a common open-source component, third-party library, or a protocol used by different products,” and stakeholders are advised to “check with specific vendors for information on patching status.” LiteLLM is embedded in numerous AI stacks and platforms, which means organizations may be running the vulnerable code without having deployed it directly. The defensive task includes a dependency hunt, not just a check of explicitly installed software.

The fix is unambiguous. BerriAI patched the issue in LiteLLM v1.83.7; the project's release notes point to the v1.83.7-stable tag, and the GitHub Security Advisory GHSA-v4p8-mg3p-g94g documents the flaw. CISA's required action directs patching per BOD 22-01 or discontinuing use if a fix is unavailable, with a federal remediation due date of June 22, 2026.

The version range is worth noting for triage. The flaw was introduced in LiteLLM 1.74.2 and persisted until the 1.83.7 fix, which means deployments pinned to a release in that band are affected while older installations may not be — an unusual situation where being behind on updates could, in this narrow case, have left an organization on a pre-vulnerable build. The reliable answer is still to move forward to 1.83.7-stable or later rather than to reason about which side of the window a given install sits on. The MCP angle also generalizes: Model Context Protocol is rapidly becoming the connective tissue between LLM applications and external tools, and its stdio transport launches local processes by design. Any system that accepts MCP server configurations from users and then acts on them is handling code-execution-adjacent input, and the lesson of CVE-2026-42271 is that such input demands authorization checks and validation as rigorous as any other path that can spawn a process.

For defenders, the practical takeaway has three parts. First, upgrade every LiteLLM instance to v1.83.7-stable or later, and audit AI platforms and internal tools that may bundle LiteLLM as a dependency. Second, treat the gateway's API keys as the high-value secrets they are: because any valid key was enough to trigger code execution, assume that broadly distributed internal-user keys were a viable attack path, and consider rotating provider credentials and gateway keys if a vulnerable version was exposed to untrusted callers. Third, review host process logs for unexpected subprocesses spawned by the proxy during the affected window — the exploitation mechanism leaves a process tree, and that is where evidence of an MCP-preview abuse would surface.

The larger signal here is the maturing of AI infrastructure as a target class. LLM gateways, MCP servers, and the glue connecting them are now production systems that sit in privileged positions and accept attacker-influenced input by design. CVE-2026-42271 is an early, concrete example of that surface being exploited in the wild — and a reminder that a “preview” feature which launches processes deserves the same scrutiny as any other path to code execution.