LiteLLM flaws expose the risks of centralising AI access

Businesses running LiteLLM versions older than 1.83.9 face two vulnerabilities that could let account holders gain administrative access to their AI gateway, according to Infosecurity Magazine. The fixes are available in version 1.83.9 and later. The business risk lies in what the gateway concentrates: access to AI services, provider credentials and the permissions supposed to keep ordinary users in their lane.

What happened

Check Point researchers identified two flaws, tracked as CVE-2026-35029 and CVE-2026-59823, in LiteLLM, an open-source tool connecting applications to model providers including OpenAI, Google and Anthropic. Infosecurity Magazine reports almost 100,000 downloads a month. That indicates substantial distribution, though downloads are not a count of distinct businesses or exposed installations.

The researchers detailed their findings in a blog post published on October 13. They reported both vulnerabilities to LiteLLM through coordinated disclosure, and the report identifies 1.83.9 as the version containing the fixes. It does not give a separate release date for that version.

CVE-2026-35029 concerns a missing authorisation check. An attacker could modify a runtime configuration that should be beyond an ordinary user's authority. According to Check Point, this could allow malicious Python modules to be loaded from cloud storage, potentially leading to remote code execution and full takeover of the gateway system.

CVE-2026-59823 involves server-side request forgery: making the server send requests somewhere it should not. In this case, redirecting the gateway's outbound requests could expose API keys belonging to AI providers. The distinction matters operationally. One flaw threatens control of the gateway; the other threatens credentials entrusted to it.

The access condition is also important. Check Point describes the danger as applying to anyone holding an account on a vulnerable deployment, including low-privileged users. That is not the same as establishing that an unauthenticated internet user can exploit it. The report does not describe confirmed attacks, named victims or measured losses; the reported consequences are capabilities the flaws could enable.

The background

An LLM gateway sits between a business application and one or more model providers. Rather than connecting separately to each provider's API, the application sends requests through the gateway, which forwards them to the appropriate model backend. This creates a common control point for services that might otherwise be managed separately.

That arrangement serves purposes beyond routing. Such gateways often centralise logging, usage tracking, credential management and user permissions. In deployments using these functions, the gateway is both a traffic intermediary and an administrative system. Its security therefore matters even when the underlying model providers are operating normally.

The credential concentration is particularly consequential. Infosecurity Magazine notes that gateways can hold API keys for every AI provider an organisation uses. A weakness in one shared component can therefore put several provider relationships within reach, rather than confining the exposure to one application or one model service. The convenience of central management comes with a correspondingly concentrated security obligation.

The missing permission check illustrates a separate distinction: assigning a role is not the same as enforcing it. A deployment can appear orderly, with administrators and restricted users correctly labelled, while allowing those restricted users to perform privileged actions. The vulnerability concerns the authority exercised by an account, not merely whether its holder has successfully logged in.

These are infrastructure vulnerabilities, not evidence that OpenAI, Google or Anthropic themselves were breached. Nor does the reported exploit depend on persuading a model to ignore its instructions. The relevant failure is in conventional application controls surrounding AI access. Calling the software an AI gateway does not change the nature of the permission check it omitted.

What people are saying

Mateo Rojas-Carulla, Check Point's head of research for AI agent security, described the practical risk as an account holder taking over a vulnerable gateway and putting it to malicious use. His emphasis is on the gap between ordinary membership and administrative power: an account need not have been intended for privileged work to become a route to it.

Christopher Jess, senior R&D manager at application-security company Black Duck, characterised the findings as familiar application-security failures. He pointed to low-privileged users reaching administrative functions, with consequences including code execution. His assessment places the incident less in the category of novel AI behaviour than in the older, well-populated category of insufficient access control.

Jess also argued that centralising AI access makes gateways especially valuable targets, and warned that security fundamentals are being subordinated to rapid AI adoption. The disclosed flaws support the narrower point about gateway exposure. The report alone cannot establish how prevalent that trade-off is across the industry; his broader diagnosis remains an attributed assessment.

The account provides no separate LiteLLM statement explaining how the flaws arose or what development practices might change. The concrete response it records is the availability of patched versions following disclosure. That is evidence of remediation, not a basis for inferring either the maintainers' intentions or their wider security record.

What happens next

The immediate task is version-specific: establish whether the organisation runs LiteLLM and whether the deployed version predates 1.83.9. Check Point urges users to update. A general assertion that an AI service is maintained is not enough to resolve this question; the relevant fact is the version actually handling requests.

Check Point also recommends reviewing gateway accounts and removing those no longer needed. Because the reported attack path includes ordinary account holders, this review cannot stop at the administrator list. An unnecessary low-privilege account still falls within the access population the researchers identify as potentially dangerous.

Credential rotation is a separate, conditional step. The researchers advise rotating AI provider API keys stored in LiteLLM if there is any indication of unauthorised gateway access before patching. Updating the software closes the reported flaws; it does not make a previously exposed credential secret again. This is why remediation and investigation answer different questions.

Permissions also need to be tested in practice, according to Check Point. The useful test is whether a restricted user is actually prevented from performing privileged operations, not whether the configuration assigns a suitably modest role. That recommendation follows directly from the authorisation failure rather than from a general preference for more security paperwork.

The researchers further recommend including LLM gateways in penetration tests and vulnerability assessments alongside web applications and cloud infrastructure. For businesses, this changes the scope of an existing security activity rather than requiring an entirely new discipline. AI tooling must be visible to the people already responsible for testing software boundaries.

For UK firms following the unresolved AI safeguards in the cyber bill, the distinction between policy and operational control is practical. The report's patch threshold is already explicit; resolving these two flaws does not depend on a future legislative answer. US businesses using the same software face the same version-specific remediation question.