You might think the biggest threat to your software is a hacker breaking through a firewall, but the reality is far more subtle. Attackers have shifted their focus from cracking open locked doors to simply walking through the ones you hold open for them. They are no longer relying on brute force; instead, they are exploiting the very tools and shortcuts you use to build and deploy code. This shift makes the open source supply chain one of the most vulnerable points in modern software development. Recent campaigns have shown that malicious code hidden in open-source packages and AI assistants has become the easiest way to compromise systems. The risk is alarming: one security firm estimates a roughly 1-in-10 chance that any package your organisation installs could trigger an active attack. Understanding how these software supply chain attacks work is no longer optional—it is essential for protecting your work.
H2: The TeamPCP Campaign – Poisoning Open-Source Packages at Scale
That threat is not theoretical. One group, TeamPCP, has already shown how easily bad actors can exploit the open source supply chain. In under four months, they injected malicious code into more than 1,000 widely used packages. Their poisoned packages now rack up roughly 500 million downloads a week. The list of victims includes well-known names like Bitwarden, Red Hat, SAP, PyTorch Lightning, and GitHub.
How TeamPCP Injected Malicious Code into Packages
TeamPCP relied on two main techniques: dependency confusion and typo-squatting. Dependency confusion occurs when your package manager pulls a malicious package from a public registry instead of a private one, because the public version has a higher version number. Typo-squatting is simpler: attackers publish packages with names that are easy to mistype, like “requets” instead of “requests.” When you or your automated tools accidentally install these malicious npm packages, you hand the attackers a foothold into your system. These basic package manager security gaps are what let the campaign spread so quickly.
What the Poisoned Packages Actually Did
Once installed, the booby-trapped packages could do real damage. They performed data exfiltration, silently stealing sensitive information from your environment. They also enabled remote code execution, giving the attackers direct control over the infected machine. This is not just a nuisance — it is a full compromise of your system, and it can happen without any warning or suspicious activity visible to you.
Extortion and Motive – $90,000 in Two Months
What drives a group behind such a massive operation? TeamPCP appears to be after chaos and notoriety rather than a huge financial windfall. In two months of extortion demands, they pocketed only about $90,000. That sum is surprisingly small for the scale of the campaign, suggesting that disruption and visibility are the real goals. Understanding these types of attacks is essential for anyone who relies on the open source supply chain.
AI Coding Agents – The Unwitting Accomplice
That same open source supply chain now faces a new kind of threat—one that exploits the very tools meant to speed up development. AI coding assistants have become a standard part of many developers’ workflows. They can write code, fix bugs, and install dependencies automatically. What sounds like a productivity boost is also a fresh attack surface. Because these agents often act without human oversight, a single well-crafted prompt can turn them into a delivery vehicle for malware.
How a Fake Bug Report Hijacks an AI Agent
Attackers don’t need to break into your system directly. Instead, they plant a fake bug report in a public repository or a popular forum. The report describes a plausible issue—for example, a missing dependency or a compatibility problem. When you ask your AI assistant to help resolve the bug, the agent reads the report and automatically runs the suggested fix. That fix might be a command to install a malicious package from the open source supply chain. Because the agent trusts the content, it executes the instruction without asking for confirmation. The result: a compromised development environment, all from a single piece of text.
Why Developers Are Exposed When Using AI Assistants
Traditional code review gates are designed to catch human errors. But AI agents operate at machine speed, often skipping those checks. They install packages, modify configuration files, and run scripts based on natural language prompts. Attackers exploit this by using prompt injection—hiding malicious instructions inside the bug report itself. The agent has no way to distinguish between a legitimate fix and a poisoned command. This makes automated dependency installation a critical risk. Every time you let an AI assistant handle a package update without review, you’re trusting the entire open source supply chain behind that suggestion. And as these attacks show, that trust can be easily broken.
The Claude Shared Chats Scam – Social Engineering Meets AI
That breach of trust isn’t limited to automated package updates. Attackers are now turning AI assistants themselves into weapons, using social engineering to bypass technical safeguards. One notable campaign abused Anthropic’s Claude to trick macOS developers into running malicious commands, proving that even the tools designed to help you can be manipulated.
What Is the Shared Chats Feature on Claude?
Claude’s ‘Shared Chats’ feature lets you create a public link to a conversation. It is meant for collaboration or sharing examples. But attackers realized they could stage entire fake support dialogues inside Claude and then share the chat link. To a victim, the conversation looks like a legitimate interaction between an Apple Support agent and a user, complete with convincing formatting and step-by-step instructions.
The Fake Apple Support Attack – Step by Step
Here is how it worked. Attackers crafted a chat on claude.ai where a pretend Apple Support representative guided a developer through a ‘security fix’. The chat would instruct the developer to open their Mac Terminal and paste a specific command. Because the chat looked official and came from a shared Claude link, many developers trusted it. The command likely installed malware or exfiltrated sensitive data like credentials and source code. This is a classic social engineering play, but with a modern twist: the AI chat platform gave the scam an air of authenticity.
Impact on the 2,000 Victims
Security firm Trend Micro identified more than 2,000 victims in this campaign, with the majority located in the Asia-Pacific region. The target profile was clear: macOS developers, who often have access to critical codebases and deployment pipelines. By compromising even one developer’s machine, attackers could gain a foothold into larger systems. This attack highlights another vector in the open source supply chain vulnerability – the human element. When developers are tricked into running arbitrary commands, the entire chain of trust is compromised, from the developer’s local environment to the packages they publish.
To protect yourself, never paste a terminal command from an online chat, even if it appears to be from official support. Verify instructions directly with the company’s verified website or documentation. If a chat asks you to run a command, treat it as a red flag. This scam shows that AI chat abuse can be just as dangerous as a compromised package – and it relies on your trust in the interface.
Protecting Against Open-Source Supply Chain Attacks
That AI chat scam is just one entry point. The broader threat landscape targets the open source supply chain itself — the packages, libraries, and dependencies your project relies on every day. Given that one security firm estimates roughly a 1-in-10 chance that any package your organisation installs could trigger an active attack, waiting until something goes wrong is not a viable strategy. The good news is that practical, repeatable measures can dramatically reduce your risk.
Tools for Automatically Vetting Open-Source Packages
Manual review of every dependency isn’t realistic at scale. This is where software composition analysis (SCA) and dependency scanning tools become essential. SCA tools automatically inventory all open-source components in your project, cross-reference them against known vulnerability databases, and flag packages with known exploits. Pair this with dependency scanning that runs every time you add a new library; it checks for outdated versions, deprecated packages, and suspicious code patterns before the code ever enters your pipeline. Together, these tools form the backbone of modern supply chain security best practices.
Warning Signs a Package or AI Tool Has Been Compromised
Even automated tools have blind spots, so your own vigilance matters. Watch for typo-squatted names — packages with names that look nearly identical to popular libraries but add, remove, or swap a single character. Another red flag is an unexpected version bump: if a package you have used for months suddenly releases a major update with little documentation, pause before upgrading. The same caution applies to any AI-generated command that installs a package you have never heard of. A quick side-by-side compare of the requested name against the official open source package vetting registry usually reveals the trick.
What to Do If You Suspect a Malicious Installation
If you spot something suspicious, act immediately. Isolate the affected system from your network to prevent lateral spread. Pull the software bill of materials (SBOM) for the project — a complete list of every component and dependency — and audit each item. If the SBOM shows a package you did not explicitly approve, remove it and scan for any code that imported from it. Finally, report the malicious package to the repository maintainer and your internal security team. A fast, documented response stops a single mistake from turning into a full breach of the open source supply chain.
Frequently Asked Questions
How can developers protect against open-source supply chain attacks?
Developers should verify package integrity using checksums and digital signatures before installation. Implement a software composition analysis tool to scan dependencies for known vulnerabilities. Regularly audit your dependency tree and remove unused packages to reduce the open source supply chain risk.
What is the difference between a poisoned package and a legitimate one?
A poisoned package often mimics a popular library’s name with slight typos or includes unexpected network calls in its code. Legitimate packages maintain consistent naming, have clear documentation, and show a stable release history on package registries. Checking the package’s public repository and community feedback can reveal clues about its trustworthiness within the open source supply chain.
What should I do if I suspect a package I installed is malicious?
Immediately isolate the affected system from your network and run a full antivirus scan. Review the package’s source code for any suspicious activity, such as data exfiltration or unauthorized file access. Then report the package to the relevant registry maintainer and rotate all credentials that may have been exposed due to the open source supply chain compromise.
