Part 4 of The Rise of Supply Chain Attacks: Why 2025–2026 Changed Everything
On May 20, 2026, GitHub confirmed what TeamPCP had posted on an underground forum a day earlier: the group had accessed approximately 3,800 internal GitHub repositories and was selling the alleged source code and internal organization data for $50,000. Their message was blunt: “This is not a ransom. We do not care about extorting GitHub. One buyer and we shred the data on our end. It looks like our retirement is soon, so if no buyer is found, we leak it for free.”
GitHub confirmed the breach was detected and contained, and that customer data outside internal repositories showed no evidence of impact. Investigation was ongoing at time of writing.
TeamPCP (also tracked as UNC6780) is not a new name. The group has been running a sustained, escalating campaign throughout 2026 — compromising Aqua’s Trivy security scanner, Checkmarx’s KICS, LiteLLM, the Telnyx SDK, TanStack, Mistral AI, OpenSearch, Guardrails AI, and Microsoft’s official durabletask Python SDK, among others. Their self-replicating worm, Mini Shai-Hulud, automates the entire propagation loop: steal CI/CD credentials, publish infected versions of new packages, repeat. The GitHub breach is not a new campaign — it is the same campaign, reaching its most consequential target to date.
Here is what the full picture tells us.
1. The Company Laptop Is Now Primary Infrastructure
The company laptop is now primary infrastructure. That is not a metaphor or an aspiration — it is a statement about what happened. The entry point into approximately 3,800 internal GitHub repositories was not a misconfigured cloud policy or a vulnerable API. It was a developer installing a VS Code extension on their work machine. That machine held credentials that reached GitHub’s internal codebase. By any reasonable definition of “infrastructure,” that laptop was part of it.
GitHub’s investigation revealed that the attackers accessed the internal repos after a GitHub employee installed a poisoned Visual Studio Code extension. Every organization’s threat model has an implicit assumption about where the sensitive surface lives — production infrastructure, cloud environments, CI/CD pipelines get the scrutiny. Developer workstations are treated as endpoints, managed with endpoint controls, but rarely modeled as a path to the internal repositories of the platform hosting the global software ecosystem. That assumption is now demonstrably wrong.
VS Code extensions are a significant and underdefended attack surface. A malicious extension does not get a CVE. It is not a vulnerable component; it is a working installer for the attacker’s tooling. Software Composition Analysis scans package.json and requirements.txt, not the VS Code extension store. The extension ran, harvested credentials, and exfiltrated them before the endpoint was isolated. Containment stopped the bleeding. It did not undo what was taken.
The operational implication is direct: developer workstations must now be modeled with the same threat assumptions applied to CI/CD runners and production cloud environments. Extension allow-listing policies enforced at the organization level, monitoring for unexpected child processes and credential file reads, and treating any machine that installed an unvetted extension in a relevant time window as a potentially compromised host requiring full credential rotation — not just a software uninstall.
2. FIRESCALE Makes Domain Blocking Structurally Insufficient
The most technically significant detail in the campaign is FIRESCALE, the C2 resilience mechanism embedded in the durabletask payload and linked operationally to the broader Mini Shai-Hulud infrastructure.
When the primary C2 domain is unreachable, the worm does not fail over to a hardcoded backup. It queries GitHub’s public commit history, searching for messages matching the pattern FIRESCALE <base64_url>.<base64_signature>, extracts the encoded C2 address, and reconnects. The operator publishes a commit to a public repository. Every infected host recovers its C2 channel without any further operator involvement.
The implication for defense is significant. The backup C2 infrastructure runs on GitHub’s API — traffic that every corporate network allows, and cannot meaningfully restrict without breaking the development workflow entirely. Domain blocking remains worth doing; it raises the attacker’s operational cost and eliminates the primary C2 path. But it cannot be the final control when the rotation mechanism routes through api.github.com.
Detection has to move upstream from the domain to the behavior. The FIRESCALE query pattern is a stable IOC that survives infrastructure rotation. So are the exfiltration endpoint paths (/api/public/version), the credential file targets, and the worm’s infection markers (~/.cache/.sys-update-check, ~/.cache/.sys-update-check-k8s). Behavioral detection on those signals holds its value even after the operator burns a domain and registers a new one.
3. The Exfiltration Has Three Independent Channels — Each Defeating a Different Control
The durabletask payload does not rely on a single exfiltration path. Harvested credentials are buffered to a 102,400-byte threshold, then dispatched through three independent transport channels.
The first is HTTPS POST to the C2 domain on port 443. This fails if egress filtering blocks the domain — which is why it is not the only channel.
The second is GitHub API exfiltration using any stolen GitHub tokens. The payload creates commits or release artifacts on the victim’s own repositories, or posts data as release assets. From a network monitoring perspective, this traffic is bound for api.github.com and is indistinguishable from legitimate developer activity. Most enterprise egress policies explicitly allow it.
The third is DNS tunneling, activated when both network-layer options are blocked.
The GitHub API channel deserves particular focus because it exploits a constraint no enterprise can remove: developer environments must communicate with GitHub. Detecting exfiltration through this path requires behavioral monitoring of GitHub API activity — anomalous commit patterns, unexpected release artifact creation, API calls from processes that should not be making them — not just egress filtering at the firewall.
The worm also caps its lateral movement at five targets per infected host via AWS SSM SendCommand or kubectl exec, deliberately throttling the fan-out to stay below the anomaly threshold in CloudTrail and Kubernetes audit logs.
4. The Worm’s Credential Reach Is Broader Than Most Teams Assume
The durabletask payload sweeps every significant secrets plane in a modern cloud-native environment: AWS (IAM credentials, IMDS, Secrets Manager, SSM), Azure, GCP service accounts, Kubernetes service account tokens, HashiCorp Vault KV secrets, and SSH keys. It also attempts to unlock and dump 1Password and Bitwarden vaults by brute-forcing the master password from environment variables and shell history (~/.bash_history, ~/.zsh_history), and reads Docker credentials and VPN configurations.
The password manager targeting is the detail most teams will not have modeled. If a developer’s Bitwarden or 1Password vault is unlocked on a compromised machine, the payload attempts to read it. That vault may contain credentials that are entirely outside the developer’s cloud environment — personal accounts, shared team credentials, anything stored for convenience. The blast radius of a single compromised developer device now potentially includes everything that person has in their password manager.
Remediation guidance from Wiz is appropriately broad: rotate AWS credentials (especially IAM User credentials), Azure credentials, GCP service accounts, Kubernetes service accounts, Vault tokens, and any passwords stored in Bitwarden or 1Password. Assume shell history was exfiltrated. On any host that imported an affected version of durabletask, treat the entire credential footprint of that machine as compromised — not just the CI/CD secrets.
5. Nine Weeks. Zero CVEs. This Is the Structural Problem.
The Mini Shai-Hulud campaign has been running since at least March 2026. Across nine weeks, it has compromised package registries across npm and PyPI, GitHub Actions workflows, VS Code extensions, and now internal repositories at GitHub itself. OpenAI confirmed two employee devices were compromised in the May 11 TanStack wave. The Trivy breach infected tens of thousands of devices with the group’s infostealer.
Zero CVEs exist across the entire nine-week campaign.
This is not a critique of CVE’s maintainers. The system did exactly what it was designed to do: catalog exploitable defects in versioned software components. There were no exploitable defects to catalog. Lifecycle hooks that execute on install are a feature, not a defect. OIDC token federation is working as designed. Mutable Git tags are documented behavior. Reading process memory from within the same runner context is a Linux kernel capability, not a vulnerability. A malicious VS Code extension is not a defect in VS Code.
Security teams that rely on CVE-based tooling as their primary supply chain risk signal had no automated alert fire across the entire campaign. SCA dashboards were clean. Compliance reports were green. The risk was real, active, expanding, and structurally invisible to the tooling most organizations trust to surface it.
The controls that would have caught this operate at a different layer: behavioral detection at the moment a package is published, not when it accumulates enough complaints to earn a database entry. Install-time enforcement that blocks execution before it begins, not an audit that runs after. Continuous verification that pinned commit SHAs remain reachable from their repository’s main branch. Egress monitoring that treats api.github.com as a potential exfiltration destination, not just an allowed endpoint. Extension governance on developer machines modeled as a security boundary, not a convenience policy.
Where This Goes
GitHub’s investigation is ongoing. The full scope of what was taken from internal repositories — source code, infrastructure configuration, internal tooling, secrets present in repository contents — will take time to characterize. TeamPCP’s “retirement” announcement should be treated with appropriate skepticism; threat actor retirement claims have a poor track record of accuracy, and the first independent Shai-Hulud worm clones appeared within days of the group releasing their malware’s source code on GitHub.
The structural conditions that made this campaign possible remain in place. Mutable tags, lifecycle hook execution, OIDC federation, blind CI runners, under-monitored extension stores, and FIRESCALE-style C2 resilience are not patched by any of the responses to date. The next group with access to this playbook — and it is now a documented, public playbook — will not announce themselves in a forum post.
The attack surface is the development workflow itself. That is the takeaway that matters most, and it does not go away when this group goes quiet.
Full IOCs for the durabletask compromise are documented in Wiz’s technical analysis and StepSecurity’s incident report. The FIRESCALE C2 mechanism is detailed by Hunt.io. GitHub’s official statement is on the GitHub blog. The full Mini Shai-Hulud campaign tracker is maintained by Socket at socket.dev/supply-chain-attacks/mini-shai-hulud.