In early 2026 a group called TeamPCP published malicious versions of TanStack packages, and because TanStack is a dependency in countless JavaScript projects the malware spread to hundreds of organisations within hours. OpenAI had two compromised developer devices (they said “a limited number of internal repositories” were accessed, no customer data), at Grafana the entire GitHub environment was compromised and source code was stolen, followed by an extortion attempt. The TanStack incident was however only one of three major supply chain attacks in the first half of 2026, all of which operated on the same fundamental principle.
In May the “Megalodon” campaign infected over 5500 GitHub repositories by disguising malicious commits as legitimate automated contributions, and also in early 2026 the popular Nx Console extension for VS Code was trojanized to steal developers credentials. What connects all three attacks is that they do not target servers or endpoints but rather developers and their tools.
Why developers
Developers are particularly attractive targets from an attackers perspective because they typically have access to everything that is valuable: source code repositories, CI/CD pipelines, cloud consoles, production environments. A compromised developer laptop yields SSH keys, API tokens, cloud credentials, Kubernetes configurations and access to internal systems, all on a single device. On top of that developers constantly install third party code (npm install, pip install, VS Code extensions) and rarely question whether a package is truly trustworthy because it comes from a known provider and is listed in the official registry.
The TanStack attack exploited exactly this trust chain. TeamPCP compromised the official TanStack packages (not fakes with similar names but the real packages), and every developer who ran an update automatically picked up the malware. The malware then exfiltrated GitHub credentials, cloud secrets, SSH keys and CI/CD tokens from the developers device and sent them to the attackers. From there they could break into the repositories and build pipelines of the affected organisations; a classic cascade effect where a single compromised building block produces dozens or hundreds of downstream victims.
The fact that the same group also hacked Trellix, a security software vendor, underscores how difficult these attacks are to detect even for organisations that professionally deal with IT security…
Megalodon
The Megalodon campaign in May 2026 took a different approach but with the same goal. Instead of compromising packages the attackers injected malicious commits into existing GitHub repositories, disguised as automated contributions (e.g from bots that update dependencies or format code). Within a few hours over 5500 repositories were affected, and the stolen data included cloud credentials, SSH keys, Kubernetes configurations and CI/CD secrets.
The effectiveness of this approach is based on the fact that the commits looked like normal maintenance work, and many maintainers approved them without reviewing the code in detail. The attackers targeted the entire software delivery lifecycle, from source code repositories through automation workflows to build pipelines.
VS Code as entry point
The third attack vector involves a trojanized VS Code extension called Nx Console, a popular developer tool for Angular and React projects. Anyone who installed it unknowingly gave the attackers access to their GitHub account, their CI/CD workflows, cloud environments and possibly even production systems.
VS Code extensions run with the same permissions as VS Code itself, which means they can access practically everything the developer has on their machine. There is a marketplace review process but it is nowhere near as strict as e.g mobile app stores, and updates to existing extensions often do not receive close inspection.
Attack chain
The typical sequence of a supply chain attack follows a recurring pattern:
1. Source compromise: The attacker takes over an npm package, a VS Code extension or a GitHub repository (through stolen maintainer credentials, social engineering or a platform vulnerability).
What would have helped: package signing, dependency pinning with hash verification, two factor authentication for all maintainer accounts.
2. Developer installs the update: The compromised package is distributed through the normal update process (npm update, extension update etc).
What would have helped: automated dependency scanning (Dependabot, Snyk), lockfile verification, review of dependency updates before they enter the pipeline.
3. Malicious code executes: The malware runs in the context of the development environment and has access to everything the developer has.
What would have helped: sandboxed build environments, least privilege for developer tools (not every tool needs access to production).
4. Credentials are exfiltrated: GitHub tokens, SSH keys, cloud credentials, API keys are sent to the attacker.
What would have helped: secrets management (HashiCorp Vault etc), no long lived credentials on developer devices, short lived tokens with automatic rotation.
5. CI/CD access: With the stolen credentials the attacker gains access to build pipelines and deployment systems.
What would have helped: OIDC tokens instead of static credentials, pipeline hardening, separate credentials for different environments.
6. Lateral movement: The attacker moves laterally toward production, other repositories and customer systems.
What would have helped: network segmentation, zero trust architecture, separate production credentials that do not reside on developer devices.
7. Data theft or further compromise: Source code is stolen, customer data exfiltrated, or the compromised packages are used to spread the attack further.
What would have helped: DLP, code signing, audit logging, incident response plan.
Recommendations
For Swiss software companies (and really for anyone who develops software) there are a number of concrete measures that significantly reduce the risk of supply chain attacks:
First, dependency management should be treated as a security-relevant process. This means using lockfiles, verifying hashes and deploying automated tools like Dependabot or Snyk that raise alarms when suspicious changes appear in dependencies, rather than letting dependency updates pass through unchecked.
Second, no long lived secrets should reside on developer devices. SSH keys, API tokens and cloud credentials should be short lived and automatically rotated, so that when a developer device is compromised the credentials expire within hours rather than remaining valid for months.
Third, build environments should be isolated from developer devices. CI/CD pipelines should not run with the same credentials that sit on developer laptops, and access to production should go through separate, controlled channels that do not depend directly on the developers workstation.
Fourth, VS Code extensions and other developer tools should not be treated as trustworthy by default simply because they are listed on the official marketplace. When updates come in it is worth reviewing the changes before accepting them..
If you are wondering whether your organisation is prepared against supply chain attacks: talk to us about a security assessment of your development environment.
Sources: