Litellm and the human cost of a supply-chain breach: when one tag changes a workday

At 7: 40 a. m. ET, a security engineer in a small DevOps team stared at a CI run that had never failed before. The log didn’t show a dramatic crash—just subtle behavior that felt “off, ” the kind that makes you stop sipping coffee and start taking screenshots. The keyword that would dominate the day, in Slack threads and incident notes, was litellm.

What happened in the TeamPCP campaign—and where does Litellm fit?

A credential-stealing supply-chain operation tracked as TeamPCP widened its reach across developer environments, touching multiple distribution points and automation paths. In one thread of the campaign, the KICS GitHub Action was compromised with credential-stealing malware. KICS is an open-source infrastructure-as-code security scanner by Checkmarx.

The compromise window for the KICS GitHub Action ran from 12: 58 to 16: 50 UTC on March 23, meaning that users pinning to one of 35 hijacked tags during that period would have been served malware. The repository was taken down at 16: 50 UTC, shortly after a GitHub issue was filed by a user notifying maintainers. Later, at 19: 24 UTC on March 23, the repository was reinstated and maintainers stated, “The issue is resolved now. ”

In another thread, packages on PyPI were trojanized: the “litellm” packages (versions 1. 82. 7 and 1. 82. 8) were described as containing the same functionality as a previous operation, but using a new exfiltration domain: models. litellm[. ]cloud. The malicious update was published at approximately 8: 30 UTC and quarantined by PyPI at 11: 25 UTC.

Translated into Eastern Time (ET), 12: 58–16: 50 UTC is 8: 58 a. m. –12: 50 p. m. ET on March 23. The PyPI quarantine at 11: 25 UTC lands at 7: 25 a. m. ET—an early-morning containment, but still late enough to worry anyone whose systems automatically pull dependencies at the start of a workday.

Why compromised GitHub Actions and packages can break more than code

Supply-chain attacks are often explained as a technical chain reaction—one artifact, one token, one unauthorized push. In practice, they also create a human chain reaction: sudden freezes on deployments, a rush to audit logs, the uncomfortable task of telling leadership that a “security tool” may have delivered malware, and the quiet fear that an automation token could have been used elsewhere.

In the KICS incident, the attacker’s method was described in concrete steps: imposter commits were staged on a fork containing a payload file named setup. sh, and then an identity that appeared to be compromised was used to directly update 35 tags to point to those staged commits. The malware used a new command-and-control domain, checkmarx. zone, and added Kubernetes-focused persistence code in addition to credential stealing and exfiltration. It also created a docs-tpcp repository victims’ GITHUB_TOKENs as a fallback mechanism if command-and-control was disrupted, echoing a naming pattern seen earlier in the Trivy incident.

That detail—creating a repository using someone else’s token—lands differently when you picture the person behind the token. It’s not just an abstract credential; it’s a bridge into a team’s work habits and trust model. For many developers, GitHub Actions are the quiet machinery that turns small commits into shipping software. When that machinery becomes the delivery path for credential theft, the day becomes about containment, not building.

What are researchers and maintainers saying—and what responses are underway?

The campaign has been connected across multiple incidents. Wiz assessed with high confidence that the KICS compromise involved the same actor as the Trivy incident, citing familiar naming conventions and the same RSA public key. Wiz also stated that this was the second popular open-source security scanner the group compromised in the last five days.

Additional spillover was noted. At 22: 25 UTC on March 23, Sysdig stated that ast-github-action was also impacted, observing a single malicious tag 2. 3. 28, while noting that TeamPCP tactics suggested it was likely all tags were impacted. At 22: 35 UTC on March 23, Wiz confirmed—based on a tip from independent researcher Adnan Khan—that Checkmarx OpenVSX extensions cx-dev-assist 1. 7. 0 and ast-results 2. 53. 0 had been compromised, and said it reported them to OpenVSX for removal.

Checkmarx later published a Security Update addressing the KICS GitHub Action and OpenVSX plugins. An observation in the same thread noted that while new versions had been pushed, the malicious versions had not yet been removed at the time of that report.

Separate analysis described an expanding blast radius from the Trivy compromise into Docker Hub artifacts. Socket security researcher Philipp Burckhardt said that new image tags 0. 69. 5 and 0. 69. 6 were pushed on March 22 without corresponding GitHub releases or tags, and that both contained indicators of compromise associated with the same TeamPCP infostealer observed earlier. Security researcher Paul McCarty said forensic analysis of GitHub Events API activity pointed to a compromised service account token—likely stolen during a prior GitHub Actions compromise—as the attack vector, and said one compromised token for that service account could bridge write/admin access across organizations.

For teams looking for immediate steps, the KICS incident write-up emphasized auditing workflows, identifying malicious activity, and securing GitHub Actions. Those phrases sound procedural, but in the real world they mean pulling engineers off sprint work, scanning build histories for when tags were updated, and rethinking whether “pinning to tags” is safe enough when tags themselves can be rewritten.

Back at the desk, the engineer returned to the same CI run—now less as a failure to fix, and more as a timeline to understand. The morning’s anxiety wasn’t only about one tool or one repository; it was about trust in the invisible plumbing that connects modern software. In the hours when defenders were racing to quarantine packages and pull down repositories, the name that kept surfacing in incident notes was litellm—not as a headline, but as a reminder that supply-chain security is lived one build, one token, and one interrupted workday at a time.