A Supply-Chain Attack Hit Three Developer Tools at Once — Here's How It Actually Worked, Step by Step
Table of Contents
- Who's behind this, and what's actually confirmed about them
- Terms worth getting straight before the timeline
- How the Trivy compromise actually happened
- Then LiteLLM, then a VS Code extension
- What the payload did once it was running
- The 3,800-repository number — whose claim is it, really
- Why this is a pipeline story, not a malware story
- What we're not claiming
Most supply-chain attack writeups describe a single poisoned package. This one is different because it's a chain, not an incident: a group tracked as TeamPCP worked its way through three separate pieces of developer tooling over several months in 2026 — a widely used security scanner, a popular LLM gateway library, and a VS Code extension — using credentials and access gained from one compromise to reach the next. The reporting on it comes mostly from one vendor's writeup, corroborated in pieces by the affected companies themselves, so this piece is careful about which specific numbers and mechanisms are solid and which are still one source's account.
Who's behind this, and what's actually confirmed about them
The most detailed account of this campaign comes from a security vendor, BlackFog, published November 6, 2026, which pulls together incident details from Aqua Security (the maker of the Trivy scanner), a GitHub security statement, and its own payload analysis. GBHackers' November 10, 2026 coverage summarizes the same material with a sharper headline but less of the underlying nuance, and is where this story first crossed into general tech-news coverage.
TeamPCP, per BlackFog's account, surfaced publicly via a Telegram channel that launched in November 2025, growing to roughly 700 members by February 2026. The group itself claims it isn't new — that it's a rebrand of an earlier operation — though that claim isn't independently verified here. Its monetization is described as straightforwardly financial: reselling stolen credentials and source code through a channel called ShellForce, and reportedly partnering with a ransomware operation tracked as Vect to extort some victims directly. Separately from the technical story, Australian authorities charged two alleged members, aged 21 and 23, on August 27, 2026, with the US Department of Justice announcing its own indictment of one of them around the same time — both described explicitly as unproven allegations at this stage, not convictions.
Terms worth getting straight before the timeline
CI/CD pipeline is the automated system that takes a developer's code change and runs it through building, testing, and often deployment — without a person manually running each step. GitHub Actions, the system implicated in part of this attack, is one popular CI/CD platform.
A mutable tag on a GitHub Action is a version label, like v1, that a maintainer can repoint to a different piece of code later — unlike a fixed version number, which is supposed to always point to the same thing. That flexibility is convenient for maintainers pushing quick fixes, but it also means that if an attacker gains write access, they can silently redirect everyone already using that tag to run new, malicious code with zero configuration change on the user's end.
A personal access token (PAT) is a credential that lets a script or tool authenticate to GitHub with a specific person's or service's permissions, standing in for a password. A stolen PAT with broad permissions can do almost anything that account could do manually — including, as this story shows, creating new repositories to stash stolen data in.
Typosquatting a domain, in this context, means registering a URL that looks almost identical to a legitimate company's real domain — the kind of thing a quick visual scan of a log file would miss.
How the Trivy compromise actually happened
Trivy is a widely used open-source vulnerability scanner made by Aqua Security, commonly run inside CI/CD pipelines to check containers and code for known security issues before deployment. Per BlackFog's account of Aqua's own incident findings, the root cause traces back to an earlier, separate security incident — after which credential rotation was incomplete, leaving some access still valid that should have been revoked. TeamPCP used that lingering access to get into Aqua's open-source release environment and force-pushed malicious commits into the project's GitHub Action tags. Aqua's investigation found that 76 of 77 trivy-action tags had been redirected this way. Because the tags themselves were mutable, any pipeline already referencing one of them picked up the malicious code automatically, with no visible change on the user's side. GBHackers' coverage separately names a specific poisoned binary version, v0.69.4, but that detail doesn't appear in BlackFog's more detailed account and isn't independently corroborated here — it's a single-source claim, not a confirmed fact, if you're citing the exact version.
BlackFog's timeline places this compromise, along with a parallel one affecting Checkmarx's KICS tool, between March 19 and 24, 2026.
Then LiteLLM, then a VS Code extension
The same window of activity reached LiteLLM, a widely used library for routing requests to different large language model providers through one interface — BlackFog notes it sees roughly 95 million monthly downloads, though that figure describes the project's overall popularity, not how many of those downloads were of the affected versions specifically. Two versions, 1.82.7 and 1.82.8, were identified as compromised. The later one installed a .pth file — a Python mechanism that runs arbitrary code automatically whenever Python itself starts up, even in scripts that never explicitly import LiteLLM at all. On some infected machines, this reportedly dropped a persistent background service that checked in for new commands every 50 minutes.
Nearly two months later, on May 18, 2026, the campaign reached Nx Console, a VS Code extension with more than 2.2 million installs across its version history, used by developers working with the Nx build system. A malicious version was live on the VS Code Marketplace for roughly 18 minutes before removal. Here's a genuine gap in the public reporting: neither BlackFog's account nor GBHackers' names the specific version number that was poisoned, or explains exactly how the attackers obtained the publishing credentials used to push it. If you see a specific mechanism stated confidently elsewhere, it isn't supported by either source checked for this piece.
What the payload did once it was running
Across the Trivy and LiteLLM compromises, the actual data-theft mechanism followed a consistent pattern, per BlackFog's payload analysis. On GitHub-hosted CI runners, the malicious code searched the Runner.Worker process's own memory for values GitHub had flagged as secrets — a technique that specifically sidesteps the masking that normally hides secret values in workflow logs. On self-hosted runners, where that specific trick doesn't apply the same way, it instead searched more than 50 known filesystem locations for SSH keys, cloud provider credentials, Kubernetes configuration files, and cryptocurrency wallet files.
Whatever it found was encrypted with AES-256-CBC under an RSA-4096 public key, bundled into an archive named tpcp.tar.gz, and sent over HTTPS to a domain, scan.aquasecurtiy.org, built to look like it belonged to Aqua Security at a glance. BlackFog's writeup also describes a fallback method — if that upload failed and a sufficiently privileged stolen token was available, the malware could create a new repository named tpcp-docs in the victim's own GitHub account and attach the stolen archive to a release there, using GitHub's own infrastructure as the exfiltration channel. That specific detail deserves a careful reading: BlackFog describes it as something the malware "could" do, which reads as a documented capability rather than a confirmed, observed action in every case. One operational detail worth remembering if you're on the response side of an incident like this: BlackFog notes some stolen tokens were reportedly used by attackers weeks after the original theft — meaning removing the malicious code isn't sufficient on its own; every credential it could have touched needs rotating regardless of when the cleanup happened.
The 3,800-repository number — whose claim is it, really
This is the figure that made headlines, and it deserves a more careful framing than most coverage gives it. The claim that roughly 3,800 of GitHub's own internal repositories were stolen — reportedly pulled from a single GitHub employee's device — originates with TeamPCP itself, not with GitHub's own initial disclosure. GitHub's own public statement, as relayed by BlackFog, describes the group's claim as "directionally consistent" with what GitHub's internal investigation found — a careful phrase that confirms the rough shape of the claim without validating its precision. GitHub separately stated that it found no evidence that any customer-owned repositories were affected, and that credentials stolen in the March compromise were used to explore other parts of GitHub's own environment afterward. Reports that the stolen repositories were subsequently listed for sale at a specific price aren't independently confirmed here and are left out of this piece's confirmed-facts list for that reason.
Why this is a pipeline story, not a malware story
Pull back from the specific tool names, and the actual lesson here applies to any CI/CD pipeline, not just the three tools named: a pipeline is only as trustworthy as every mutable reference inside it, and "we scan our dependencies for known vulnerabilities" doesn't protect you if the scanner itself is one of the compromised links in the chain. Mutable version tags, broadly scoped access tokens that outlive the incident they were issued for, and build systems that pull in third-party actions or extensions without pinning them to an immutable, verified version are the specific weaknesses this entire campaign exploited at every stage — not some novel zero-day in any of the three tools themselves.
That's exactly the kind of practical pipeline hygiene Innovative Academy's DevOps training in Bangalore works through directly: setting up CI/CD pipelines with GitHub Actions and similar tools the right way from the start, pinning dependencies and actions to specific commit hashes instead of mutable tags, managing secrets so a single leaked token doesn't cascade across an entire organization's build infrastructure, and building the habit of auditing exactly what a pipeline pulls in automatically before trusting it with production credentials. Reading an incident writeup like this one and being able to map each step back to a concrete pipeline configuration choice is the difference between following security news and actually being able to prevent the next version of it. Contact for course details: 8447712333.
What we're not claiming
The specific Trivy binary version named in some coverage, v0.69.4, comes from a single secondary source and isn't corroborated in the more detailed primary writeup this piece relies on, so the exact version number should be treated as unconfirmed. Nx Console's exact compromised version number and the precise method used to steal its publishing credentials aren't stated in either source checked here; that's a real gap in the public reporting, not an oversight on our part. The 3,800-repository figure is TeamPCP's own claim, which GitHub has called "directionally consistent" with its findings rather than independently confirmed as an exact count — the real number could be somewhat different in either direction. The tpcp-docs fallback-exfiltration method is described in the sourcing as a documented capability of the malware, not confirmed as something that was actually used in every affected environment. And the criminal charges against two alleged TeamPCP members in Australia, along with a separate US indictment, are allegations at this stage — nothing here should be read as establishing guilt.