The tool that checked for supply-chain risk was the supply-chain risk

The week

In the second half of March 2026, a group tracked as TeamPCP ran a cascading software supply-chain campaign. On March 19, attackers published a malicious release of Trivy, a widely used open-source vulnerability scanner, and repointed nearly all version tags of its official GitHub Action to credential-stealing code. Aqua Security disclosed the compromise on March 20, tracked as CVE-2026-33634. Researchers later traced it to credentials stolen in late February and only partly rotated. On March 23, tokens taken from compromised pipelines were used to poison Checkmarx’s KICS GitHub Action. On March 24, malicious versions 1.82.7 and 1.82.8 of LiteLLM, a popular library that routes requests to many AI model providers, appeared on PyPI. They were published with credentials stolen from a pipeline that had run the poisoned scanner. PyPI quarantined them within about an hour.

The irony is easy to state. Teams add scanners to their build pipelines to catch dangerous dependencies, and here the scanner was the dangerous dependency. The more useful observation is about credentials. Every hop in the campaign used a secret stolen at the previous hop. The campaign also began with a secret that should already have been dead.

So we look at exposure in three parts, following the life of a stolen credential. First, the tools that could read it. Second, the systems that pooled many credentials in one place. Third, the time each one stayed valid after theft. An organization’s risk in March was the product of all three.

Tools that could read the keys

Vulnerability scanners run in the most sensitive part of the software process. To scan a repository or container image, they run inside build jobs that often hold cloud credentials, signing keys, registry passwords and package-publishing tokens. Most teams add a scanner by referencing a public action by name and version tag, then never revisit the decision.

A version tag is a pointer the publisher can move. When the attackers force-pushed the Trivy action’s tags, every pipeline that referenced a tag pulled the new code on its next run, with all the access that job had been granted. Pipelines that referenced the action by full commit hash kept running the old, clean code.

Three controls follow, and none is exotic. Reference third-party actions and images by immutable hash, and update them deliberately. Give each pipeline step only the secrets it needs, so a scanning step never sees a publishing token. And restrict outbound network access from build runners to known registries and code hosts. The reported payloads sent stolen data to look-alike domains. Egress rules would have blocked that, and alerting on denied connections would have turned a silent theft into a visible event.

Security tools deserve particular scrutiny because organizations grant them broad read access by design and exempt them from the suspicion applied to other code. A security tool in a pipeline should be inventoried, owned and reviewed like any privileged service account.

Systems that pooled the keys

LiteLLM is popular because it solves a real problem. It gives applications one interface to many model providers and manages the keys for each. That convenience makes a gateway host unusually rich. It may hold API keys for several AI providers, cloud credentials, database connection strings and the prompts and responses that pass through it. Researchers reported that the malicious versions targeted exactly that: provider keys, cloud and Kubernetes credentials, SSH keys and environment files.

For a bank, health system or agency, the data side matters as much as the keys. Prompts can contain customer records, clinical notes or case files. Yet AI gateways were often installed by a development team as a library, outside the controls applied to an identity provider or payment switch. It had turned into tier-one infrastructure without anyone deciding it should.

Governing it as tier-one infrastructure starts with a named owner and a hardened, pinned build. Secrets should be fetched from a vault at runtime rather than read from environment files. Egress should be limited to approved model endpoints, and a security team should review the logs. LiteLLM said users of its official proxy container, which pinned its dependencies, were not affected. That is a direct argument for consuming such components as pinned, maintained builds rather than installing the latest version on demand.

How long stolen keys stayed valid

The campaign was possible because a credential stolen in late February still worked in March. Researchers reported that the maintainers detected the earlier intrusion but rotated secrets only partly. The same pattern repeated downstream. A long-lived PyPI token sat where a scanning step could read it, and it stayed valid long enough to publish two malicious releases.

Two practices shorten that window. On the publisher side, package registries now support short-lived, workflow-bound publishing credentials, often called trusted publishing, which removes standing tokens from build environments. On the consumer side, a secrets inventory that records which pipelines can reach which credentials makes rotation targeted and complete. Organizations that had one could rotate the right keys within hours. Those without one faced a choice between rotating everything, which is slow and disruptive, and guessing, which is how the original incomplete rotation happened.

Rotation also needs verification. After an incident, someone should confirm that old credentials are actually rejected, not merely that new ones were issued. Lock files, hash checking and an internal package mirror that delays brand-new releases by a short period add a further buffer. Many organizations would never have installed a version that was public for less than an hour.

The response week also tested a quieter capability: build records. To know whether it was exposed, an organization had to show which pipelines ran an affected action or installed an affected version between March 19 and the cleanup. That requires build logs and dependency resolution records kept long enough to search. Teams that retained them answered in an afternoon. Teams that kept a few days of logs had to assume exposure and rotate on that basis.

With hindsight

The main packages were cleaned up within days, but the campaign did not stop with them. Researchers documented further waves, including malicious releases of a communications provider’s Python SDK on March 27, and CISA added the Trivy vulnerability to its Known Exploited Vulnerabilities catalog on March 26. Later research notes reported that credentials harvested in the campaign were being used by a ransomware operation, a reminder that stolen secrets have a long shelf life. Published accounts differed on exact times and on the number of organizations exposed, which is typical of fast-moving incidents, and we would not rely on any single estimate.

What held up is the credential-centered view. Organizations that pinned actions by hash, used short-lived publishing credentials and knew which secrets each pipeline could reach read about the campaign. Others spent weeks rotating keys they could not fully enumerate.