TeamPCP has turned ordinary developer tools into a high-speed route into some of the world’s most important software systems.
GitHub is now the clearest warning sign. A poisoned Visual Studio Code extension compromised an employee device, and the attackers behind the incident claimed they pulled roughly 3,800 internal repositories from the Microsoft-owned platform. GitHub has said that figure is directionally consistent with its investigation so far, while stressing that it has no evidence customer repositories outside its internal systems were affected.
That distinction matters, but it should not make anyone comfortable. Software companies do not run on finished products alone. They run on internal repositories, credentials, build scripts, support snippets, tokens, test systems and developer machines that touch sensitive parts of the business every day. Once those machines become the target, the old perimeter starts to look very thin.
According to WIRED, TeamPCP has been running a near-weekly campaign of supply chain attacks, corrupting open source tools and using one compromise to feed the next. The group has been linked by researchers to attacks across npm, PyPI, Docker Hub, OpenVSX, GitHub Actions and popular developer utilities, including AI and cloud infrastructure projects. That is what makes this episode bigger than one breach. It is a model.
The GitHub incident followed the compromise of Nx Console, a widely used VS Code extension for developers working with Nx projects. The Nx team said malicious version 18.95.0 was available during a May 18 exposure window, from 12:30 to 13:09 UTC, and advised anyone who had the extension installed with auto-update enabled during that period to treat the machine as potentially compromised and rotate credentials.
The Nx postmortem tied the compromise to an earlier poisoned package in the TanStack ecosystem, showing how a routine installation on one contributor machine could become a publishing-path problem for another tool. That is the uncomfortable lesson here. Modern development is built on speed, reuse and automation. Those are enormous advantages when everything is clean. They also give attackers a way to move quickly once one trusted link breaks.
VS Code extensions are especially attractive because they live where developers work. They can see project files, read local environment variables, interact with terminals and sit close to cloud credentials, SSH keys and source control tokens. A browser phishing page has to trick someone into handing over access. A poisoned extension may already be running in the place where access is stored.
Security firm Aikido said the related Nx Console payload was only a small JavaScript injection inside a minified file. That is the kind of detail that should bother executives as much as security teams. Many companies still think about malware as a suspicious executable or a strange attachment. This was software doing what software is allowed to do, just with hostile intent.
The open source risk is now a business risk
TeamPCP’s activity also cuts straight into the AI market. Tools such as LiteLLM, Mistral-related packages and developer libraries used around model deployment and cloud automation have all been mentioned in recent reporting and security analysis around the wider campaign. AI teams are often heavy users of open source packages because the field moves quickly and because stitching together model providers, vector databases, evaluation tools and deployment layers is now normal work.
That creates a serious governance problem. A company may have strict controls over production infrastructure, but developers can still bring in packages and extensions that change quickly, update automatically and inherit trust from a public ecosystem. The risk is not that open source is broken. The risk is that companies have treated open source consumption as a convenience instead of a supply chain that needs active control.
GitHub said it removed the malicious extension version, isolated the affected endpoint and began rotating critical secrets after discovering the incident. Those are expected response steps, and they matter. But the broader defense has to begin earlier, before a developer machine becomes the first point of failure. Companies need tighter extension allowlists, minimum package age policies, automated secret scanning, stronger token scoping and faster rotation when build systems or package registries are touched.
There is also a cultural shift required. Developers have been trained to move fast, install useful tools and trust package managers because that is how modern software gets built. Security teams cannot simply tell them to stop. The practical answer is to make trusted paths easier, risky paths visible and automatic updates less casual for tools that can read local secrets.
TeamPCP is unlikely to be the last group to use this playbook. The incentives are too obvious. A single open source compromise can reach hundreds of organizations, and a single developer workstation can expose code, credentials and internal context that would be hard to get any other way. What happens next will depend on whether companies treat this as another breach headline or as a sign that developer tooling has become core infrastructure. The market should watch how quickly platforms, security vendors and enterprise buyers move from detection to prevention, because the attackers have already made that move.
Also read: Hyperscaler Debt Flood Brings Derivatives Bonanza • Putting The Senses In AI • Samsung’s AI memory bonus fight is testing its chip supply chain
