On March 24, 2026, the cybercriminal group TeamPCP published two malicious versions of LiteLLM to PyPI. Within hours, organizations using these compromised packages began leaking credentials to attacker-controlled infrastructure. The result: a 153GB archive containing 433,909 files linked to 2,488 corporate domains, including credentials from AWS, Cisco, and Salesforce environments.
This wasn't a zero-day exploit or a sophisticated social engineering campaign. It was a supply chain compromise of an open-source tool that many teams had already integrated into their AI workflows.
Timeline
March 24, 2026: TeamPCP publishes malicious LiteLLM versions 1.82.7 and 1.82.8 to PyPI. The compromise originated from a backdoored version of Trivy, an open-source vulnerability scanner that LiteLLM's build process depended on.
March 24-25, 2026: Organizations running automated dependency updates pull the malicious versions. Credentials begin exfiltrating to attacker infrastructure.
Post-breach: Hudson Rock discovers the 153GB archive and begins coordinating disclosure with affected organizations. The firm urges immediate audits for the two malicious versions.
Which Controls Failed
The breach exposed gaps across three control areas:
Software supply chain verification: Teams installed packages from PyPI without verifying signatures or checksums. LiteLLM's dependency on Trivy created a transitive trust relationship that wasn't monitored. When Trivy was compromised, that compromise spread downstream.
Secrets management: The exfiltrated credentials were accessible to the LiteLLM process at runtime. This suggests they were stored as environment variables, configuration files, or hardcoded in application code rather than retrieved from a secrets manager with short-lived tokens.
Runtime monitoring: The malicious versions were making outbound connections to exfiltrate data, but no network egress monitoring or anomaly detection flagged the behavior. Organizations didn't know they'd been compromised until the archive surfaced publicly.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed based on industry standards and incorporate information security throughout the software development lifecycle. This includes securing the build pipeline itself. If your payment processing touches any code built with compromised dependencies, you've violated this requirement at the source.
NIST 800-53 Rev 5 control SA-12 (Supply Chain Protection) requires organizations to employ anti-counterfeit measures and validate that software hasn't been tampered with. This means verifying package signatures, maintaining an SBOM (Software Bill of Materials), and monitoring for unexpected changes in your dependency tree.
ISO/IEC 27001:2022 Annex A.8.30 addresses secure coding practices, but the broader requirement is A.5.19 (Information Security in Supplier Relationships). You're required to identify and document information security risks in your supply chain and implement controls to address them. Installing unverified packages from public repositories without a validation process fails this requirement.
SOC 2 Type II CC6.1 (Logical and Physical Access Controls) requires that credentials be protected through encryption and access restrictions. If your secrets were sitting in environment variables that any compromised process could read, you don't meet the control objective.
Lessons and Action Items
Audit your environment immediately: Search your container registries, CI/CD logs, and dependency manifests for LiteLLM versions 1.82.7 and 1.82.8. If you find them, assume compromise. Rotate every credential that was accessible to systems running those versions.
Implement package verification: Configure your package managers to verify signatures before installation. For PyPI, use pip install --require-hashes and maintain a requirements file with pinned hashes. For containerized builds, verify image signatures with tools like cosign.
Generate and monitor your SBOM: Use tools like Syft or OWASP Dependency-Track to create a software bill of materials for every application. Set up automated alerts when a component in your SBOM is flagged for compromise or vulnerability. You can't respond to supply chain incidents if you don't know what you're running.
Move secrets to a proper manager: Migrate credentials from environment variables and config files to HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Configure your applications to retrieve short-lived tokens at runtime rather than storing long-lived credentials. This limits the blast radius when a process is compromised.
Monitor egress traffic: Deploy network monitoring that baselines normal outbound connections and alerts on anomalies. The malicious LiteLLM versions were exfiltrating to attacker infrastructure, which should have triggered alerts if you were monitoring for unexpected destinations or unusual data volumes.
Require MFA and JIT access for production secrets: Even if credentials leak, they're less useful to attackers if they require multi-factor authentication or just-in-time access approval. This won't stop the initial exfiltration, but it limits what attackers can do with stolen credentials.
Review your CI/CD security: The compromise originated in the build process. Isolate your build environments, restrict network access, and verify the integrity of build tools before they run. If your CI/CD pipeline has broad access to production secrets, you've created a high-value target.
The LiteLLM breach wasn't inevitable. The controls exist in every major framework. What failed was implementation: teams integrated open-source tools without verification, stored secrets in easily accessible locations, and didn't monitor for the telltale signs of exfiltration. Start with the audit, then fix the gaps that made this breach possible in your environment.
