LLM gateways are becoming a quiet control plane for modern AI applications. They route prompts to providers, hold API keys, enforce rate limits, log usage, and often expose administrative configuration paths. That makes them useful infrastructure — and a high-value target when access control or request validation breaks.

Check Point Research reported multiple high-impact vulnerabilities in LiteLLM, an open-source LLM gateway, after assessing version 1.77.7. The issues are tracked as CVE-2026-35029 and CVE-2026-59823 and were fixed in LiteLLM 1.83.9.

What Check Point Found

The most important finding was not exotic AI magic. It was a missing authorization check on a sensitive configuration endpoint. According to Check Point, a low-privileged authenticated UI user could reach a runtime configuration update path that should have been restricted to administrators.

From that single control-plane weakness, the researchers described several impact paths:

  • Configuration tampering: lower-privileged users could modify gateway runtime settings.
  • Arbitrary file read: attacker-controlled configuration values could influence a file-serving path and expose files accessible to the gateway process.
  • Administrative account takeover: environment-backed UI credentials could be overwritten, allowing full proxy-admin access.
  • Remote code execution: pass-through endpoint configuration could load a Python module from remote storage, turning configuration access into code execution.
  • Provider key exposure through SSRF: a separate clients-side credential feature could redirect LLM traffic and leak API credentials to attacker-controlled infrastructure.

LiteLLM has patched the reported issues, but the broader lesson applies to every organization deploying AI gateways, model routers, prompt brokers, or internal LLM proxy services.

Why This Matters

For many SMBs and government contractors, AI infrastructure is being deployed faster than traditional security review cycles can keep up. A gateway may start as a developer convenience, then quickly become the production path for customer support tools, document summarization, code assistants, security automations, and internal knowledge systems.

That gateway may have access to:

  • LLM provider API keys and spend limits
  • internal prompts and sensitive business data
  • model routing rules and fallback providers
  • logging and observability data
  • network reachability into internal services

If an attacker can change gateway configuration, the blast radius can extend beyond the AI application itself. They may be able to steal provider keys, redirect traffic, read local secrets, abuse model spend, or use the gateway host as a foothold into the surrounding environment.

Defensive Takeaways

  • Patch LiteLLM immediately: update to version 1.83.9 or newer if LiteLLM is in use.
  • Treat AI gateways as privileged infrastructure: classify them closer to identity, secrets, and CI/CD systems than ordinary web apps.
  • Restrict administrative endpoints: put gateway admin surfaces behind VPN, SSO, MFA, and role-based access controls. Do not expose them broadly.
  • Audit low-privileged users: verify that non-admin accounts cannot change runtime configuration, environment variables, provider settings, routing rules, or pass-through endpoints.
  • Rotate exposed provider keys: if compromise is suspected, rotate LLM provider keys and review usage spikes, unusual model calls, and abnormal destination routing.
  • Limit outbound egress: prevent the gateway from calling arbitrary cloud storage buckets, attacker-controlled hosts, metadata services, or internal-only systems unless explicitly required.
  • Monitor configuration changes: alert on updates to model lists, API base URLs, pass-through endpoints, environment variables, admin users, and authentication settings.
  • Run the gateway with least privilege: reduce file-system access, avoid broad cloud IAM permissions, and separate gateway secrets from application secrets.

Bulwark Black Assessment

This is a useful reminder that AI security is still infrastructure security. The models are new, but the failure modes are familiar: missing authorization, permissive routing, SSRF, dangerous dynamic loading, overpowered service accounts, and weak change monitoring.

The practical move is not to slow down AI adoption. It is to put AI gateways into the same control framework already used for VPNs, identity providers, CI/CD runners, EDR management consoles, and cloud admin planes. Inventory them, patch them, isolate them, log them, and review who can change their configuration.

For government contractors especially, LLM gateways should be treated as part of the controlled technical boundary. If prompts, documents, tickets, security alerts, source code, or customer data transit the gateway, then its configuration and secrets are mission-critical assets — not just developer tooling.