A LiteLLM Key Is Not Permission to Run the Gateway
A shared AI gateway is a place where a team turns a business decision into a technical permission: this application may use these models, on these terms. A working request is only part of that contract. The more important question is what the same identity cannot do. Recent LiteLLM research gives operators a reason to examine that negative space, without mistaking a new explanation for a newly unpatched emergency.
Check Point’s 13 October analysis, tested against 1.77.7, explains two previously repaired, authenticated flaws. It reports demonstrations, not an observed exploitation campaign for these findings.
Two permissions crossed different boundaries
CVE-2026-35029 let low-privilege users reach /config/update without a proxy_admin check. Environment settings enabled local-file reading and administrator-credential changes; remote pass-through Python enabled code execution. The maintainer advisory identifies versions before 1.83.0 as affected.
CVE-2026-59823 required a valid virtual key. Nested user_config.api_base bypassed top-level routing restrictions, reaching proxy-accessible internal or external hosts. The researchers’ listener also received a configured provider credential, not proof of exposure in every integration. The separate advisory lists versions through 1.83.8 as affected.
A caller’s identity, permitted operations and approved destination are therefore separate review questions. A successful sign-in should not be the acceptance test for all three. Nor should the absence of an unauthenticated entry point make an internal service automatically low priority: legitimate application credentials still need deliberately limited authority.
The first fixes did not arrive together
The configuration flaw was first fixed in 1.83.0, linked to pull request 24823, merged 31 March. PyPI records 1.83.0 on 31 March and 1.83.9 on 17 April. The latter first fixes the separate routing flaw; its patch rejects user_config. “Both resolved as of 1.83.9” is a combined status, not a shared first-fix date.
Those are historical minimums for these two issues, not a recommendation to deploy an old release today. Establish the version actually running, select an appropriate maintained release and review its changes before deployment. A repository declaration, downloaded image and serving process are different evidence. An upgrade ticket should identify which one was checked and which person accepted the result.
Review a service, not just a version string
Consider a hypothetical organisation with one gateway serving a customer-support assistant, a development team and a finance experiment. The operator maintains the service; each team owns its application. A dashboard showing three successful requests makes the rollout look healthy. It does not explain whether one team can interfere with another, who approves a new dependency or who can recover service when a credential is withdrawn.
Start by writing a short permission contract for each workload. Name its owner, expected models, approved external dependencies and spending responsibility. Then name the people allowed to change that contract. Keep the service operator’s authority distinct from the application owner’s convenience. This is a proposed review method, not a claim that LiteLLM enforces every business policy automatically.
Choose a small set of assertions that would reveal a broken contract. A support application should retain its ordinary function while administrative changes remain unavailable to it. A dependency change should require the intended approval. Another team’s work should remain separate. Define an observable pass and failure for each assertion before testing, rather than deciding afterwards that any error message is reassuring.
Run that exercise in an authorised test environment with representative identities and controlled destinations. Do not probe arbitrary internal systems or production provider accounts to prove a point. Record which identity was used, the build under test, the expected outcome and the observed response. A rejected request is useful evidence only when the normal permitted task still works and the relevant server-side effect was also checked.
Give the investigation its own acceptance record
Software remediation and historical investigation need different owners and different conclusions. The operator can confirm a deployment. The incident lead must decide what the available records say about earlier activity. Do not turn the first answer into the second, or label an installation compromised simply because it once ran an affected version.
For the hypothetical three-team service, preserve an inventory of expected changes and compare it with available administrative and outbound-activity records. Ask the application owners to explain unfamiliar dependencies rather than asking only the platform team. Retention gaps belong in the conclusion. “No unexplained activity in the records we have” is narrower and more useful than an unsupported assurance that nothing happened.
If the review gives reason to distrust a credential, plan its replacement with the service that consumes it. Identify who can issue the replacement, where it must be installed and how success will be demonstrated. Preserve relevant evidence first where incident procedures require it. A rushed change that disables the assistant but leaves an overlooked background job untouched is neither a complete recovery nor a reliable exposure assessment.
What a finished review should leave behind
The useful output is a compact service record: a confirmed running build, named owners, the permission contract, repeatable negative tests and an honest investigation conclusion. Keep outstanding evidence gaps visible with a decision owner and review date. That makes the next release easier to assess and prevents a familiar product name from becoming a substitute for knowing what the deployed service can do.
The technical findings and demonstrations come from Check Point and the two maintainer advisories. The linked patch and package records establish the repair chronology. The three-team example and review method are BlackTree’s own analysis. These two findings should not be conflated with separate malicious-package incidents or other vulnerabilities merely because they involve LiteLLM.
