CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, 2026, confirming active exploitation in the wild and giving federal civilian agencies until June 22 to remediate. The vulnerability is a command-injection flaw in LiteLLM, the open-source project from BerryAI that gives teams a single OpenAI-format interface in front of dozens of model providers, deployed either as a Python SDK or, more relevantly here, as a standalone AI gateway and proxy that manages API keys, cost tracking, and traffic routing. If you run an LLM proxy in production, there is a meaningful chance it is LiteLLM, and that is exactly why this one matters more than its CVSS line alone would suggest.
The mechanism is specific and worth understanding. Two endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, accepted full server configurations and then spawned the supplied commands as subprocesses running with the privileges of the proxy process itself, with no proper sanitization of the input. That is textbook command injection: the input that was supposed to describe an MCP server to test instead becomes a command the host executes. Initial access nominally requires a valid proxy API key, which sounds like a meaningful barrier until you read the second half: that requirement can be bypassed entirely via CVE-2026-48710, a BadHost authentication bypass in Starlette (the ASGI framework underneath), which turns an authenticated-only bug into an unauthenticated one for any deployment that has not also patched Starlette. The fix landed in LiteLLM v1.83.7, which both sanitizes the endpoints and adds an authorization control restricting the MCP test endpoints to users holding the PROXY_ADMIN role.
The reason this rises above a routine CVE is where LiteLLM sits in the stack. The proxy is the one component that, by design, holds the credentials for every model provider you route through it: your OpenAI key, your Anthropic key, your cloud-inference keys, and often the secrets for whatever else the proxy is wired into. Command execution on that host is therefore not a contained event, it is immediate access to the most concentrated pile of credentials in your AI infrastructure, plus a foothold to move laterally into everything those credentials reach. The help-net writeup is blunt about the impact chain: arbitrary command execution, theft of model-provider credentials and secrets, and lateral movement into connected AI systems. And the context makes it worse, this is the second weaponized LiteLLM vulnerability in a single month after a May 2026 incident, and BerryAI also suffered a March 2026 supply-chain attack via malicious PyPI packages. The gateway layer is being actively probed, and the attackers have noticed that it is where the keys live.
Monday morning, the actions are not subtle and they are not optional if you self-host LiteLLM. First, upgrade to v1.83.7 or later today, this is the one that actually closes the hole. Second, if you cannot upgrade immediately, block network access to the /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints at your reverse proxy or load balancer as an interim measure. Third, rotate every credential the proxy has touched, on the assumption that if you were exposed you should treat the keys as compromised, provider keys, connector secrets, anything in the proxy's environment. Fourth, restrict the proxy's network exposure to trusted segments rather than leaving the admin and test surfaces reachable from the open internet, which is the configuration that turns this from a bad day into a breach. And patch Starlette too, because CVE-2026-48710 is what removes the API-key prerequisite, and a defense that depends on the attacker not having the bypass is not a defense. If you are tracking the broader agent-security thread, this is the concrete version of the warning that has been building in the research, the more the gateway and runtime layers become critical infrastructure, the more they become the target, and the LLM proxy is now demonstrably on the front line.