CVE-2026-12773 is a high-severity improper authentication flaw (CVSS 7.3) in BerriAI LiteLLM up to version 1.59.8. The UserAPIKeyAuth function in the MCP proxy can be manipulated remotely. The record names no fixed version, so upgrade, check the advisory and limit who can reach the proxy.
What's affected
From the CVE record:
- Product: BerriAI LiteLLM, versions up to and including 1.59.8.
- Component: the MCP Proxy, function
UserAPIKeyAuthinlitellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py. The path includes_experimental, which suggests a feature that was still marked experimental. - Weakness classes: CWE-287 (improper authentication) and CWE-303 (incorrect implementation of an authentication algorithm).
- Severity: CVSS 7.3: network reachable, no privileges, no user interaction, Low impact on each of confidentiality, integrity and availability.
- Fixed version: not named in the record. The record says the vendor was contacted early about the disclosure.
- Exploitation: the record says the exploit has been made available to the public. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
LiteLLM is a Python package, so the version check is quick.
pip show litellm
pip list 2>/dev/null | grep -i litellm
Run it in every environment: servers, containers and developer machines that run the proxy. For lockfiles, you can paste requirements.txt into the free scan at gold.safeguard.sh/scan.
Then check how the proxy is deployed:
- Is the MCP server feature of the LiteLLM proxy turned on in your configuration? The affected code is in the MCP part of the proxy.
- Is the proxy reachable from the internet or from broad internal networks?
- Which keys, models and tools can a caller reach through the proxy? That is the size of the problem if authentication fails.
What to do now
- Upgrade LiteLLM to the current release. Upgrading from 1.59.8 or earlier is sensible on its own, but confirm in the project release notes and the Red Hat security page for this CVE that the fix is included.
- If you do not use the MCP proxy feature, turn it off in the configuration.
- Do not expose the proxy to the internet. Put it behind a network control or an authenticating gateway, so that the proxy's own key check is not the only barrier.
- Use separate keys for separate teams, set spending and rate limits on them, and rotate keys that you cannot account for.
- Review proxy logs for calls to the MCP endpoints that you cannot tie to a known client.
Why it matters
An LLM gateway is a high value target. It sits in front of model providers, and it commonly holds the upstream API keys, the virtual keys given to teams and the access to tools that agents can call. A flaw in how the gateway authenticates a caller puts all of that on the line. In the MCP proxy, a caller that is wrongly accepted can use the tools exposed through it.
The record classes the problem as improper authentication and as an incorrect implementation of an authentication algorithm. It does not describe the logic error, and we do not guess at it. The score of 7.3 comes from easy network access and no required privileges, with Low impact ratings for each of the three security properties. Those ratings depend on what the MCP tools can do in your deployment, so a proxy that fronts powerful tools deserves more concern than the number suggests.
Public exploit information and a project that was told early but has not published a clear fix in the record make exposure reduction the first step. The version in the record, 1.59.8, is old, which means many teams have already moved past it by routine upgrades. If you are one of them, check which release you run and read the notes. If you are not, a dependency inventory is the fastest way to find the forgotten deployments.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which LiteLLM version fixes this?
The record does not say. It lists versions up to 1.59.8 as affected. Check the project release notes and the Red Hat page listed in the record.
I do not use MCP. Am I exposed?
The affected code is in the MCP proxy component. If the feature is not enabled, the described path is not in use, but upgrading is still a good idea.
Sources
- Gold entry and CVE record: CVE-2026-12773.
- References listed in the record, not retrievable for this review: Red Hat CVE page, VulDB entry and the researcher gist.
Last reviewed: 19 October 2026.
