LiteLLM Supply Chain Attack Exposes AI Gateway and CI/CD Credentials

LiteLLM’s second supply chain compromise this year shows how an AI gateway’s release pipeline can become a route into broader enterprise systems. Attackers used stolen developer credentials to publish a malicious release that could steal secrets and maintain remote access to infected machines.

Two-hour package exposure, wider container risk

Version 1.107.0 appeared on the Python Package Index (PyPI) and in official Docker images on October 21. LiteLLM said the Python packages remained available for approximately two hours before removal. Affected images were withdrawn or replaced later that day. The exposure included Docker images published under the latest, main-latest and main-stable tags.

According to cybersecurity firm Aikido, code bundled with the package ran when Python started, even if an application never imported LiteLLM. It sought sensitive data, including cloud credentials and API keys stored in LiteLLM’s database. Aikido also reported a remote access trojan that periodically contacted attacker-controlled infrastructure, retrieving and executing code every hour. Removing the package alone may therefore leave systems at risk.

LiteLLM said attackers used stolen GitHub credentials linked to three developer accounts to alter the release workflow and redirect it to a lookalike repository controlled by the attackers. The company believes logs from an internet-facing internal deployment may have exposed the credentials. It also identified circumstances where Claude Code could return GitHub authentication tokens in responses that LiteLLM later logged. The initial route into the deployment remains unknown.

The company said the incident was contained and customers using its private enterprise registry were unaffected. For organizations that ran the compromised open-source package or images, LiteLLM advised treating systems as potentially breached and rotating exposed credentials.

A gateway can extend the blast radius

The exposure reaches beyond model access. Aikido said the malware targeted Kubernetes service account tokens and secrets used by CI/CD systems, including GitLab and Jenkins. What attackers could do next would depend partly on the permissions granted to each deployment and the credentials it could access.

“A compromised LiteLLM gateway provides a strong foothold to hackers and could expose far more than AI API keys,” said Keith Prabhu, CEO of Confidis. IDC research director Sakshi Grover described AI gateways as “privileged enterprise infrastructure”: centralizing access to models can support governance, she said, while also concentrating trust in one service.

A compromised gateway could also interrupt business applications that rely on it. IDC’s Future Enterprise Resiliency and Spending Survey, conducted in July 2026, found that 95% of enterprises surveyed worldwide had at least one company-funded agent-enabled workflow in production. That makes the gateway’s availability and integrity relevant to workflows beyond AI teams.

Response needs to account for persistence

Prabhu said security teams should not treat the event as a package removal task. His recommendations include locating affected installations and images, isolating suspected systems, preserving forensic evidence, and rebuilding from trusted software. He also urged organizations to review logs for signs of persistent access or credential misuse and rotate every secret the compromised deployment could reach, including cloud and development pipeline credentials.

Grover cautioned against launching Python or pip in suspected environments, since startup hooks could run again. She recommended checking package versions and container image digests across production, developer machines and CI runners. “Missing indicators do not prove an environment is clean,” she said.

Teams can also compare AI usage telemetry with cloud and identity audit logs to spot possible misuse. Unusual token consumption may help reveal unauthorized activity, though attackers could keep usage low enough to avoid a visible spending spike.

Signing alone cannot validate a release

This is LiteLLM’s second reported supply chain incident of the year. In March, malicious package versions were distributed after a compromise the project linked to the Trivy security scanner used in its release pipeline.

LiteLLM subsequently moved releases to a private repository and introduced signed Docker images. In this incident, the attackers’ stolen GitHub credentials let them alter the workflow that signed and published the software. A signature can show that an artifact has not changed since it was signed; it cannot establish that the artifact was safe at signing time.

“Repeated supply-chain compromises show that a trusted source repository does not guarantee that the package users install was built from that source,” Prabhu said. He recommended signed releases paired with verifiable build provenance and stronger protection for publishing credentials.

Grover’s recommendations extend verification to deployment: inspect packages and images before use, restrict production to approved package and image digests, and require independent approval for release workflow changes. The practical lesson is that trust must cover the build and publication process as well as the artifact’s signature.