← All insights

Securing Your AI Gateway: Lessons From October's LiteLLM Flaws

A year ago, most AI use at a mid-sized company was people typing into a chat window. Now there are often a few internal tools, a coding assistant, maybe an agent pilot, all calling one or more AI providers. To keep that manageable, many IT teams put a gateway in the middle: one self-hosted service that holds the provider API keys, decides who can use which model and tracks spend.

That is a sensible design. It also creates a single server that holds every AI credential the company has. Two disclosures this month show why it deserves the same attention as your firewall or identity provider.

What was disclosed in October

LiteLLM. On October 13, 2026, Check Point Research published two vulnerabilities in LiteLLM, an open-source gateway that Check Point calls one of the most widely used. According to the researchers:

The research post describes proof-of-concept work only and does not report attacks in the wild. Check Point says its coordinated disclosure to LiteLLM began in October 2025, so teams that update regularly may already be on a fixed release. Check, do not assume.

GitLab AI Gateway. On October 2, 2026, GitLab fixed CVE-2026-90970, rated Critical at CVSS 9.9. GitLab says an authenticated user with Duo Agent Platform access could escape the prompt template sandbox and run arbitrary commands on the AI Gateway. Only self-hosted AI Gateway installations need to act; GitLab.com, GitLab Dedicated and self-managed instances using a GitLab-hosted gateway are already protected. Ten days later, GitLab’s October 12 patch release fixed CVE-2026-96893, a High-severity issue where crafted content in AI agent instructions could cause unintended command execution attributed to other users.

The common thread is not one vendor. It is that AI plumbing is ordinary server software with ordinary bugs, sitting on very valuable credentials.

Why the gateway is worth attacking

Check Point puts the risk plainly: the credentials a gateway holds provide “direct, billable access to AI providers with no further authentication required.” The same server typically also sees every prompt and response passing through it, manages user roles and tracks usage.

In practice, a compromised gateway can mean:

  • Stolen keys used to run up charges on your provider accounts.
  • Exposure of prompts and responses, which often contain customer data, contracts, code or internal financials.
  • A foothold inside your network, if the flaw allows code to run on the gateway host.

Notice who the attacker is in both October cases: someone who already has an account. Gateways are often rolled out quickly, with broad sign-up or a shared admin login, so “authenticated user” can mean a lot of people.

Find, patch and lock down

1. Inventory every AI gateway and proxy. Look beyond the one IT installed. Developers and data teams often stand up LiteLLM, an open-source proxy or a vendor’s self-hosted gateway on a spare VM or in a container. Search container registries, cloud accounts and outbound traffic to AI provider domains for hosts you do not recognize.

2. Patch to fixed versions. LiteLLM to 1.83.9 or later. Self-hosted GitLab AI Gateway to 19.2.4, 19.3.2 or 19.4.1, and GitLab itself to 19.4.2, 19.3.5 or 19.2.8 depending on your release line. Add these components to the same patch tracking you use for servers, rather than leaving them with whoever deployed them.

3. Review accounts and roles. Check Point recommends auditing who has access and verifying that limited-role users are actually restricted. Turn off open sign-up, connect the gateway to your identity provider with multi-factor authentication, remove shared admin logins, and test a low-privilege account against admin functions yourself.

4. Rotate provider keys if in doubt. If a vulnerable version was reachable by people you cannot fully account for, Check Point advises rotating the AI provider API keys stored in the gateway. Set spending limits and usage alerts at each provider so stolen keys show up as a billing anomaly within hours, not at month end.

5. Restrict the network. The gateway should not be reachable from the internet unless there is a clear reason. Limit its outbound traffic to the provider endpoints it actually uses; that makes request-forgery flaws much harder to exploit.

6. Log and watch it. Send gateway logs to wherever your other security logs go. Alert on configuration changes, new admin accounts and sudden jumps in token use.

7. Include it in testing. Check Point recommends bringing LLM gateways into penetration tests and vulnerability assessments. If your scanner or testing firm does not cover these tools, ask them to.

Agents raise the stakes

As AI agents take on real actions, the gateway and agent platform become the place where permissions are enforced. The joint guidance CISA published with five partner agencies in May, Careful Adoption of Agentic AI Services, says agents should not be granted broad or unrestricted access, and calls for strong identity management, layered defenses and continuous monitoring. Give each agent or integration its own key with its own limits, so one leak does not expose everything and one key can be revoked without breaking the rest.

Questions to ask this week

  • Which AI gateways, proxies or self-hosted AI components run anywhere in our environment, and who owns each one?
  • Are LiteLLM and any self-hosted GitLab AI Gateway on fixed versions today?
  • Who can log in to each gateway, and does a low-privilege account really have low privileges?
  • Are provider keys separated by application, with spending limits and alerts?
  • Can the gateway reach anything other than the AI providers it needs?
  • Are gateway logs in our security monitoring, and is the gateway in scope for our next vulnerability assessment?

If you would like an independent view of how your AI tools fit into your security and technology plans, get in touch.

Get new articles by email

How we handle what you send us: Privacy Policy.