LiteLLM Supply Chain Attack Exposes AI Gateway Credentials

LiteLLM’s second supply chain compromise this year shows how an AI gateway can become a route into the wider enterprise. Attackers altered the project’s release pipeline and distributed a credential stealer and remote access trojan in package version 1.107.0, potentially exposing cloud services, developer systems and applications that rely on the gateway.

The package reached PyPI on October 21 and remained available for approximately two hours, LiteLLM said. Malicious Docker images were also distributed under the latest, main-latest and main-stable tags. Those images were withdrawn or replaced later that day, leaving deployments that pulled the affected tags during the exposure window at risk.

According to cybersecurity firm Aikido, files in the package ran when Python started, even if an application didn’t import LiteLLM. The malware sought sensitive data, including cloud credentials and API keys stored in LiteLLM’s database. It also installed a remote access trojan that periodically fetched and ran code from attacker-controlled infrastructure, potentially allowing continued access after the initial theft.

Credentials opened the release pipeline

LiteLLM’s incident report says attackers used stolen GitHub credentials associated with three developer accounts to change the release workflow. The modified process pointed to an attacker-controlled lookalike repository, then produced and published the malicious software.

The company said credentials may have been captured in logs from an internet-facing internal LiteLLM deployment. It also identified cases in which Claude Code could expose GitHub authentication tokens in responses that LiteLLM later recorded. The initial route into the deployment has not been established.

LiteLLM said it contained the incident and that customers using its private enterprise registry weren’t affected. For users of the compromised open-source release, the company advised treating systems as potentially breached and rotating exposed credentials. Removing the package alone may not stop the trojan’s persistent access.

The potential reach extends beyond AI credentials. Aikido said the malware targeted Kubernetes service account tokens and secrets connected to CI/CD systems, including GitLab and Jenkins. How far an attacker could go depends in part on the deployment’s permissions and the secrets 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.

For enterprises, the gateway’s central role makes the incident more consequential than a single package compromise. “An AI gateway is privileged enterprise infrastructure,” said Sakshi Grover, research director for information and data security at IDC. “Centralizing access to multiple models can improve governance, but it also concentrates trust.”

A compromised gateway could also interrupt business applications that depend on it, Grover said. IDC’s Future Enterprise Resiliency and Spending Survey, conducted in July 2026, found that 95% of surveyed enterprises worldwide had at least one company-funded agent-enabled workflow in production.

Response requires more than package removal

The trojan’s remote access feature complicates recovery: deleting the malicious package doesn’t establish that a system is clean. “CISOs should not treat this just as a package-cleanup exercise,” Prabhu said. He recommended finding affected deployments, isolating suspected systems, preserving forensic evidence and rebuilding from trusted software.

Grover cautioned security teams against launching Python or pip in suspected environments, since startup hooks could trigger the malware again. She recommended searching production systems, developer machines and CI runners for the affected packages and container image digests. “Missing indicators do not prove an environment is clean,” she said.

Prabhu advised reviewing logs for signs of persistent access or credential misuse, then rotating every secret available to the compromised deployment, including cloud and development pipeline credentials. Grover also recommended correlating AI usage telemetry with cloud and identity audit logs. Unusual token consumption may reveal misuse, though an attacker could avoid activity that drives a noticeable spending increase.

Signed releases still depend on the pipeline

The October incident follows a March compromise in which malicious LiteLLM packages were distributed after an attack linked by the project to the Trivy security scanner used in its release pipeline.

After that attack, LiteLLM moved releases to a private repository and introduced signed Docker images. But stolen GitHub credentials let attackers change the workflow, which then signed and published the malicious software. The episode underscores a limit of signing: it can show that an artifact hasn’t changed since it was signed, but it can’t certify that the signed code was safe.

“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 called for signed releases with verifiable build provenance and stronger safeguards around publishing credentials.

Grover recommended that enterprises inspect packages and container images before deployment, restrict production to verified package and image digests, and require independent approval for release workflow changes. The practical lesson is that protecting the source repository matters, but so does verifying what the release process actually builds and delivers.