The second LiteLLM flaw in 14 days: CVE-2026-42203 (Jinja2 SSTI in /prompts/test) and why proxy endpoints behind API keys are not the end of the story

On 7 May 2026 the BSI published a security warning for LiteLLM versions 1.80.5 through 1.83.6: Server-Side Template Injection in the endpoint POST /prompts/test, which renders user-supplied prompt templates without a sandbox in the Jinja2 environment of the proxy process. Any authenticated proxy user with a valid API key can execute arbitrary Python code in the container — the classical __class__.__mro__.__subclasses__() escalation chain works out of the box. Fix: 1.83.7-stable, which simultaneously closes the SQL-injection sibling CVE -42208.

Fourteen days earlier — on 23 April — CVE-2026-42208 had been published: an SQL injection in proxy API-key verification, pre-auth, with a public PoC within 36 hours and a CISA KEV listing. The KEV deadline for CVE-2026-42208 is today, 11 May 2026. Anyone who has not yet applied the first patch has today as the last regular day to do so — and should pull straight to 1.83.7-stable, which closes both flaws.

Recommendation: patch now, reverse-proxy block for /prompts/test as a transition, rotate backend API keys, sharpen detection rules (Falco or Tetragon) on the container hosts. The two-week line makes clear that the /prompts/* and key-management subspaces deserve the same security discipline as the /chat/completions path.

What the SSTI is technically

Since version 1.80.5 LiteLLM exposes an endpoint POST /prompts/test that ships prompt templates to various models and returns the render results — a tool for prompt engineers wanting to try their templates against real LLM backends. The render happens in Jinja2, the Python world's standard template engine. That is reasonable, because prompts in practice need to substitute variables ({{ user_input }}, {{ context }}). It is only reasonable if the render runs in a sandbox.

Jinja2 provides SandboxedEnvironment for that purpose — a variant of the standard environment that blocks attribute access to Python-internal methods and prevents calls along known escalation paths (__class__, __mro__, __subclasses__(), __globals__). Exactly this sandbox is missing in /prompts/test of versions 1.80.5 to 1.83.6. The classical Jinja2 SSTI escalation chain therefore works out of the box: a few lines of {{ ''.__class__.__mro__[1].__subclasses__() }} are enough to retrieve the list of all loaded Python subclasses — including subprocess.Popen.

The endpoint checks that the caller carries a valid proxy API key. That is exactly the kind of “authentication, but not really authorisation” that regularly goes wrong in API-gateway designs: every employee, every LLM-backend integration, every test pipeline with its own API key can hit the endpoint. In a realistic LiteLLM installation a normal application key has access to /prompts/test, because it is a read_only path in the default permission map.

Why the two-week line matters more than the individual flaw

Anyone looking only at the individual flaw sees a known SSTI pattern in a popular open-source project. Anyone looking at the two-week line sees a structural pattern in the LiteLLM codebase. 23 April: pre-auth SQL injection in key verification. The endpoint that should establish authentication leaks database contents (CVE-2026-42208, CVSS 9.3, KEV listed). 7 May: post-auth SSTI in an unsandboxed template render. The endpoint that should be safe behind authentication gives code execution.

Both flaws sit in the same subsystem — the proxy API layer — and both land exactly where LiteLLM operators have historically invested little attention: not in the /chat/completions path but in the administrative tooling endpoints. The operational lesson is not “LiteLLM is insecure” but “the /prompts/* and key-management subspace deserves the same security discipline as the actual inference path”.

Who is affected

Directly affected are all LiteLLM proxy installations in versions 1.80.5 through 1.83.6 inclusive — meaning every LiteLLM installation that has been freshly deployed or updated since around mid-March 2026 without jumping to 1.83.7-stable. The open-source variant is affected; the enterprise variant is also affected (it shares the codebase).

Anyone running LiteLLM behind an additional API gateway (Kong, Tyk, AWS API Gateway, Cloudflare Workers) has a secondary protective ring: if that gateway runs path-based allowlisting and does not whitelist /prompts/test, the direct attack is blocked. Anyone running LiteLLM in a multi-tenant setup (one proxy for multiple customers, teams or applications with their own API keys) carries the largest operational risk: each of those keys can hit the endpoint, and a compromised application key gives RCE on the proxy process. Anyone using LiteLLM as an MCP server backend has a special escalation path: a prompt-injection attack on the MCP consumer can structurally aim at generating a call against /prompts/test with a crafted template.

Mitigation and immediate actions

The clean sequence is: first, version check at the proxy (curl -s litellm-proxy/health/litellm-versions | jq '.litellm_version'); second, update to 1.83.7-stable (docker pull ghcr.io/berriai/litellm:litellm-stable_release_v1.83.7-stable); third, restart and verification. For setups that cannot update in the short term, the most robust transitional measure is to block /prompts/test at the upstream reverse proxy or ingress — an nginx snippet location /prompts/test { return 403; } neutralises the flaw for traffic served by the reverse proxy.

Rotate all backend API keys stored in the LiteLLM configuration if the installation was running during a period in which an attacker might have had access. That is the unpleasant but structurally clean variant. “We do not know whether we were compromised” is the more expensive answer after an SSTI flaw in a proxy process.

Detection and verification

Search reverse-proxy logs for SSTI patterns. One line is enough: grep "POST /prompts/test" /var/log/nginx/access.log | grep -E '(__class__|__mro__|__subclasses__|__globals__|__builtins__)'. Falco rule on the container host that detects unusual subprocesses from the LiteLLM process (spawning sh, bash, python subprocesses with atypical arguments). Alternative Tetragon TracingPolicy that ships wake_up_new_task events from the LiteLLM binary to an external sink. Anyone finding even one suspicious request: full container forensics (memory dump, filesystem snapshot), rotation of all stored backend API keys, rebuild of the proxy from a known image tag.

Operator recommendation

The operational decision depends on the setup in which LiteLLM runs at your site. Patch immediately if you run LiteLLM in a multi-tenant setup or as an MCP backend for agent frameworks. Update within a 48-hour maintenance window acceptable if LiteLLM runs in a single-tenant configuration with clearly trusted API key holders. Block now instead of patching if a production maintenance window is not possible this week — set /prompts/test at the reverse proxy to 403, follow with the update in the next regular maintenance.

DACH mid-market companies with LiteLLM as a central AI gateway typically have a single container instance and a manageable list of backend providers. The clean path here: bump the container image tag to 1.83.7-stable, rotate backend API keys, search reverse-proxy logs of the past 14 days for SSTI patterns — 90 minutes plus reaction to any log findings. Larger setups with a central AI-gateway team need the two-stage variant: first patch in the staging region and smoke-test the routing table, then rolling-update production regions, with backend-key rotation per region as a separate stage. LiteLLM in Kubernetes benefits from the standard rolling-update mechanism, complemented by a NetworkPolicy that makes /prompts/test reachable only from the dedicated prompt-engineering namespace.

What we actually did

We run LiteLLM in two productive tenant constellations. On 7 May at 14:30, roughly two hours after the BSI warning, we bumped the container image to 1.83.7-stable in both setups, with a short maintenance window and a health-check-based rollover. In the one tenant constellation that had been on a 1.81.x version since March, we rotated backend API keys in parallel — not because we had seen signs of compromise, but because the period during which the flaw was unknowingly open was not fully covered by logging. On the detection side we sharpened the Falco rule on the container hosts and put a reverse-proxy filter in place that continues to block /prompts/test calls from outside the explicitly named prompt-engineering network on 403.

Technical deep dive

The fix in 1.83.7 is instructive. The relevant patch changes the render path in /prompts/test from Environment to SandboxedEnvironment and additionally enables an allowlist of permitted filters and global functions that should be available in the sandboxed render. SandboxedEnvironment blocks attribute access to methods starting with _ and calls on a list of known unsafe methods. That structurally closes __class__.__mro__ and similar paths. It is not perfect — Jinja2 sandboxes have had their own bypass flaws in the past — but it is the right defensive layer for this endpoint.

The strategically more interesting question behind the flaw is: why was the endpoint unsandboxed in the first place, and why did code review not catch it? The honest answer is that /prompts/test was an “internal tooling” path originally intended as a CLI helper and later exposed via HTTP endpoint — without the sandbox requirement being carried visibly through the transition. For your own codebase, the question worth asking is: which render paths in our system take user input, and which of those run in an explicit sandbox environment?

Conclusion

CVE-2026-42203 considered alone is a known SSTI pattern escalation in a popular open-source project, with a clear patch and a manageable operational response. In combination with CVE-2026-42208 of 23 April the line is more unpleasant: the LiteLLM proxy layer has shown two structurally different flaws in the past 14 days, both sitting in places where most operators have historically invested little attention.

The question is not whether LiteLLM is a trustworthy tool — in our assessment it remains so. The question is whether the /prompts/* and key-management paths in your own installation receive the same attention as the /chat/completions path that makes the proxy valuable for your application. This week the answer is: not yet, but by Friday yes.

A personal background and technical details on hardening LiteLLM installations and MCP backends: ole-hartwig.eu.