Yes. CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalogue on 8 June 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. BerriAI LiteLLM contains a command injection vulnerability that could allow any authenticated user, including holders of low-privilege internal-user keys, to run arbitrary commands on the host.
Why active exploitation changes the response
CISA’s KEV listing is the key operational signal here: it means defenders should treat this as a confirmed exploitation problem, not a theoretical product flaw. For BerriAI LiteLLM, the command injection risk matters because an authenticated user can turn ordinary application access into host-level command execution, which shifts the issue from patch hygiene into immediate containment and exposure review.
When a flaw is already in the wild, the practical question is no longer whether exploitation is possible, but whether the affected service is exposed, reachable, and still trusted to handle production traffic. That is why KEV status should move the item to the front of remediation queues, especially when the vulnerable path is available to low-privilege internal users.
What the command injection path means for LiteLLM deployments
Command injection is dangerous because the application may pass attacker-controlled input into the host operating system with more authority than the user should ever have. In this case, the important nuance is that the attacker does not need unauthenticated internet access to be dangerous, an authenticated foothold with weak privilege boundaries may be enough to run arbitrary commands on the server.
That makes the blast radius broader than a single request or one compromised account. If LiteLLM is used as a gateway, broker, or orchestration layer, host compromise can expose adjacent secrets, configuration material, logs, and downstream integrations that the service can reach. A seemingly local application defect can therefore become a platform compromise.
The right way to think about the flaw is as a control-break in trust between application identity, user privilege, and operating-system execution. If internal users, automation, or shared keys can invoke the vulnerable function, then compromise can come from inside the trust boundary as easily as from outside it.
How to verify exposure and limit blast radius
Start by confirming whether any LiteLLM instance is Internet-facing, reachable from untrusted internal segments, or embedded in a workflow that accepts user-supplied prompts, requests, or configuration values. Then determine whether the deployment uses shared credentials, broad host permissions, or container settings that would let a successful injection reach the underlying node or nearby services.
If patching is not immediate, reduce exposure by restricting who can reach the service, tightening execution permissions around the host, and isolating the process from sensitive local resources. Where the vulnerable component is fronting other systems, treat it as a high-value choke point and remove any unnecessary network paths, mounted credentials, and privileged runtime settings that would increase post-exploitation leverage.
After remediation, validate whether there are signs of earlier abuse rather than assuming the issue was only theoretical. Command injection often leaves behind unusual process creation, unexpected outbound connections, altered configuration, or new files and scheduled tasks on the host. If the instance could access secrets, tokens, or service credentials, those should be reviewed as potentially exposed.
Risk and Threat Considerations
This is a high-consequence class of flaw because authenticated command injection often bypasses the normal trust model inside a platform. The attacker does not need to own the service outright at the start, only a request path that reaches command execution with enough privilege to matter.
Failure mechanism: User-controlled input reaches an OS command context, and the application executes it with host authority instead of safely constraining the operation. In deployments that reuse internal-user keys or broad service permissions, that can turn limited application access into full system compromise.
Impact: A successful exploit can lead to remote command execution, secret exposure, lateral movement, service disruption, and persistence on the host or adjacent systems. If the service brokered access to other infrastructure, the compromise can extend well beyond the LiteLLM process itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | LiteLLM exposure depends on hardened service and host settings. |
| Recommendation — Harden the LiteLLM host, remove unnecessary privileges, and disable unsafe execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Command injection is fundamentally an input-handling failure. |
| IA-5 — Authenticator Management | Authenticated users and internal keys are part of the abuse path. | |
| SI-2 — Flaw Remediation | KEV status makes remediation urgent and operationally time-bound. | |
| Recommendation — Validate and constrain all user-supplied input before it reaches command execution. Rotate, scope, and monitor credentials that can reach the vulnerable LiteLLM service. Prioritise emergency remediation for the vulnerable LiteLLM deployment. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Command injection reflects an unsafe execution design in the application layer. |
| Recommendation — Remove shell execution from request handling and enforce safer command construction. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | The flaw enables adversaries to execute operating-system commands on the host. |
| Recommendation — Hunt for command interpreter abuse, unusual child processes, and post-exploitation activity. | ||
Practitioner Guidance
What to verify: Confirm whether the affected LiteLLM path is reachable by any authenticated user class that should not be able to execute operating-system commands. Verify whether the runtime can access production secrets, cloud credentials, or other sensitive local material that would change the incident from application compromise to wider environment compromise.
Decision rule: If the vulnerable instance is still exposed and cannot be patched immediately, treat it as an active security incident condition, not a routine maintenance item. Preserve logs and host artefacts first, because once the service is changed or restarted, evidence of prior exploitation can disappear quickly.
Practitioner takeaway: For an exploited command-injection KEV, the key judgement is not just whether the patch exists, but whether the service already had enough authority to turn one authenticated request into meaningful host or environment compromise.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- CVE-2026-42271 (BerriAI LiteLLM Command Injection)
- Is CVE-2026-1731 (BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA) OS Command Injection) being exploited in the wild?
- Is CVE-2026-73570 (Zimbra Collaboration Suite (ZCS) OS Command Injection) being exploited in the wild?
- Is CVE-2026-59822 (BerriAI LiteLLM Improper Authentication) being exploited in the wild?