Quick answer
Direct answer
Risk scores
| CVSS metric | What it means |
|---|---|
| Attack vector (AV:N) | Network: reachable remotely |
| Attack complexity (AC:L) | Low complexity |
| Attack requirements (AT:P) | Attack requirements present |
| Privileges required (PR:L) | Low privileges required |
| User interaction (UI:N) | No user interaction |
| Confidentiality (VC:H) | High confidentiality impact |
| Integrity (VI:H) | High integrity impact |
| Availability (VA:H) | High availability impact |
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CISA required action
About BerriAI LiteLLM
LiteLLM, from BerriAI, is a proxy server that lets you call LLM APIs using OpenAI or native formats. For teams providing applications with access to those APIs, it serves as an AI gateway. That role makes the gateway itself an important security boundary, not merely a convenient interface.
If you operate the gateway, you need to distinguish permission to use an AI service from permission to administer the server behind it. An application user might legitimately hold a proxy API key without having any reason to start operating system processes. This vulnerability crosses that boundary.
The affected functionality concerns previewing an MCP server before saving its configuration. Previewing sounds like a temporary check, but the behavior described here was not passive inspection. For the stdio transport, attempting a connection meant starting a local subprocess. That difference between checking configuration and executing configuration is central to understanding the exposure.
What the flaw is
CVE-2026-42271 affects LiteLLM from version 1.74.2 through versions before 1.83.7. Two POST endpoints, one for testing an MCP connection and another for previewing its tools list, accepted a complete server configuration supplied in the request body.
That configuration included command, args, and env fields used by the stdio transport. When a request selected this transport, the connection attempt caused LiteLLM to launch the supplied command as a subprocess on the proxy host. The subprocess ran with the privileges of the proxy process.
The authorization problem made this behavior available too broadly. The endpoints required a valid proxy API key, but they did not check the caller's role. Consequently, a user with a low privilege internal user key could reach functionality that started arbitrary commands on the host.
This is not simply a case of missing authentication. Authentication existed, but it did not establish whether the caller should control local process execution. Your assessment therefore needs to examine both the configuration driven execution path and the missing authorization boundary.
The supplied weakness classifications include CWE-77 and CWE-78, covering command injection concerns. You do not need to assume a particular shell trick to understand the failure: caller supplied configuration directly influenced which process the gateway started. The issue was patched in LiteLLM 1.83.7. Consult the advisory for implementation details rather than assuming exactly how the fix changes request handling.
How an attack could happen
Consider a deployment running an affected LiteLLM version where an ordinary internal user can reach the MCP preview functionality. The following is a conceptual exposure scenario, not a reconstruction of any reported intrusion.
- An attacker possesses a valid proxy API key with limited application privileges. The verified facts do not establish how attackers obtain such keys, so do not assume theft or any particular initial access technique.
- The attacker reaches a vulnerable preview endpoint and supplies a stdio server configuration. The important boundary is that a service user can influence local process execution without an additional role check.
- The preview connection attempt starts the supplied command on the proxy host with the proxy process's privileges. Execution happens during the attempted preview rather than requiring the configuration to be saved first.
- The consequences then depend on what that process identity can access. Your investigation should establish its actual permissions, accessible data, and connections rather than treating every deployment as equally exposed.
Impact
The immediate impact is arbitrary command execution on the proxy host. This is not automatically equivalent to root access or control of every surrounding system. The verified privilege boundary is the proxy process identity, which is why understanding that identity matters.
Potential consequences include unauthorized access to data available to the process, changes to resources it can modify, and disruption of services it can affect. Treat these as outcomes to assess, not evidence that any particular data theft or outage has occurred.
The vulnerability has High severity and CVSS 8.7. Its supplied EPSS is 92.57 percent. These signals support urgent attention, but they do not tell you whether your own gateway has already been compromised.
CVE-2026-42271 is in the CISA Known Exploited Vulnerabilities catalog, with an addition date of June 8, 2026. Exploitation in the wild is therefore established. The supplied ransomware status is Unknown, so you should not describe this as a confirmed ransomware campaign.
Affected versions and timeline
| Field | Detail |
|---|---|
| Product | BerriAI LiteLLM |
| Affected versions | Litellm from 1.74.2 before 1.83.7; Openshift Ai from 2.25 before 2.25.8; Openshift Ai from 3.3 before 3.3.4; Openshift Ai 3.4 |
| Published | May 8, 2026 |
| Last modified | Jul 15, 2026 |
| Added to CISA KEV | Jun 8, 2026 |
| Assigning CNA | security-advisories@github.com |
For LiteLLM, the affected interval begins at 1.74.2 and ends before 1.83.7. Inventory the version actually running in each deployment rather than relying only on a package declaration, an intended upgrade, or the version in a development repository.
The supplied affected product list also includes OpenShift AI from 2.25 before 2.25.8, from 3.3 before 3.3.4, and version 3.4. Check the Red Hat advisory and associated errata for the appropriate supported remediation for your installation. Do not infer an unlisted fixed release for 3.4.
For an affected deployment, assess endpoint reachability and access by valid proxy key holders. Internet exposure is not the only concern: an internal deployment can still present this authorization failure to an authenticated user. Conversely, a product match alone does not establish that exploitation occurred.
How to detect it
- Identify running LiteLLM instances and affected OpenShift AI installations. Record version evidence, deployment ownership, available logs, and how callers reach the gateway. Separate confirmed affected systems from installations whose versions remain unknown.
- Review available HTTP access records for POST requests to the MCP connection preview and tools list preview endpoints. If your telemetry permits it, correlate requests with the authenticated key identity and its assigned role.
- Look for preview activity by identities that do not normally configure MCP integrations. This is an investigation lead, not proof of abuse. Establish whether the activity had an approved administrative purpose before drawing conclusions.
- Where request details are already captured safely, examine whether previews selected stdio and included process configuration fields. Avoid adding unrestricted body logging as a quick fix: configuration data may itself require careful handling.
- Correlate preview requests with child process creation beneath the LiteLLM proxy process. Review process ancestry, execution identity, timing, and whether the launched program fits the deployment's approved behavior.
- Investigate unexpected file access, outbound connections, or configuration changes associated with suspicious subprocesses where telemetry exists. Missing records or an absence of obvious errors does not prove that execution never happened.
How to fix it
Do this now
- Prioritize upgrades of affected LiteLLM deployments to 1.83.7 or an appropriate later release. Confirm that the running service has changed, including any additional instances still serving traffic. A completed package update is not sufficient evidence by itself.
- For affected OpenShift AI installations, follow the Red Hat advisory and applicable errata. Use supported product remediation rather than assuming that independently replacing a bundled component is an equivalent fix.
- If you find suspicious preview requests or subprocess activity, preserve relevant evidence and involve incident response. Patching removes the vulnerable software condition but does not establish that prior execution left no lasting changes.
If you cannot patch yet
- If immediate patching is impossible, consider temporarily blocking access to both affected preview functions at an enforcement point you control. Verify coverage across every reachable route. Treat this as a compensating restriction, not as a confirmed vendor prescribed workaround.
- Reduce access to affected gateways and revoke unnecessary proxy keys while remediation proceeds. Restricting only anonymous traffic does not address the documented attack path because valid low privilege keys are sufficient.
- CISA's required action calls for vendor directed mitigations, applicable BOD 22-01 cloud service guidance, or discontinuing product use when mitigations are unavailable. Check the current instructions and their applicability to your environment.
Longer term hardening
- Review the permissions of the proxy process. Where operationally feasible, reduce unnecessary filesystem access, credentials, and network reach. These measures can constrain consequences, but they do not replace correcting the vulnerability.
- Define who is authorized to configure MCP integrations and who merely needs model API access. Include preview and test functions in that authorization review rather than treating them as harmless utility features.
- Maintain monitoring for unexpected child processes and unusual preview activity. If investigation indicates that accessible credentials may have been exposed, rotate them through an incident response process and verify that dependent services recover safely.
CTEM action plan
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Start with the gateway's business role and operating boundary. Identify who owns it, which applications depend on it, which users receive proxy keys, and what the proxy process can access. Include affected OpenShift AI installations in your scope. This keeps the assessment focused on the exposure behind the product name. |
| Discover | Collect running version evidence and map access to the preview functions. Compare the intended permission model with the actual identities that can reach them. Record uncertainties explicitly, including missing inventory or telemetry. An unknown version or untested access boundary should remain an open discovery task, not quietly become a clean result. |
| Prioritize | Combine confirmed exploitation, CVSS 8.7, and EPSS 92.57 percent with your local exposure. Give particular attention to affected instances reachable by broadly distributed low privilege keys and processes with sensitive access. Do not use network isolation alone to dismiss an issue whose entry condition is possession of a valid key. |
| Validate | Validate remediation without attempting arbitrary command execution in production. Confirm running versions, review vendor guidance, and use approved checks to assess access boundaries. If temporary blocking is your control, verify every relevant path. Also confirm that legitimate gateway functions still work, so an operational rollback does not silently restore the exposure. |
| Mobilize | Assign an accountable owner for each affected deployment and coordinate security, platform, and application teams. Track upgrades, temporary controls, investigation findings, and validation evidence separately. Close the vulnerability task only when remediation is demonstrated, while keeping any incident investigation open until its own evidence supports closure. |
Key takeaways
- LiteLLM's MCP preview functions could start caller supplied commands under the proxy process identity, making a preview request a host execution boundary.
- A valid proxy API key was required, but no role check prevented low privilege internal users from reaching the vulnerable behavior.
- LiteLLM versions from 1.74.2 before 1.83.7 are affected. The supplied scope also includes specific OpenShift AI versions.
- CISA catalog inclusion establishes exploitation in the wild. It does not establish compromise of your deployment or confirmed ransomware involvement.
- Upgrade, validate the running deployment, and investigate relevant activity. Keep temporary exposure restrictions and incident response distinct from the software fix.
CWE References
- CWE-77: Command Injection More CVEs with this weakness
- CWE-78: OS Command Injection More CVEs with this weakness
- CWE-78: OS Command Injection More CVEs with this weakness
Technical References
Frequently asked questions
Related CVEs
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key. This issue is fixed in version 1.84.0.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.81.16 to before version 1.83.7, a database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example POST /chat/completions) and reach this query through the proxy's error-handling path. An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages. This issue has been patched in version 1.83.7.
Crafted MQTT messages can trigger command injection, resulting in root-level code execution on the target device.
A command injection vulnerability exists in MLflow's model serving container initialization code, specifically in the `_install_model_dependencies_to_env()` function. When deploying a model with `env_manager=LOCAL`, MLflow reads dependency specifications from the model artifact's `python_env.yaml` file and directly interpolates them into a shell command without sanitization. This allows an attacker to supply a malicious model artifact and achieve arbitrary command execution on systems that deploy the model. The vulnerability affects versions 3.8.0 and is fixed in version 3.8.2.
This vulnerability allows authenticated attackers to execute arbitrary commands on the underlying system using the file name of an uploaded file.
This vulnerability allows authenticated attackers to execute commands via the hostname of the device.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like CVE-2026-42271 with a free CTEM certification.
Beginner / Practitioner / Program Leader
Explore certifications