Most organizations that have adopted AI have a layer they do not think about much: the gateway. It is the service that sits between your application and the AI providers, OpenAI, Anthropic, Google. It manages routing, load balancing, cost tracking, and API key storage. It knows everything your application knows about your AI usage, and it holds the credentials that make it all work.
Two critical vulnerabilities in LiteLLM, one of the most widely deployed open-source AI gateways, demonstrate exactly why that layer deserves the same security scrutiny as your authentication infrastructure.
What Check Point Research found
Check Point Research published findings on two flaws in LiteLLM (tested in version 1.77.7). Both have been fixed in version 1.83.9.
CVE-2026-35029: broken access control on the configuration endpoint
The /config/update endpoint, which manages runtime configuration for the gateway, had no authorization check beyond basic authentication. Any user with an account, including read-only users, could reach it. From there an attacker could:
- Extract sensitive internal files by changing the logo path variable and fetching the result through /get_image. This includes configuration files that may contain secrets, credentials, or internal service addresses.
- Overwrite administrator credentials by changing the UI username and password variables, locking out legitimate admins.
- Execute arbitrary code by configuring a pass-through endpoint to load a malicious Python module from cloud storage. The attacker points LiteLLM at an S3 or GCS bucket they control, and the gateway downloads and runs the module.
This is not a privilege escalation chain that requires chaining multiple steps. Each of these impacts is available directly to any authenticated low-privilege user.
CVE-2026-59823: server-side request forgery in the Clientside LLM Credentials feature
The /chat/completions endpoint accepted a user_config parameter without validation. Any gateway user could direct LiteLLM to send requests to a server they control. Because LiteLLM includes provider API keys in default headers, those keys are transmitted to the attacker-controlled endpoint in plaintext.
The result: an attacker with any level of gateway access can steal your OpenAI, Anthropic, or Google API keys without ever compromising the providers themselves. They then use your provider accounts, on your billing, without your knowledge.
Context: the PyPI supply-chain incident
This is not the first time LiteLLM has been in the crosshairs. In March 2026, the threat group TeamPCP published malicious LiteLLM package versions 1.82.7 and 1.82.8 to PyPI. Any team that updated during that window and did not verify checksums received a compromised package. Check Point's disclosure this week has renewed attention on the broader LiteLLM supply chain.
What to do
The fix is clear. Upgrade to LiteLLM version 1.83.9 or any later version. Both CVEs are patched.
If you suspect unauthorized access, rotate every AI provider API key that flowed through the gateway. This means OpenAI, Anthropic, Google, and any other provider you have configured. Keys stolen via CVE-2026-59823 have been used to make API calls under your account. Check billing dashboards and API usage logs for unexpected activity before and after rotation.
Audit access to your LiteLLM instance. Who has user accounts? Are any of those accounts shared? Does your gateway sit on an internet-exposed port or is it restricted to internal network traffic?
If you updated LiteLLM between March 2026 and today and did not verify package integrity, review your deployment history against the known malicious versions (1.82.7 and 1.82.8).
The bigger point
The AI gateway sits at a unique position in your stack. It has credentials for every AI provider you use. It processes every request your applications make. It often runs with broad network access to internal services. And most teams treat it as infrastructure that, once configured, is maintenance-free.
CVE-2026-35029 and CVE-2026-59823 are a reminder that every piece of your AI infrastructure is attack surface. Treat your gateway access controls, API key rotation policies, and network exposure with the same rigor you apply to your authentication systems. The consequences of a compromise here are not hypothetical: billing abuse, credential theft, and code execution on the same host that routes your sensitive data to AI providers.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want to talk through AI infrastructure security for your organization.