LiteLLM release pipeline hacked to distribute credential-stealing malware

Hackers hijacked the software release pipeline of LiteLLM, a popular open-source AI gateway, to distribute credential-stealing malware, marking the project’s second supply chain compromise this year despite security measures introduced after an earlier attack. The compromised version, 1.107.0, was distributed through the Python Package Index (PyPI) and official Docker images on October 21. LiteLLM said the malicious Python packages remained available for approximately two hours before being removed, while the affected Docker images were withdrawn or replaced later that day. The affected Docker images included those distributed under the latest, main-latest, and main-stable tags, extending the risk to deployments that pulled those tags during the exposure window. According to cybersecurity firm Aikido , files bundled with the compromised package executed automatically when Python started, even if an application did not import LiteLLM. The malware was designed to collect sensitive information from infected systems, including cloud credentials and API keys stored in LiteLLM’s database, potentially giving attackers access to services beyond the affected AI gateway. The compromised package also contained a remote access trojan that launched a background process to retrieve and execute code from attacker-controlled infrastructure every hour, according to Aikido. This could allow attackers to continue executing commands on infected systems after the initial credential theft. In its incident report, LiteLLM said attackers used stolen GitHub credentials associated with three developer accounts to manipulate its software release pipeline. The stolen credentials enabled changes to the release workflow, which was redirected to an attacker-controlled lookalike repository. The company said the attackers may have obtained the credentials from logs associated with an internet-facing internal LiteLLM deployment. It also identified circumstances in which Claude Code could expose GitHub authentication tokens in responses subsequently recorded by LiteLLM. However, it has not been established how the attackers initially accessed the deployment. LiteLLM said the incident had been contained and that customers using its private enterprise registry were unaffected. It advised organizations running the compromised open-source software to treat their environments as potentially breached and rotate exposed credentials rather than relying solely on removing the malicious package. Broader enterprise exposure “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. Aikido noted that the malware targeted Kubernetes service account tokens and secrets associated with CI/CD systems , including GitLab and Jenkins. The extent of any subsequent compromise may depend on the privileges assigned to the affected deployment and the credentials available to it. “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.” Beyond credential theft, a compromised gateway could disrupt business applications that depend on it, Grover said. 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. A wider incident response challenge The malware’s remote access component could remain active even after the compromised package is removed, complicating efforts to determine whether an affected system is safe to restore. “CISOs should not treat this just as a package-cleanup exercise,” Prabhu said. He recommended identifying deployments running affected packages or container images, isolating suspected systems, and preserving forensic evidence before rebuilding them using trusted software. Grover warned that security teams should avoid launching Python or pip in suspected compromised environments because the malware’s startup hooks could execute again. She recommended identifying affected packages and container image digests across production environments, developer systems and CI runners. “Missing indicators do not prove an environment is clean,” Grover said. Prabhu recommended examining logs for evidence of persistent access or misuse of stolen credentials. He said organizations should rotate every secret accessible to the compromised deployment, including credentials associated with cloud infrastructure and development pipelines. Grover also recommended linking AI usage telemetry with cloud and identity audit logs to help identify possible credential misuse. Unusual token consumption could provide an indication of unauthorized activity, although attackers may avoid generating noticeable increases in spending, she said. Software supply chain weaknesses In March, malicious versions of LiteLLM’s Python package were distributed following a compromise that the project linked to the Trivy security scanner used in its software release pipeline. After this, LiteLLM strengthened its software release process by moving releases to a private repository and introducing signed Docker images. However, attackers used stolen GitHub credentials to modify the release workflow, which then signed and published the malicious software, the company said. The incident shows how malicious code can pass through an authorized software signing process when attackers compromise the release pipeline. A valid digital signature can verify that an artifact has not been altered since signing, but cannot establish whether the code was safe when it was signed. “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. Prabhu recommended cryptographically signed releases backed by verifiable build provenance, alongside stronger protection of publishing credentials. Grover said enterprises should also inspect distributed software packages and container images before deployment, rather than relying solely on the integrity of the source repository. She recommended restricting production deployments to verified package and image digests and requiring independent approval for changes to release workflows.