Hi, Thank you Markus for posting this to oss-security on time.
On Thu, Apr 09, 2026 at 12:51:06AM +0200, Markus Vervier wrote: > Workarounds > =========== > > No vendor patch is available at the time of publication. Users could > apply the following mitigations: Somehow this section just ended with the above, without actually listing any mitigations. The copy of this advisory on the X41 website: https://www.x41-dsec.de/lab/advisories/x41-2026-001-litellm/ actually includes the mitigations, which I'll copy-paste to here: > - Block the endpoint at the reverse proxy level: If LiteLLM is deployed > behind a reverse proxy such as nginx or Caddy, deny requests to > /guardrails/test_custom_code. For example in nginx: location > /guardrails/test_custom_code { deny all; return 403; } > > - Restrict access to the admin API: The affected endpoint requires > authentication with the master key. Ensure the master key is only known > to trusted administrators and is not shared with regular API consumers. > > - Do not expose the LiteLLM management interface to untrusted networks: > Use network-level controls (firewall rules, VPC security groups) to > limit access to the LiteLLM admin port to trusted hosts only. > > - Avoid running LiteLLM as root: The default Docker image runs the process > as root, maximizing the impact of code execution. Use --user to run the > container as an unprivileged user to limit post-exploitation impact. Alexander
