TeamPCP Compromised LiteLLM: A Supply Chain Attack Breakdown

On March 24, the cybercriminal group TeamPCP uploaded malicious versions 1.82.7 and 1.82.8 of LiteLLM—a popular Python library for AI application development—to the Python Package Index (PyPI). These compromised packages contained malware designed to exfiltrate sensitive data from developers and enterprises using the library. The attack was tied to a compromised maintainer account and malicious GitHub Actions workflows, allowing the attackers to distribute their payload through legitimate release channels.

Timeline

March 24: TeamPCP gains access to a LiteLLM maintainer account and uploads compromised versions 1.82.7 and 1.82.8 to PyPI with malicious code.

March 24 (hours later): Malicious workflows execute during the package build process, injecting additional payloads into the distribution.

Subsequent days: Developers and organizations unknowingly download and integrate the compromised versions into their AI application stacks.

Detection timeframe not specified: Security researchers identify the malicious packages and alert the maintainers.

Post-detection: The LiteLLM team removes the malicious versions, but organizations that downloaded them remain at risk until they upgrade and rotate credentials.

Which Controls Failed or Were Missing

Maintainer Account Access Control

The attack succeeded because TeamPCP compromised a maintainer account with publish rights to PyPI. This represents a failure in several control layers:

• No multi-factor authentication on the compromised account
• Insufficient monitoring of maintainer account activity for unusual behavior
• No approval workflow requiring multiple maintainers to sign off on releases
• Missing just-in-time access controls that would limit publish rights to specific time windows

Build Pipeline Integrity

The malicious workflows during the package build process indicate:

• No code review requirement for workflow changes before execution
• Insufficient isolation between build environments and production release processes
• No integrity verification of the build artifacts against expected checksums or signatures
• Missing runtime monitoring of build processes for unexpected network connections or file modifications

Downstream Detection Failures

Organizations consuming LiteLLM failed to detect the compromise because:

• No package verification against known-good signatures or checksums
• Missing dependency scanning that would flag newly published versions for review
• No behavioral monitoring of packages post-installation to detect malicious activity
• Inadequate software bill of materials (SBOM) tracking to identify affected systems

What the Relevant Standards Require

NIST 800-53 Rev 5

SR-3 (Supply Chain Controls): Organizations must employ supply chain controls to protect against supply chain risks, including verifying the integrity of software components and monitoring for malicious code insertion.

SR-4 (Provenance): Requires documenting and tracking the provenance of system components, including open source packages. You need to know exactly which version of LiteLLM you're running and when you installed it.

SR-11 (Component Authenticity): Mandates anti-counterfeit measures, including verifying the authenticity of software components through cryptographic signatures or checksums.

ISO/IEC 27001:2022

Annex A 8.30 (Outsourced Development): Even though open source isn't traditional outsourcing, the control applies—you must verify the security of external code before integrating it into your systems.

Annex A 8.19 (Installation of Software): Requires procedures to control software installation, including verification of software integrity before deployment.

PCI DSS v4.0.1

Requirement 6.3.2: Custom and bespoke software must be reviewed prior to release. While this targets custom code, the principle applies to your supply chain—you're responsible for verifying third-party components before they process cardholder data.

Requirement 11.6.1: Requires detection and alerting of unauthorized modifications to critical files. If LiteLLM processes payment data, modifications to its code should trigger alerts.

Lessons and Action Items for Your Team

Implement Package Verification Now

Stop auto-accepting PyPI packages. Your dependency management process needs:

1. Pin exact versions in your requirements.txt or pyproject.toml—never use version ranges for production dependencies
2. Generate and verify checksums for every package using pip hash or tools like pip-audit
3. Enable package signature verification where available
4. Set up a private package mirror that you control, allowing you to vet packages before they reach your developers

Monitor Your Dependency Chain

You need visibility into what you're actually running:

1. Generate SBOMs for every application using tools like Syft or CycloneDX
2. Subscribe to security advisories for your critical dependencies
3. Implement automated scanning with tools like Trivy, Grype, or Snyk that check for known malicious packages
4. Set up alerts for new versions of critical dependencies so you can review them before upgrading

Harden Your Own Build Pipelines

The LiteLLM attack exploited malicious workflows. Audit your GitHub Actions, GitLab CI, or Jenkins configurations:

1. Require code review for all workflow file changes, not just application code
2. Restrict workflow permissions using the principle of least privilege
3. Pin action versions to specific commit SHAs, not tags that can be moved
4. Isolate build environments from production credentials and secrets

Learn from the Trivy Credential Rotation Failure

The source notes that Aqua's Trivy scanner was compromised due to non-atomic credential rotation. When you discover a compromise:

1. Rotate all credentials simultaneously, not in sequence
2. Revoke before you create new credentials, not after
3. Audit all systems that used the compromised credentials, not just the obvious ones
4. Assume persistence—attackers often leave backdoors when they compromise build systems

Establish a Response Protocol

Document your response plan before the next supply chain incident:

1. Identify your critical dependencies—know which packages would cause immediate production impact if compromised
2. Map your exposure—determine which systems use each critical dependency
3. Define your rollback process—ensure you can revert to a known-good version quickly
4. Test your SBOM accuracy—verify you can identify all systems running a specific package version

The TeamPCP campaign demonstrates that open source supply chain attacks are active threats targeting the tools your team uses daily. Your controls need to match that reality.