Improper authorization in BerriAI LiteLLM Secret Resolution

A vulnerability has been found in BerriAI LiteLLM up to 1.94.0. This affects the function get_secret of the file secret_managers/main.py of the component Secret Resolution. The manipulation of the argument api_key leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

• BerriAI LiteLLM: the normalized record describes versions up to 1.94.0 as affected.
• The structured affected-version list supplied with the record explicitly marks 1.0 through 1.19 as affected, while the VulDB CNA entry lists versions from 1.0 through 1.94.0. Because these representations differ, treat LiteLLM up to 1.94.0 as potentially affected until branch-specific vendor guidance is available.
• The affected component is Secret Resolution, specifically the get_secret function in secret_managers/main.py and the api_key argument.
• The record supplies no confirmed fixed release or official solution.

The flaw is in the get_secret function in secret_managers/main.py, part of BerriAI LiteLLM's Secret Resolution component. The CNA detail states that manipulating the api_key argument with an unspecified input value leads to an improper authorization condition. The vulnerable logic is remotely reachable; the supplied attack metadata indicates that low privileges are required, no user interaction is needed, and attack complexity is low. The available evidence does not identify the endpoint, request schema, secret backend, precise authorization boundary, or exact data returned. Exposure of a secret belonging to another user or service is possible, but that consequence is an inference from the component's role rather than a confirmed exploit trace.

Remote exploitation is supported. The supplied attack metadata indicates low privileges are required, no user interaction is needed, and attack complexity is low; the exact authentication mechanism is not described. VulDB reports that technical details and a public proof of concept or exploit are available. The record does not establish active exploitation, identify a specific campaign, or provide a confirmed payload, endpoint, or indicator.

The primary technical outcome is unauthorized access to Secret Resolution results or actions that should be protected by the authorization check. Depending on what a returned credential controls, confidentiality, integrity, and availability of connected services could be affected, consistent with the supplied impact metadata. Organisational consequences may include credential rotation, unauthorized API use, unexpected cost, and exposure of data processed through those services. The evidence does not show host compromise, does not confirm privilege escalation beyond the affected authorization boundary, and does not identify the specific secrets that could be accessed.

Successful exploitation could allow an attacker to retrieve or use secrets outside the requester's intended authorization boundary. Because LiteLLM brokers model and API requests, exposed credentials could enable unauthorized use of connected services, unexpected charges, or access to data handled through those credentials. The record does not establish that a breach occurred, which secrets are exposed, or whether every deployment uses the vulnerable path. Public exploit availability increases the priority of reviewing LiteLLM instances exposed to untrusted networks.

1. If BerriAI LiteLLM up to 1.94.0 is deployed, treat it as potentially exposed. No exact fixed release is confirmed, so do not assume that a later or parallel branch is safe.
2. Restrict network access to the LiteLLM service with firewall or reverse-proxy controls, allowing access only from trusted sources while awaiting official guidance or a confirmed fix.
3. Audit API key and secret access. If unauthorized retrieval or credential exposure is suspected, rotate the affected credentials and review dependent services.
4. Monitor for abnormal API key use and compare it with expected users, services, and request sources. This is a precautionary measure, not a response to a confirmed indicator.

1. Inventory BerriAI LiteLLM deployments and record their versions, network exposure, and whether Secret Resolution is enabled.
2. Check whether get_secret is present in secret_managers/main.py and determine whether the logic can be reached through a remote service.
3. Review application logs and reverse-proxy telemetry, where available, for unusual requests reaching secret-resolution functionality or api_key values inconsistent with expected use. This is precautionary monitoring, not a vendor-confirmed indicator.
4. Compare API key and secret usage with expected users, services, sources, and times. Treat unusual retrieval or downstream use as a possible exposure signal.
5. No specific log field, signature, or indicator is confirmed; the absence of matching log evidence does not prove that a deployment is safe.