The TeamPCP supply chain attack compromised LiteLLM packages 1.82.7 and 1.82.8, stealing SSH keys, cloud credentials, API tokens, and more from developer machines, where secrets live, breathe, and often remain unmonitored.

"Litellm is downloaded millions of times a day, and it is highly likely that the blast radius is significant, despite PyPI's quick response in removing the malicious package," said Guillaume Valadon, our cybersecurity researcher.

When GitGuardian reported on Tuesday that the TeamPCP threat actor had poisoned LiteLLM packages with infostealer malware, organizations using this popular AI development tool faced an urgent question: what do we do now?

The Blast Radius

The attack targeted litellm packages versions 1.82.7 and 1.82.8 on the PyPI software registry, using the same infostealer malware previously deployed in the Trivy campaign. While PyPI maintainers acted quickly to remove the malicious packages, the damage window was significant.

The infostealer harvested everything an attacker could want:

• SSH keys for accessing production servers
• Cloud credentials for AWS, Azure, and GCP
• Docker configurations
• Information tied to crypto wallets

Given that many organizations use Litellm to build AI-powered applications, the potential reach of this attack extends far beyond a simple package compromise. This is about the keys to your entire infrastructure potentially being in the hands of threat actors.

First Response: Is Your Environment Compromised?

The first step in any incident response is detection. You can't remediate what you don't know is compromised. Here's how to rapidly assess your exposure.

Leverage Your EDR Tools

If your organization has deployed Endpoint Detection and Response (EDR) solutions on developer machines (and you should), now is the time to put them to work. Check for any outbound connections to the malicious domains listed in the indicators of compromise above, particularly scan.aquasecurtiy.org and checkmarx.zone.

An EDR solution can prove invaluable in detecting this type of compromise. The system can flag unusual outbound connections to the exfiltration domain models.litellm.cloud, immediately identifying which developer machine may be compromised. This allows security teams to verify that the malicious package was indeed installed in one of the developer's local Python environments and, crucially, to confirm that only one machine was affected.

Without EDR visibility into developer endpoints, detecting this kind of compromise becomes significantly harder. The malware is designed to operate quietly, exfiltrating data without obvious symptoms that would alert the developer.

Don't Forget Your CI/CD Pipelines

While the immediate concern focuses on developer workstations, supply chain attacks can propagate into your automated build and deployment systems. Your CI/CD pipelines represent a particularly dangerous vector because compromised credentials there can affect production systems at scale.

Organizations need to audit their continuous integration and deployment environments thoroughly. This means checking GitHub Actions workflows, GitLab CI pipelines, CircleCI configurations, Jenkins jobs, and any other automation that might have pulled in the compromised package versions.

Look for LiteLLM versions 1.82.7 or 1.82.8 in:

• Dependency declaration files like requirements.txt, Pipfile, or pyproject.toml
• CI/CD workflow configuration files
• Container image definitions and Dockerfiles
• Build and deployment scripts

First manually review every active branch and CI configuration across their repositories to confirm that no production workloads were running the compromised versions. While time-consuming, this audit provides critical assurance that the blast radius was contained to development environments.

As Dan Lorenc, CEO of Chainguard, noted on LinkedIn, it's concerning that CI/CD systems like GitHub Actions remain vulnerable to these kinds of supply chain attacks. Organizations should treat their automation infrastructure with the same security rigor they apply to production systems.

The Power of Automated Local Scanning

To help organizations respond quickly to this incident, GitGuardian developed a specialized script and packages for local machine scanning. Based on public research about the malware's behavior and target file patterns, this script automates the discovery process by identifying all the file types and locations that the malware targets, collecting those files from compromised machines, and preparing them for systematic analysis.

The script works in conjunction with ggshield (needs to be installed primarily), GitGuardian's command-line tool, to leverage GitGuardian's local scanning capability. Rather than manually reviewing hundreds or thousands of files for potential secrets, the script feeds them directly into GitGuardian's detection engine and remediation platform. 

We're sharing this script on GitHub so any organization affected by the LiteLLM compromise can use it to rapidly assess their exposure.

The result is a complete, automatically generated inventory of every secret that may have been exposed, all centralized in GitGuardian's incident management dashboard. What might have taken days of manual work happens in minutes, and security teams can immediately move to the critical work of remediation rather than still trying to understand the scope of the problem.

Setting Up GitGuardian for Local Scanning

Before you can use our scanning script with ggshield, you need to set up a GitGuardian workspace and authentication. ggshield requires an active workspace and API key to function, even for local scanning.
Here's how to get started:
1. Create a Free GitGuardian Workspace
Visit dashboard.gitguardian.com and sign up for a free account. The freemium tier provides everything you need for incident response scanning.
2. Generate an API Token
Once your workspace is active, you'll need to generate either:

• A Personal Access Token (PAT) for individual use, or
• A Service Account token for team-wide scanning

To generate a token:

1. Log into your GitGuardian dashboard
2. Navigate to API in the settings menu
3. Click Create token and select your token type
4. Copy the token immediately (it won't be shown again)
5. Store it securely

3. Configure ggshield
Set your API key as an environment variable:export GITGUARDIAN_API_KEY=your_token_here
Or configure it permanently:ggshield auth login --method=token --token=your_token_here
4. Verify Your Setup
Test that ggshield can connect to your workspace:ggshield –version
ggshield auth status
You should see confirmation that you're authenticated and connected to your workspace.
Important: Without this setup, the scanning script won't work. The local scanning capability requires an active connection to GitGuardian's detection engine and your workspace to store incident records.

Managing Remediation at Scale

Every potentially compromised secret becomes an incident record with rich, automatically generated metadata. The security team can immediately see criticality scores for each secret, helping them prioritize the most dangerous exposures first. Validity checks confirm which secrets are still active and represent real risk versus ones that have already been rotated or expired. For example, integration with a vault deployment provides additional context about where secrets are actually being used across their infrastructure.

With their complete inventory visible in the dashboard, the security team can effectively coordinate their response. They will start with the highest criticality secrets based on GitGuardian's automatic scoring and can divide the work across available team members. Each person claimes specific incidents, ensuring clear ownership and preventing duplicate effort or missed secrets.

For each secret, the team should follow a consistent evaluation process:

Is this secret actually critical? The criticality score provides a starting point, but context matters. Some high-scoring secrets might have limited scope in practice, while others needed immediate action.

Is it still valid? GitGuardian's validity checks eliminated false alarms from secrets that had already been rotated or revoked, letting the team focus on active threats.

What access does it grant? Understanding the scope of potential damage requires knowing what systems and data each secret can access. GitGuardian's analyzers and integration with secret managers provides much of this context automatically.

Where is it being used? Before revoking or rotating a secret, teams need to know what systems depend on it. Breaking production services during incident response helps no one.

What's the remediation strategy? Different secrets require different approaches, which we'll explore next.

With a complete inventory and clear priorities, the security team can move into active remediation. The variety of secrets exposed requires multiple remediation strategies, each suited to different circumstances.

Immediate Revocation for Isolated Secrets

Some secrets exist solely on developer machines for local testing and development. These represent the easiest remediation cases because revoking them doesn't risk breaking shared systems or production services.

If you find keys that are not referenced in any production code or shared development environments, GitGuardian's direct integration with service providers enables one-click revocation. A single button press in the dashboard immediately invalidates the compromised credentials, eliminating the threat with no downstream impact.

This capability dramatically reduces the time and effort required for a portion of the remediation work. Instead of logging into multiple service provider consoles, navigating to API key management interfaces, and manually revoking credentials, the security team can handle dozens of revocations directly from their central incident management view.

Safe Rotation for Shared Secrets

Many exposed secrets can’t probably  be simply revoked because they are actively used by legitimate systems. These require a more careful rotation process to maintain service continuity while eliminating risk.

The standard rotation procedure follows three steps:

First, create a new secret with appropriate permissions and scope. This new credential should be functionally equivalent to the one being replaced.

Second, update all legitimate uses of the old secret to reference the new one. This might involve updating configuration files, environment variables, CI/CD system secrets, or secret manager entries, depending on how the credential is deployed.

Third, revoke the old secret only after confirming that all legitimate uses have been migrated. This prevents service disruptions while ensuring the compromised credential can no longer be abused.

GitGuardian's integration with secret managers streamlines this process significantly. For secrets stored in vaults, the team can see usage information and coordinate rotation activities directly through the incident management interface rather than context-switching between multiple tools.

Assignment for Specialized Knowledge

Usually, not every secret can be immediately remediated by the security team. Some credentials may require specialized knowledge about internal systems, application architecture, or business processes that the incident responders may not possess.

For these cases, the team can leverage GitGuardian's assignment capabilities. Rather than trying to handle every incident themselves or losing track of secrets that need follow-up, they can assign those incidents to the appropriate subject matter experts with full context about the exposure.

This ensures nothing falls through the cracks even when the security team lacks the specific knowledge needed for remediation. Each assigned individual receives clear information about what was compromised, why it mattered, and what actions they need to take.

"Attackers are after your secrets. When it comes to incident response, the key now is to have a real-time inventory of compromised secrets so you can revoke them in an instant, thereby neutralizing the threat posed by these supply chain attacks using infostealers." – Guillaume Valadon.

The LiteLLM compromise is part of a clear pattern where threat actors target developer environments specifically because that's where secrets live in abundance and often with less monitoring than production systems.

What to Do Right Now

If you're reading this article, here are your immediate action items:

Check your EDR logs for any connections to the malicious domains and IP addresses listed in the indicators of compromise section. Focus particularly on developer machines.

Audit your CI/CD systems comprehensively. Search for LiteLLM versions 1.82.7 and 1.82.8 across all your GitHub Actions workflows, GitLab CI pipelines, and other automation infrastructure.

If you identify compromised systems, use our GitHub script with ggshield to systematically scan and inventory all potentially exposed secrets. Don't rely on manual review or guesswork about what might have been compromised.

Use GitGuardian to centralize, prioritize, and coordinate your remediation efforts. Take advantage of automated criticality scoring, validity checks, and integration with your existing secret management infrastructure.

Implement continuous secret scanning across your development environments and repositories to detect future exposures before they can be exploited. The goal is to make secret exposure events into minor incidents rather than major breaches.

The window for attackers to abuse stolen credentials is narrow, but only if you can identify and revoke them quickly.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Take Control of Your Secrets Security authored by Guillaume Valadon. Read the original post at: https://blog.gitguardian.com/litellm-supply-chain-attack/