BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the /completions endpoint. The vulnerability arises from the hfchattemplate method processing the chattemplate parameter from the tokenizerconfig.json file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious tokenizerconfig.json files that execute arbitrary code on the server.

BerriAI/litellm version v1.35.8 contains a vulnerability where an attacker can achieve remote code execution. The vulnerability exists in the adddeployment function, which decodes and decrypts environment variables from base64 and assigns them to os.environ. An attacker can exploit this by sending a malicious payload to the /config/update endpoint, which is then processed and executed by the server when the getsecret function is triggered. This requires the server to use Google KMS and a database to store a model.

LiteLLM 1.18.10 contains a remote code execution vulnerability in its MCP server creation functionality. The application allows users to add MCP servers via a JSON configuration specifying arbitrary command and args values. LiteLLM executes these values on the host without validation, enabling attackers to run arbitrary operating system commands. Successful exploitation may result in remote code execution with the privileges of the LiteLLM process.

Impact

A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.

The auth layer derived the effective route from request.url.path in litellm/proxy/auth/authutils.py::getrequestroute(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.

Most deployments are not affected. The bypass is blocked by any upstream layer that validates or normalizes Host, such as:

- a CDN or WAF, such as Cloudflare - a reverse proxy with servername allowlists - a host-based load balancer

LiteLLM Cloud customers are not affected.

Patches

Fixed in 1.84.0. Upgrade to 1.84.0 or later. No configuration change is required.

Workarounds

If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the Host header before forwarding (a CDN/WAF, a reverse proxy with explicit servername allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.

References

- Patched release: v1.84.0

Discovery Credit: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)

Summary

On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware, and replace all 7 tags in aquasecurity/setup-trivy with malicious commits.

On March 22, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.5 and v0.69.6 DockerHub images.

Exposure Window

| Component | Start (UTC) | End (UTC) | Duration | | ------------- | ---------------------- | ----------------- | --------- | | trivy v0.69.4 | 2026-03-19 18:22 [^1] | 2026-03-19 ~21:42 | ~3 hours | | trivy-action | 2026-03-19 ~17:43 [^2] | 2026-03-20 ~05:40 | ~12 hours | | setup-trivy | 2026-03-19 ~17:43 [^2] | 2026-03-19 ~21:44 | ~4 hours | | dockerhub trivy images v0.69.5 and v0.69.6 | 2026-03-22 15:43 | 2026-03-22 ~01:40 | ~10 hours |

[^1]: Time when v0.69.4 release artifacts became publicly available. The malicious tag was pushed at ~17:43 UTC, triggering the release pipeline. [^2]: Earliest suspicious activity observed in our audit log. Affected Components

Note that all malicious components, artifacts, commits, etc have been removed from all sources and destinations (yet they may linger in intermediary caches). Use this information to understand if you have been exposed to the malicious artifacts during the exposure window.

trivy binary and image

Users are affected if they utilized: 1. trivy binaries version v0.69.4 (or latest during the exposure window) distributed via GitHub, Deb, RPM. 2. trivy container images v0.69.4 (or latest during the exposure window) distributed via GHCR, ECR public, Docker Hub. 3. trivy container images v0.69.5 and v0.69.6 (or latest during the exposure window) distributed via Docker Hub.

Users are not affected if they utilized: 1. trivy (binary or image) version v0.69.3 or earlier. 1. v0.69.3 is protected by GitHub's immutable releases feature (enabled March 3, before v0.69.3 was published). 2. v0.69.2 predates immutable releases enablement but integrity can be verified via sigstore signatures (see "How to Verify" section below). 2. trivy images referenced by digest. 4. trivy binaries built from source. 1. The malicious code was not committed to Trivy's main branch. It was fetched and built on the ephemeral runner, and also committed to a v0.70.0 branch but no release or git tag was ever pushed. 5. homebrew from official formula (brew install trivy) 1. The official homebrew formula is building trivy directly from source. 2. There's an additional custom trivy tap which was compromised as part of the v0.69.4 release, but that tap requires special installation and is not even mentioned in the trivy documentation.

aquasecurity/trivy-action GitHub Action

Users are affected if they utilized: 1. Any tags prior except 0.35.0 (0.0.1 – 0.34.2) to reference the action. 2. the action's version: latest parameter explicitly (not the default) during the trivy binary exposure window. 3. SHA pinning to a commit prior to 2025-04-09. 1. trivy-action started pinning setup-go with pull request trivy-action#456. If you pinned trivy-action to a commit prior to that PR (merged 2025-04-09), then you would get a safe trivy-action but it would get a malicious setup-trivy, if invoked during the setup-trivy exposure window.

Users are not affected if they utilized: 1. 0.35.0 tag 1. 0.35.0 is protected by GitHub's immutable releases feature (enabled March 4, before 0.35.0 was published) and was not affected by the tag hijacking attack. 2. SHA pinning to a safe commit commit after 2025-04-09.

aquasecurity/setup-trivy GitHub Action

Users are affected if they utilized: 1. Any version without pinning.

Users are not affected if they utilized: 1. SHA pinning to a safe commit.

Attack Details

Root Cause

This incident is a continuation of the supply chain attack that began in late February 2026. Following the initial disclosure on March 1, credential rotation was performed but was not atomic (not all credentials were revoked simultaneously). The attacker could have use a valid token to exfiltrate newly rotated secrets during the rotation window (which lasted a few days). This could have allowed the attacker to retain access and execute the March 19 attack. Trivy v0.69.4 binary and container images

The attacker created a malicious release by: 1. Pushing a commit (1885610c) that swapped the actions/checkout reference to an imposter commit (70379aad) containing a composite action that downloaded malicious Go source files from a typosquatted domain 2. Adding --skip=validate to goreleaser to bypass binary validation 3. Tagging this commit as v0.69.4, triggering the release pipeline

The compromised release was distributed across Trivy's regular distribution channels channels: GHCR, ECR Public, Docker Hub (both 0.69.4 and latest tags), deb/rpm packages, and get.trivy.dev.

The attacker attempted to release a v0.70.0 malicious release but that was stopped prematurely. trivy-action tag hijacking

The attacker force-pushed 76 of 77 version tags to malicious commits that injected an infostealer into entrypoint.sh. The malicious code executes before the legitimate Trivy scan and does the following:

1. Dumps Runner.Worker process memory via /proc/<pid>/mem to extract secrets. Sweeps 50+ filesystem paths for SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, Docker configs, .env files, database credentials, and cryptocurrency wallets. 2. Encrypts collected data using AES-256-CBC with RSA-4096 hybrid encryption. 3. Transmits to attacker-controlled infrastructure. If exfiltration fails and INPUTGITHUBPAT is set, creates a public tpcp-docs repository on the victim's GitHub account and uploads stolen data as a release asset.

setup-trivy release replacement

All 7 existing tags (v0.2.0 – v0.2.6) were force-pushed to malicious commits. The malicious action.yaml contained the same infostealer as trivy-action, injected as a "Setup environment" step that executes before the legitimate Trivy installation. We have removed all malicious releases within ~4 hours and re-created v0.2.6 with safe content. Tags v0.2.0 – v0.2.5 were not restored.

Trivy v0.69.5 and v0.69.6 docker image published. The attacker created aquasec/trivy:0.69.5 and aquasec/trivy:0.69.6 with the same C2 domain as the v0.69.4 payload, and pushed them directly to Docker Hub using separately-compromised Docker Hub credentials (not via GitHub). No corresponding GitHub tags or releases existed. We have removed all tags related to 0.69.5 and 0.69.6 and restored the latest tag to the safe 0.69.3 tag.

Recommended Actions

Update to Known-Safe Versions

| Component | Safe Version | | ------------ | ---------------- | | Trivy binary | v0.69.2, v0.69.3 | | trivy-action | v0.35.0 | | setup-trivy | v0.2.6 |

Regarding trivy-action: The original tags (0.0.1 – 0.34.2) were deleted during remediation. Because the attacker's force-push caused these tags to be treated as immutable releases by GitHub, they cannot be re-created with the same names. New tags have been published with a v prefix (v0.0.1 – v0.34.2) pointing to the original legitimate commits. Three tags: v0.0.10, v0.34.1, and v0.34.2 have not yet been restored. If you need to reference a version older than 0.35.0, use the v-prefixed tag (e.g., aquasecurity/trivy-action@v0.34.0 instead of @0.34.0). Rotate All Potentially Exposed Secrets

Based on information shared above, if there is any possibility that a compromised version ran in a project's environment, all secrets accessible to affected pipelines must be treated as exposed and rotated immediately. Audit Trivy Versions Check whether a project's organization pulled or executed Trivy v0.69.4 from any source. Remove any affected artifacts immediately. Audit GitHub Action References Review all workflows using aquasecurity/trivy-action or aquasecurity/setup-trivy. Check workflow run logs from March 19–20, 2026 for signs of compromise. Search for Exfiltration Artifacts Look for repositories named tpcp-docs in project's GitHub organization. The presence of such a repository may indicate that the fallback exfiltration mechanism was triggered and secrets were successfully stolen. Pin GitHub Actions to Full SHA Hashes Pin GitHub Actions to full, immutable commit SHA hashes, don't use mutable version tags. As described here: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions How to Verify Existing Installations

Binary verification

bash Download binary and sigstore bundle curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy0.69.2Linux-64bit.tar.gz" curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy0.69.2Linux-64bit.tar.gz.sigstore.json"

Verify signature $ cosign verify-blob \ --certificate-identity-regexp 'https://github\.com/aquasecurity/' \ --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \ --bundle trivy0.69.2Linux-64bit.tar.gz.sigstore.json \ trivy0.69.2Linux-64bit.tar.gz Verified OK

Check signing timestamp $ date -u -d @$(jq -r '.verificationMaterial.tlogEntries[].integratedTime' trivy0.69.2Linux-64bit.tar.gz.sigstore.json) Sat Mar 1 19:11:02 UTC 2026 ✅ Signed on Mar 1, before the attack on Mar 19

Container image verification

bash Verify signature and get image digest $ cosign verify \ --certificate-identity-regexp 'https://github\.com/aquasecurity/' \ --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \ --new-bundle-format \ ghcr.io/aquasecurity/trivy:0.69.2 Verification for ghcr.io/aquasecurity/trivy:0.69.2 -- The following checks were performed on each of these signatures: - The cosign claims were validated - Existence of the claims in the transparency log was verified offline - The code-signing certificate was verified using trusted certificate authority certificates

Get digest and check all signing timestamps via Rekor $ DIGEST=$(cosign verify \ --certificate-identity-regexp 'https://github\.com/aquasecurity/' \ --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \ --new-bundle-format -o json ghcr.io/aquasecurity/trivy:0.69.2 2>/dev/null | \ jq -r '.[0].critical.image."docker-manifest-digest"')

$ rekor-cli search --sha "$DIGEST" | grep -v 'Found' | while read uuid; do rekor-cli get --uuid "$uuid" | grep IntegratedTime done IntegratedTime: 2026-03-01T19:13:52Z IntegratedTime: 2026-03-01T19:13:47Z IntegratedTime: 2026-03-01T19:13:57Z IntegratedTime: 2026-03-01T19:13:54Z IntegratedTime: 2026-03-01T19:13:46Z IntegratedTime: 2026-03-01T19:13:37Z ✅ All signed on Mar 1, before the attack on Mar 19

Resources

- https://github.com/aquasecurity/trivy/discussions/10425

Impact

When JWT authentication is enabled (enablejwtauth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.

This configuration option is not enabled by default. Most instances are not affected.

An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled.

Patches

Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.

Workarounds

Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.

BerriAI LiteLLM contains a SQL injection vulnerability that allows an attacker to read data from the proxy's database and potentially modify it, leading to unauthorized access to the proxy and the credentials it manages.

BerriAI/litellm version 1.40.12 contains a vulnerability that allows remote code execution. The issue exists in the handling of the 'postcallrules' 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.

Impact

The POST /guardrails/testcustomcode endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process — which runs as root in the default Docker image.

Reaching the endpoint requires a proxy-admin credential in default configurations.

Patches

Fixed in 1.83.11. The hand-rolled sandbox has been replaced with RestrictedPython. Upgrade to 1.83.11 or later.

Workarounds

If upgrading is not immediately possible, block POST /guardrails/testcustomcode at your reverse proxy or API gateway.

References

- Patched release: v1.83.10-stable

Impact

LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.

The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object. This allowed requests with a fabricated Authorization header to reach MCP tooling without a valid LiteLLM key.

An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP.

Patches

The issue is fixed in 1.84.0.

We recommend upgrading to 1.84.0 or later.

Workarounds

If upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway.

References

v1.84.0

Impact

The /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to do the following:

- Modify proxy configuration and environment variables - Register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution - Read arbitrary server files by setting UILOGOPATH and fetching via /getimage - Take over other priveleged accounts by overwriting UIUSERNAME and UIPASSWORD environment variables

Patches

Fixed in v1.83.0. The endpoint now requires proxyadmin role.

Workarounds

Restrict API key distribution. There is no configuration-level workaround.

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.

LiteLLM prior to 1.83.14 allows an authenticated internaluser to create API keys with access to routes that their role does not permit. When generating a key, the allowedroutes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internaluser to proxyadmin.

LiteLLM prior to 1.83.10 allows a user to modify their own userrole via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxyadmin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the orgadmin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.80.5 to before version 1.83.7, the POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. This issue has been patched in version 1.83.7.

BerriAI's litellm, in its latest version, is vulnerable to arbitrary file deletion due to improper input validation on the /audio/transcriptions endpoint. An attacker can exploit this vulnerability by sending a specially crafted request that includes a file path to the server, which then deletes the specified file without proper authorization or validation. This vulnerability is present in the code where os.remove(file.filename) is used to delete a file, allowing any user to delete critical files on the server such as SSH keys, SQLite databases, or configuration files.

A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. This vulnerability allows users to specify the apibase parameter when making requests to POST /chat/completions, causing the application to send the request to the domain specified by apibase. This request includes the OpenAI API key. A malicious user can set the apibase to their own domain and intercept the OpenAI API key, leading to unauthorized access and potential misuse of the API key.

A Denial of Service (DoS) vulnerability exists in berriai/litellm version v1.44.5. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service.

In berriai/litellm before version 1.44.12, the litellm/litellmcoreutils/litellmlogging.py file contains a vulnerability where the API key masking code only masks the first 5 characters of the key. This results in the leakage of almost the entire API key in the logs, exposing a significant amount of the secret key. The issue affects version v1.44.9.

In berriai/litellm version v1.52.1, an issue in proxyserver.py causes the leakage of Langfuse API keys when an error occurs while parsing team settings. This vulnerability exposes sensitive information, including langfusesecret and langfusepublickey, which can provide full access to the Langfuse project storing all requests.

A code injection vulnerability exists in the berriai/litellm application, version 1.34.6, due to the use of unvalidated input in the eval function within the secret management system. This vulnerability requires a valid Google KMS configuration file to be exploitable. Specifically, by setting the UILOGOPATH variable to a remote server address in the getimage function, an attacker can write a malicious Google KMS configuration file to the cachedlogo.jpg file. This file can then be used to execute arbitrary code by assigning malicious code to the SAVECONFIGTODB environment variable, leading to full system control. The vulnerability is contingent upon the use of the Google KMS feature.

An SQL Injection vulnerability exists in the berriai/litellm repository, specifically within the /global/spend/logs endpoint. The vulnerability arises due to improper neutralization of special elements used in an SQL command. The affected code constructs an SQL query by concatenating an unvalidated apikey parameter directly into the query, making it susceptible to SQL Injection if the apikey contains malicious data. This issue affects the latest version of the repository. Successful exploitation of this vulnerability could lead to unauthorized access, data manipulation, exposure of confidential information, and denial of service (DoS).

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enablejwtauth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, he /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to modify proxy configuration and environment variables, register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution, read arbitrary server files by setting UILOGOPATH and fetching via /getimage, and take over other privileged accounts by overwriting UIUSERNAME and UIPASSWORD environment variables. Fixed in v1.83.0.

LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/testcustomcode URI.

berriai/litellm version 1.34.34 is vulnerable to improper access control in its team management functionality. This vulnerability allows attackers to perform unauthorized actions such as creating, updating, viewing, deleting, blocking, and unblocking any teams, as well as adding or deleting any member to or from any teams. The vulnerability stems from insufficient access control checks in various team management endpoints, enabling attackers to exploit these functionalities without proper authorization.

Impact

LiteLLM Skills archive extraction did not sufficiently validate file paths from uploaded skill ZIP archives. An authenticated user with access to LiteLLM LLM API routes, or a key whose allowedroutes includes /v1/skills, anthropicroutes, or llmapiroutes, could upload a crafted skill archive containing path traversal entries.

When the skill was processed for execution, those entries could be written outside the intended extraction/staging directory. This could allow arbitrary file write and may lead to code execution depending on deployment configuration and writable paths.

Patches

The issue is fixed in 1.83.7-stable.

LiteLLM recommens upgrading to 1.83.7-stable or later.

Workarounds

If upgrading is not immediately possible:

1. Block POST /v1/skills at your reverse proxy or API gateway. 2. Restrict Skills API access to trusted users only.

A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/experimental/mcpserver/auth/userapikeyauthmcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.

A vulnerability was determined in BerriAI litellm up to 1.82.2. This affects the function json.dumps of the file litellm/proxy/managementendpoints/uisso.py of the component SSO Debug Flow. Executing a manipulation can lead to missing authentication. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure.

SQL Injection vulnerability in BerriAI LiteLLM before 1.81.0 allows attackers to execute arbitrary commands via the key parameter to the "/key/block" and "/key/unblock" API endpoints.