CVE-2026-42271: remote command execution in LiteLLM, already actively exploited

CVE-2026-42271: remote command execution in LiteLLM, already actively exploited

In short

CVE-2026-42271 is a command injection vulnerability in LiteLLM, a proxy server (AI Gateway) that many companies use to centralize access to OpenAI-style language models. It affects versions 1.74.2 through prior to 1.83.7 [1]. It has a CVSS score of 8.7, "high" severity according to NVD [1], and is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog [2]. If your organization uses LiteLLM as a gateway to AI providers, today's priority is to update to version 1.83.7 or later and review who has active API keys.

What it is and why it matters

LiteLLM offers two endpoints —POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list— designed to test an MCP server's configuration before saving it. The problem is that both accepted the full configuration in the request, including the command, args, and env fields used by the "stdio" transport. Upon receiving a configuration of this type, the endpoint would attempt to connect by executing that command as a subprocess on the proxy's own host, with the privileges of the LiteLLM process [1].

The serious flaw is one of access control: these endpoints only checked that the request carried a valid proxy API key, without verifying the user's role. In other words, any authenticated user —including those who only have internal, low-privilege keys— could execute arbitrary commands on the server [1]. The vendor has already released a patch in version 1.83.7 [1]. The fact that the vulnerability is listed in CISA's KEV catalog indicates it is not just theoretical: there is evidence of active real-world exploitation [2], which raises the urgency beyond what the CVSS score alone would suggest.

Who is affected

It directly affects organizations running a LiteLLM instance as an AI proxy/gateway on versions 1.74.2 through prior to 1.83.7 [1]. The NVD record also generically associates the CVE with the vendor "Red Hat," without specifying a particular product or security advisory; absent further detail, it cannot be confirmed that a specific Red Hat product is exposed by this vulnerability [1]. The practical focus of this alert remains LiteLLM.

How to know if you're vulnerable

Check which version of LiteLLM you have deployed and whether it falls within the affected range (1.74.2 to prior to 1.83.7) [1]. Also check whether the admin panel or the /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints are accessible from outside your internal network, since any reduction of that exposed surface lowers the real risk of exploitation, although it does not replace updating. Our threat intelligence radar classifies this vulnerability as critical in practice —above NVD's "high" label— precisely because it combines a low barrier to entry (a low-privilege key is enough) with command execution on the host and confirmed active exploitation.

How to protect yourself

• Update LiteLLM to version 1.83.7 or higher as soon as possible [1].
• Rotate all proxy API keys after updating, especially those of internal, low-privilege users.
• Audit host logs for subprocesses or commands executed unusually by the LiteLLM process in recent weeks.
• Restrict network access to LiteLLM's admin/test endpoints to trusted internal networks.
• Apply the principle of least privilege to API keys: not every user needs to be able to create or test MCP server configurations.

Frequently asked questions

Is this vulnerability critical even though NVD marks it as "high"?

NVD scores it at 8.7 (high) [1], but it is in the CISA KEV catalog of active exploitation [2], and our radar rates it as critical due to the ease of exploitation with minimal privileges.

Does it affect Red Hat?

NVD includes "Red Hat" as a vendor associated with this CVE, but without specifying a particular product or advisory [1]; with the information available, specific exposure of Red Hat products cannot be confirmed.

Is it enough to restrict network access to the proxy?

It reduces the risk, but it is not a substitute for applying the patch: the vulnerability is exploited with a valid API key, not only from outside the network [1].

How do I know if I've already been exploited?

Check the logs on the host where LiteLLM runs for unexpected child processes launched by the service, and confirm the installed version against the affected range [1].

Sources

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-42271
• [2] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json