CVE-2024-6825: Litellm Remote Code Execution Vulnerability

CVE-2024-6825 Overview

CVE-2024-6825 is a remote code execution vulnerability in BerriAI/litellm version 1.40.12. The flaw resides in how the proxy handles the post_call_rules configuration, which accepts a callback function reference. LiteLLM splits the provided string at the final . delimiter, treats the last segment as a function name, and imports the preceding segment as a Python module. An authenticated attacker can supply values such as os.system to force execution of arbitrary operating system commands when a chat response is processed. The vulnerability is tracked as CWE-94: Improper Control of Generation of Code.

Critical Impact
Attackers with proxy configuration access can achieve arbitrary command execution on the LiteLLM host, compromising confidentiality, integrity, and availability of the AI gateway and any connected model backends.

Affected Products

BerriAI LiteLLM version 1.40.12
LiteLLM builds prior to the 441c727 security fix
LiteLLM 1.65.4 dev2 pre-release builds

Discovery Timeline

2025-03-20 - CVE-2024-6825 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-6825

Vulnerability Analysis

LiteLLM is an open source proxy that unifies calls to large language model providers. The post_call_rules configuration option lets operators register a callback that runs after each chat completion. LiteLLM resolves the callback by string parsing rather than by validated import. The parser splits the input at the last ., appends .py to the module portion, and imports it dynamically. Because no allow-list or sandbox restricts the target, values like os.system resolve to the built-in os module and expose the system function as the post-call handler. When the proxy processes the next chat response, it invokes the attacker-controlled function with response data flowing into arbitrary shell commands.

Root Cause

The root cause is unsafe dynamic module loading in litellm/proxy/types_utils/utils.py. User-controlled configuration is passed directly to Python import machinery without validating whether the target module belongs to a permitted set of callback handlers. Dangerous standard-library modules such as os, subprocess, and builtins were reachable through the same code path used for legitimate callbacks.

Attack Vector

Exploitation requires network access to the LiteLLM proxy and privileges to modify or submit the post_call_rules configuration. Once an attacker registers a callback like os.system, any subsequent chat completion triggers command execution with the privileges of the LiteLLM process. The attacker can then pivot to stored API keys for downstream model providers, exfiltrate prompt data, or move laterally within the hosting environment.

python

         module_name = ".".join(parts[:-1])
         instance_name = parts[-1]
 
+        # Security: Check if the module name contains any dangerous modules that can execute arbitrary code
+        security_checks(module_name=module_name)
+
         # If config_file_path is provided, use it to determine the module spec and load the module
         if config_file_path is not None:
             directory = os.path.dirname(config_file_path)

Source: GitHub commit 441c7275. The patch introduces a security_checks helper that rejects dangerous module names before the dynamic import proceeds.

Detection Methods for CVE-2024-6825

Indicators of Compromise

LiteLLM configuration files or API calls that set post_call_rules to values referencing os.system, subprocess, builtins, or other standard-library execution primitives.
Unexpected child processes such as sh, bash, curl, or python spawned by the LiteLLM proxy process.
Outbound network connections from the LiteLLM host to unrecognized command-and-control or file-hosting infrastructure shortly after chat completions are processed.

Detection Strategies

Inspect LiteLLM proxy configuration and Git history for changes to post_call_rules, callbacks, or related callback registration fields.
Enable audit logging on the LiteLLM admin API and alert on writes that supply dotted-path module references outside a defined allow-list.
Correlate chat completion events with process-creation telemetry to identify shell invocations that originate from the proxy runtime.

Monitoring Recommendations

Forward LiteLLM application logs, container runtime events, and host process telemetry to a centralized SIEM or data lake for retrospective hunting.
Baseline the expected child-process tree of the LiteLLM service and alert on deviations, particularly interpreter or shell executions.
Monitor egress traffic from AI gateway hosts and flag connections that do not match the configured LLM provider endpoints.

How to Mitigate CVE-2024-6825

Immediate Actions Required

Upgrade LiteLLM to a release that includes commit 441c7275, which adds security_checks on the module name before dynamic import.
Restrict administrative access to the LiteLLM proxy so that only trusted operators can modify post_call_rules or other callback configuration.
Rotate any API keys, cloud credentials, or model provider tokens stored on the LiteLLM host if unauthorized configuration changes are suspected.

Patch Information

The fix is available in the upstream repository via GitHub commit 441c7275 and is described in the Huntr bounty report. The patch introduces validation that rejects dangerous module names such as os and subprocess before the callback is imported.

Workarounds

Disable the post_call_rules feature in production configurations until the patched version is deployed.
Run the LiteLLM proxy as an unprivileged user inside a hardened container with read-only file systems and no outbound shell utilities.
Enforce network segmentation so the proxy cannot reach internal management planes or credential stores beyond what is strictly required.

bash

# Configuration example: pin a patched LiteLLM version and remove post_call_rules
pip install --upgrade 'litellm>=1.65.5'

# In config.yaml, ensure no untrusted callbacks are registered
# litellm_settings:
#   post_call_rules: []