LiteLLM Supply Chain Poisoning Exposes 195TB of Credentials Across 2500 Organizations
Security researchers have disclosed the full scope of the LiteLLM supply-chain poisoning incident that occurred in March, describing it as one of the largest AI-related credential leaks to date. Within roughly 40 minutes, attackers exfiltrated approximately 195TB of credentials belonging to around 2500 organizations, including major technology companies such as Nvidia.
LiteLLM serves as a widely used open-source API gateway for connecting Python applications to services from OpenAI, Anthropic, and Azure. The project records nearly 100 million monthly downloads and is installed approximately 3.4 million times per day, making it a critical piece of AI infrastructure.
Attackers from the group TeamPCP did not target the LiteLLM repository directly. Instead, they compromised a dependency used inside LiteLLM’s CI/CD pipeline: the open-source vulnerability scanner Trivy. By rewriting a Git tag, they injected malicious code into Trivy version v0.69.4. Because LiteLLM’s pipeline pulled the latest Trivy tag without version pinning, the poisoned scanner executed during the build process and stole PyPI publishing tokens.
Using the stolen tokens, the attackers published two malicious LiteLLM releases—1.82.7 and 1.82.8—on PyPI. These packages were downloaded more than 119,000 times before PyPI isolated them. The malware collected and transmitted cloud provider keys, Git tokens, SSH private keys, Kubernetes configurations, environment variables, and API keys for AI services.
Analysis by CloudSEK and Hudson Rock identified roughly 434,000 CI/CD-related credentials within the 195TB dataset. The first user report to PyPI arrived only after one hour and nineteen minutes, underscoring the lack of automated detection for malicious package behavior. A coding flaw in the malware’s .pth launcher triggered recursive fork bombs that crashed victim machines, inadvertently limiting the duration of silent operation.
Security analysts emphasize that modern software supply chains rely on transitive trust across hundreds or thousands of dependencies. In this case, the attack surface extended beyond LiteLLM’s own code to every third-party tool referenced in its build pipeline.
Recommended mitigations include strict version pinning with exact hashes in requirements files, locking GitHub Actions to specific commit hashes rather than moving tags, immediate rotation of any credentials used between March 24 and the discovery date, and deployment of environment-variable exfiltration monitoring inside CI/CD workflows.
The incident demonstrates that AI tooling and infrastructure components are now attractive targets for supply-chain adversaries. Organizations are advised to treat AI dependencies with the same rigor applied to production code and to prepare for an increase in similar attacks against model-serving frameworks, vector databases, and training pipelines.
Related articles
PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting
PEP 752 proposes reserving package name prefixes for organizations on PyPI, allowing control over entire families of related package names rather than individual entries. The change addresses dependency confusion and name squatting risks where attackers register packages with familiar prefixes like google-cloud- or opentelemetry- to exploit user trust. Analysis of over 800,000 PyPI projects by CodeScoring shows that prefixes are rarely controlled by a single owner, with ecosystems like aws- managed by hundreds of accounts. The proposal introduces implicit namespaces and new metadata for clients and proxies while preserving the flat namespace model familiar to Python developers. PEP 755 will define the governance process for granting prefix rights, limiting applications to organizations and requiring clear justification. Existing packages receive backward compatibility exceptions, and the mechanism does not transfer across repositories.
Suspicious Certificate Issuer Detected in MAX Messenger Windows Update Package
A detailed observation from a security researcher highlights an unexpected change in the code signing certificate for the MAX messenger desktop client on Windows. The August update package was signed by an individual named Konstantin Syomochkin instead of the usual Communication Platform LLC. This discrepancy raised concerns about potential supply chain interference linked to recent EU sanctions against the developer. The certificate was issued shortly after sanctions and belongs to a person based in Astana, Kazakhstan, with limited public ties to the VK team. Official MSI installers downloaded directly from the MAX website remain signed by the company, while the client-triggered update differs in both version and signer. The researcher recommends that VK verify the download chain through Mail.ru trackers to rule out tampering. Installation of the update was declined pending further clarification.
Linux Foundation Report Reveals Why Companies Fork Open Source Projects and Maintain Internal Patches
A new Linux Foundation Research study of 567 IT professionals shows that organizations actively modify open source components rather than using them unchanged. While 72% contribute back to projects in some form, many maintain internal forks due to missing features, integration needs, security timelines, and regulatory requirements. The average organization supports 86 internal forks, consuming over 5,000 hours per release cycle. The largest gaps between business-critical technologies and actual contributions appear in programming languages and databases. The findings highlight growing supply-chain risks when internal branches diverge from upstream projects without proper tracking of patches and commits.
Where Secrets Really End Up in Docker Images: Testing 8 Common Methods
A detailed analysis of eight different approaches for handling secrets during Docker image builds reveals that most methods leave sensitive data exposed in layers, configuration files, or build history. Experiments conducted on Ubuntu 24.04.1 LTS with Docker Engine 29.1.3 and BuildKit v0.26.2 showed that simply using RUN rm after COPY or overwriting files fails to remove secrets from immutable layers. Environment variables via ENV and build arguments via ARG both persist in image metadata and history. Only BuildKit Secrets with --mount=type=secret and multi-stage builds that avoid copying secrets into the final stage successfully prevent leakage. The study demonstrates that secrets can be extracted from saved images without running any containers. Developers are advised to adopt these two secure patterns to protect credentials in container supply chains.