BerriAI/litellm callback flaw enables remote code execution

BerriAI/litellm version 1.40.12 contains a vulnerability that allows remote code execution. The issue exists in the handling of the 'post_call_rules' configuration, where a callback function can be added. The provided value is split at the final '.' mark, with the last part considered the function name and the remaining part appended with the '.py' extension and imported. This allows an attacker to set a system method, such as 'os.system', as a callback, enabling the execution of arbitrary commands when a chat response is processed.

The supplied CNA affected data marks berriai/litellm as affected for versions less than v1.65.4.dev6, and the description specifically identifies version 1.40.12.

A separate GitHub Advisory entry lists >= 1.40.3.dev2, <= 1.40.12 and reports no patched version. These sources are not fully consistent: the CNA boundary is broader, while the advisory confirms only a narrower branch. The status of branches not covered by an explicit statement remains unknown and should not be treated as safe solely because a release is newer than 1.40.12.

BerriAI/litellm processes a callback value from the post_call_rules configuration by splitting the string at the final . character. The last part is treated as the function name, while the preceding part is given a .py extension and imported to create the callback. If an attacker can control or alter this value, they can specify a system method such as os.system, causing arbitrary commands to execute when LiteLLM processes a chat response.

The flaw is classified under CWE-94 because externally influenced data is used to determine code or a module to load. The referenced fix commit adds checks before loading the callback module and rejects dangerous modules, but the available evidence does not identify which released version contains that change.

The exact API, configuration path, or administrative workflow that permits an attacker to change post_call_rules is not established by the supplied evidence. Actual exposure therefore depends on the LiteLLM deployment model, configuration permissions, and whether the callback path is enabled.

The vulnerability is remotely reachable, has low attack complexity, requires some privileges, and does not require user interaction. The key prerequisite is the ability to set or influence the callback value in post_call_rules; the specific route or endpoint has not been confirmed.

The supplied record indicates that a public exploit or proof of concept exists. It does not establish exploitation in the wild and does not identify a campaign, victim, or specific abuse activity.

The technical result is arbitrary command execution in the security context of the LiteLLM process. The supplied attack characteristics indicate network reachability, low required privileges, no user interaction, and an unchanged security scope.

The direct impact therefore depends on the permissions of the account running LiteLLM, the files and secrets it can access, and its connectivity to other systems. A deployment with broad operating-system permissions or weak isolation may experience more extensive consequences than a tightly constrained workload. The record does not provide evidence of a specific intrusion, data theft, or service outage.

Arbitrary command execution may affect the confidentiality, integrity, and availability of the host or container running LiteLLM, depending on the process permissions.

• Data that the LiteLLM process can read may be exposed or modified.
• Secrets, tokens, or connection information available to the service may be at risk if commands run in the same security context.
• An attacker may disrupt the service, alter gateway behavior, or consume host resources.
• Actual consequences depend on operating-system permissions, network access, isolation controls, and who can modify post_call_rules; the record does not confirm a specific breach or outage.

1. Prioritize removing installations covered by the CNA range, especially 1.40.12. The CNA data uses lessThan: v1.65.4.dev6, but that condition alone does not prove that every later or parallel branch is safe.
2. Review the referenced upstream fix commit. It adds checks before loading callback modules and blocks dangerous modules, but the available evidence does not map that commit to a specific released version.
3. Because the record indicates that a patch is available but does not provide a confirmed fixed release for every branch, do not claim a single version as universally safe. Confirm release coverage with BerriAI or the CNA before standardizing an upgrade rule.
4. Until release coverage is confirmed, disable post_call_rules callbacks where they are not required, or strictly limit the accounts and services allowed to create, modify, or deploy this configuration. Do not allow untrusted data to select callback modules or functions.
5. If exploitation is suspected, isolate the affected process or workload, preserve relevant logs, and assess secrets accessible to the process. Rotate exposed secrets after determining the likely scope of access.

1. Inventory environments that install the Python package litellm and compare deployed versions with the affected boundaries in the affected summary. Check both direct and transitive dependencies.
2. Review the effective post_call_rules configuration, configuration files, and data sources that can write or modify callbacks. Look for module-and-function values, especially values resembling os.system.
3. Audit permissions and logs for accounts or services that can change LiteLLM configuration, then correlate those events with unusual chat-response processing.
4. As a precautionary monitoring measure, review unexpected child processes, file changes, or network connections originating from the LiteLLM process after chat responses are handled. These are investigation leads, not confirmed indicators of compromise for this vulnerability.
5. Do not treat the absence of a suspicious value or log event as proof of safety. Combine version, configuration, and access-control checks.