LiteLLM Supply-Chain Attack Leaked Credentials from 2,500+ Organizations in 40-Minute Window

Terabytes of credentials leaked in massive supply-chain attack

Terabytes worth of credentials, many belonging to the world's biggest and most sensitive organizations, have been exposed in a supply-chain attack on LiteLLM, an open source tool that streamlines AI-driven software development. Microsoft, Amazon, Cisco, Samsung, and Salesforce are only a handful of the entities whose access secrets were exposed. The revelation was posted on Tuesday and Wednesday by security firms CloudSEK and Hudson Rock. CloudSEK said it found cloud keys, repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables, and AI provider keys that could allow attackers to gain access to more than 2,500 organizations. 40 minutes is all it takes The credentials were extracted during a 40-minute window in March while the victims used compromised versions of LiteLLM downloaded from the package's official location in the Python Package Index repository. Hudson Rock said it made the discovery after analyzing a 195TB file that it obtained. Neither firm identified the source of the information. The LiteLLM compromise was the result of a previous supply-chain attack that infected the widely used vulnerability scanner Trivy. Other software infected in the campaign includes KICS and the Telnyx Python SDK. TeamPCP, a ramshackle but extremely capable gang largely made up of teenagers, took credit for the attack, and researchers have largely corroborated the claim. "I've confirmed the data is legit by the way, multiple victim orgs," independent security researcher Kevin Beaumont said. "It contains a significant volume of sensitive content at orgs. It's a massive supply chain breach due to poor AI security -- not because AI is the threat, but teens can run circles around orgs obsessed with rushing out AI and poor DevOps security." The compromised versions of all four software packages contained code that accessed the memory of infected machines, scraped its contents, and exfiltrated it through an attacker-controlled channel. The data is filled with an assortment of information. Interspersed in the wall of data are credentials to software pipelines maintained by the tens of thousands of organizations that ran LiteLLM during the 40-minute span that the supply-chain attack remained active. In all, both security firms said some 434,000 CI/CD (continuous integration/continuous delivery) software pipelines had credentials exposed after running the compromised LiteLLM versions. In many cases, researchers at CloudSEK and Hudson Rock had trouble identifying the organizations the credentials belonged to. For instance, an email address in the dump from the domain @siriusxm.com ultimately didn't indicate a breach at the satellite broadcaster, but rather one within the infrastructure of SiriusXM subsidiary AdsWizz. A full list of organizations is here. The researchers had high confidence that these organizations had their credentials exposed: * Nvidia Corporation * Amazon Web Services (AWS) * Samsung Electronics * samsung.com * Salesforce, Inc. * Cisco Systems, Inc. * F. Hoffmann-La Roche AG * ServiceNow * Siemens AG * S&P Global * Airbus US Space & Defense * John Deere * Regeneron Pharmaceuticals, Inc. * London Stock Exchange Group (LSEG) * Thomson Reuters * FedEx * Munich Remunichre.com * MediaTek Inc. * Volkswagen AG * Deloitte * The Kroger Co. * Siemens Energy * Thales Group * X Corp (Twitter) * Zscaler, Inc. * Epic Games * Orange S.A. * HP Inc. * Philips * Fortum Oyj * Vodafone Group Plc * Carl Zeiss AG * Deutsche Bahn AG * NGINX, Inc. * BT Group * Liebherr * Krungthai Bank Public Company Limited * Roku, Inc. "Many CI/CD pipelines are configured generically," Hudson Rock said. "The dumped variables contain active database passwords, third-party API keys, and cloud credentials without any identifiable company email, custom domain string, or internal server name. This means countless organizations currently have active secrets sitting in this database, completely unaware of their exposure." Welcome to the new world of supply-chain attacks Both firms are urging all organizations that used the compromised versions of LiteLLM -- particularly those listed in the high-confidence section of the list -- to thoroughly rotate all credentials in their pipelines. Hudson Rock instructed any organization that uses any AI proxy infrastructure, third-party CI/CD vulnerability scanners, or downstream AI packages to immediately audit their environment for versions 1.82.7 and 1.82.8 of LiteLLM, the two compromised versions of the software. The firm advised all those affected to perform "aggressive credential revocation," assume any secret accessible to the LiteLLM environment is compromised, invalidate and rotate all cloud keys, Kubernetes service account tokens, and GitLab/GitHub PATs, and audit logging and egress filtering. As a cautionary tale, CloudSEK said that Trivy developers rotated, but failed to fully revoke an automation token over a 20-day window. The lapse gave the attackers a nearly three-week period to force-push malicious code to third-party builds that used the vulnerability scanner. As Beaumont observed, organizations' rush to integrate AI into their software delivery systems has also greatly contributed to the scale of the damage. Ultimately, the new revelations concerning the LiteLLM supply-chain attack underscore the growing threat of such campaigns and hence the importance of maintaining vigilance around the use of open source software that, when infected, can spread rapidly across the Internet. "The key takeaway is how supply chains have evolved to make a single upstream breach affect thousands of companies simultaneously," Alon Gal, co-founder and chief technology officer of Hudson Rock, wrote in an email. "A window of roughly 40 minutes in which the LiteLLM dependency was hacked led to over 430,000 instances in which millions of secrets were harvested. This magnitude pushes us into a completely new world regarding the type of response required from the cybersecurity industry."

Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations

Two malicious LiteLLM releases sat on PyPI for about 40 minutes in March carrying credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from systems that installed them. Threat intelligence firm CloudSEK now says a dataset it obtained, built from roughly 434,000 files the attackers captured, maps potential exposure to more than 2,500 organizations. Those totals are not a victim count. CloudSEK told The Hacker News the material came from confidential intelligence sources and consists of captured loot and log files it assessed as belonging to the campaign, not data gathered from the organizations it names. The files were taken, in other words. CloudSEK has published the dataset as What a high-confidence match asserts is whose systems each file came from. That verdict keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and the organization's own domain has to appear before a match earns the top rating. Repository namespaces support only a medium-confidence call. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp are among the entries, and none of that establishes that stolen credentials were used, which is why both CloudSEK and LiteLLM tell affected parties to rotate rather than wait for proof. LiteLLM is an open-source AI gateway used to connect applications with multiple model providers. The project identified versions 1.82.7 and 1.82.8 as compromised and said they were live on March 24 from 10:39 UTC for about 40 minutes before PyPI quarantined them, though it tells users to treat any install that day up to 16:00 UTC as suspect. The Hacker News confirmed via PyPI on August 12 that neither version appears in the package's release history, while 1.82.6 and 1.83.0 remain available. The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows. A long-lived secret copied during that window, a static cloud key, an SSH key, or a publishing token, remains usable unless it has since been rotated or revoked. That is why the bureau's guidance is scoped to credentials rather than to the package, and why both it and Aqua tell teams to move away from long-lived tokens toward temporary ones. Version 1.82.8 included a file named litellm_init.pth that Python processes at interpreter startup, so it ran whenever a Python process started in that environment, whether or not anything imported LiteLLM. The compromised packages were designed to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords before encrypting and sending stolen data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project. Unit 42's campaign analysis records the payload reading environment variables that hold model API keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY. That behavior inverts the usual triage question. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it, and the project's advisory notes that an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could deliver it without anyone choosing it. The LiteLLM incident sits inside a wider TeamPCP supply-chain campaign linked to Aqua Security's Trivy scanner. Google tracks TeamPCP as UNC6780. Aqua said attackers retained access after an incomplete credential rotation and, on March 19, force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 release. The ecosystem compromise is tracked as CVE-2026-33634, added to CISA's Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components. Exactly how the malicious LiteLLM releases reached PyPI was disputed across the published accounts. CloudSEK's report said the poisoned build produced and published the releases, LiteLLM's own incident report pointed to a direct PyPI upload that bypassed its official CI/CD workflow, and Unit 42 described attackers targeting PyPI publishing tokens after the Trivy breach. Asked about the discrepancy, CloudSEK pushed back. "These are different stages of the same attack chain, not competing explanations," the company told The Hacker News. Its evidence covers how the credential was obtained, while the LiteLLM and Unit 42 findings cover how it was then used. PyPA's advisory for the malicious releases describes the same sequence: an API token exposed through the compromised Trivy dependency and then used to upload the two versions. BerriAI had not responded to questions about which account its own forensics support at the time of writing. Attribution inside the dataset runs through two independent checks, CloudSEK said. An index assigns each file using CI identity variables, and a separate ownership gate re-derives ownership from the fetched logs and can override that assignment. "If they disagree, the report is withheld," the company said, and the final verdict takes the lower of the two confidence levels. The 434,000 figure counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs. CloudSEK said one captured file is roughly one job execution, but it does not present the total as unique jobs without independent deduplication and verification. The company declined to discuss pre-publication notifications to the named organizations, and would not say whether any disputed its inclusion. The campaign's downstream impact is confirmed even if CloudSEK's scale figures are not. Checkmarx said credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories and the publication of malicious artifacts. Mercor said it was affected by malicious LiteLLM versions and contained unauthorized activity. CERT-EU separately assessed with high confidence that a European Commission AWS account was compromised through the Trivy supply-chain attack, with about 91.7 GB of compressed data exfiltrated. Organizations assessing exposure should take three steps: