If your business has an in-house development team or outsources software work to a third party, there is a threat you need to understand right now. Attackers are hiding malicious code inside developer packages that your team already trusts and uses every single day.
This type of attack is called a software supply chain attack, and it is happening more frequently than most business owners realise. What makes it particularly dangerous is that your developers do not have to do anything wrong for it to succeed.
What Is a Developer Package?
When developers build software, they rarely write everything from scratch. Instead, they rely on pre-built collections of reusable code called packages. These packages handle common tasks like formatting dates, sending network requests, or managing how different parts of an application communicate with each other.
The most popular place to download these packages is the npm registry, which stands for Node Package Manager. npm hosts more than 2.5 million JavaScript packages, and developers download them billions of times every week. It is one of the most used tools in software development worldwide.
Think of packages the same way you would think of buying a pre-built component for your business rather than manufacturing it in-house. It saves time and money. But just like a faulty component can create problems down the line, a compromised package can introduce serious risk into your systems.
What Is a Software Supply Chain Attack?
A supply chain attack targets the tools, platforms, and resources that developers rely on during the build process. Rather than trying to break through your firewall directly, attackers compromise something your developers already use and trust.
When a malicious package is installed, the harmful code runs automatically inside your environment. Your developers did nothing wrong. They installed a package they had always trusted. The package, however, had been quietly tampered with.
The result is that attackers gain access to your systems through the front door, hidden inside legitimate, everyday code.
This Is Happening Right Now
This is not a theoretical risk. These attacks have been accelerating at a pace the security industry has not seen before.
In September 2025, a self-replicating worm called Shai-Hulud tore through the npm ecosystem. It infected more than 500 packages, including widely trusted tools like chalk, debug, ansi-styles, and supports-color. These are not obscure packages. They are used in millions of software projects around the world. The worm stole developer credentials and then used those credentials to automatically spread itself further, infecting even more packages. Security researchers described it as a turning point for software supply chain threats.
In March 2026, the axios package was hit. Axios is one of the most downloaded JavaScript libraries in existence, with more than 100 million weekly downloads. Two malicious versions were published that delivered malware to macOS, Windows, and Linux systems. Even though the compromised versions were taken down within a few hours, researchers at Huntress observed at least 135 endpoints contacting attacker-controlled infrastructure during that window alone.
In May 2026, a single compromised npm maintainer account was used to publish 637 malicious versions across 317 packages in just 22 minutes. Those packages had a combined reach of more than 15 million monthly downloads. Popular tools like echarts-for-react and timeago.js were among those affected.
Also in May 2026, attackers targeted node-ipc, a widely used Node.js library with over 10 million weekly downloads. Three malicious versions were published at the same time, deliberately targeting different version patterns so that as many developers as possible would automatically download the compromised code. Once installed, the payload silently collected more than 90 categories of sensitive data including AWS credentials, Azure access tokens, SSH keys, GitHub configs, database passwords, Kubernetes secrets, and shell history. Everything was then compressed and quietly sent to an attacker-controlled server.
These are not obscure or fringe tools. They are the everyday building blocks of modern software development.
According to Sonatype’s 2026 Software Supply Chain Report, more than 454,600 new malicious packages were identified in 2025 alone, bringing the cumulative total of known malicious packages to over 1.2 million. Over 99 percent of open source malware in 2025 occurred on the npm platform.
How Attackers Actually Get In
Understanding how these attacks happen makes it clear why they are so difficult to catch without the right oversight in place.
The most common methods include:
- Compromised maintainer accounts: Attackers use phishing emails to steal the login credentials of trusted package authors. Once inside, they publish a new version of the package with malicious code injected directly into it.
- Rogue maintainer accounts: In some cases, attackers gain access by getting a new, malicious account added as a co-maintainer of a package. That account then publishes a poisoned version.
- Typosquatting: Attackers publish fake packages with names that look almost identical to popular ones, betting that a developer makes a small typo during installation.
- Dependency confusion: Attackers upload a malicious public package using the same name as a private internal package used within a company, tricking automated systems into downloading the wrong one.
The September 2025 attack on chalk and debug started with a phishing email sent to a trusted package maintainer. The message was designed to look exactly like a genuine npm support notice. It asked the developer to update their login credentials and directed them to a convincing fake login page. Once the attacker had their credentials, they pushed malicious code into packages downloaded by millions of projects within minutes.
What Can Attackers Steal?
Once a compromised package runs inside a developer’s environment, attackers can quietly harvest an enormous amount of sensitive information.
Common targets include:
- Cloud credentials (AWS, Azure, Google Cloud)
- SSH keys and API tokens
- Database passwords and connection strings
- CI/CD pipeline secrets and build tokens
- GitHub and code repository access tokens
- Browser stored credentials
- Shell history and configuration files
This information can be used to access your business systems directly, exfiltrate customer data, move through your network undetected, or be sold to other criminal groups. In several recent attacks, stolen GitHub tokens were used to infect additional packages, continuing the cycle and widening the blast radius further.
Your AI Coding Tools Could Be Making This Worse
Here is something many business owners and managers do not realise. Your development team is probably not the only thing installing packages into your software environment. There is a good chance AI coding tools are doing it too, automatically and without any human reviewing what gets added.
AI coding assistants (vibecoding) have become a standard part of how modern software gets built. Tools like Claude Code (Anthropic’s command-line coding agent, OpenClaw, GitHub Copilot, Cursor, Windsurf, OpenAI Codex, and others can now write code, suggest packages, install dependencies, and even run commands directly inside a developer’s environment, often with very little oversight.
That is enormously productive. It is also a serious security risk.
What AI coding agents can actually do
These tools are not just autocomplete. They are full agents with access to your codebase, your file system, your environment variables, and in many cases the ability to run terminal commands. When an AI coding agent suggests adding a new package and your developer approves it without checking, a compromised package can be installed in seconds.
The problem is that AI tools do not inherently know whether a package is safe. They work from what is available in the npm registry and what appears legitimate. They have no way to detect that a package was tampered with at the source by a criminal who compromised a maintainer’s login.
These tools have already been targeted
Attackers know that AI coding agents are now widely used. They have started targeting them specifically.
In April 2026, a malware campaign called mini Shai-Hulud was identified targeting npm packages used in SAP development environments. What made it stand out was not just what it stole. It was how it persisted. The malware injected configuration files directly into Claude Code’s settings, exploiting the SessionStart hook so that every time a developer opened a project, the malicious code ran again automatically. VS Code was targeted in the same campaign through its task runner configuration.
Security researchers have noted that tools like Claude Code, OpenClan, OpenAI Codex, Cursor, Windsurf, Cognition Devin, and GitHub Copilot are all privileged developer runtimes. They can read source trees, edit files, call tools, and run shell commands. When shell execution and network access are both available, a compromised or mistaken agent action can read local data and transmit it using ordinary tools like curl, git, or cloud CLIs.
In other words, the more capable the AI coding tool, the more damage a compromised package can do when it gets in.
The Claude Code connection
Claude Code is Anthropic’s AI coding agent and it runs via npm. On March 31, 2026, during the same window that the axios supply chain attack was active, malicious versions of axios containing a Remote Access Trojan were published, and developers who installed or updated Claude Code during that period may have pulled the compromised dependency without knowing it.
That kind of overlap, where a widely used AI tool and a compromised package collide in the same install window, is not a fluke. It is exactly the kind of scenario attackers are engineering.
It is also worth noting that the node-ipc attack mentioned earlier in this article specifically targeted Claude AI configuration files as part of its credential-harvesting payload. AI tool settings and tokens are now on the list of things attackers are actively hunting for.
The outsourcing angle gets more complicated here
If your outsourced development team is using AI coding agents (and most modern teams are), you have even less visibility into what is being installed and how. You are not just trusting your developers. You are trusting the AI tools they use, the packages those tools recommend, and whether anyone on that team has the security awareness to question any of it.
Most do not. And that is not a criticism. It is simply the reality of how fast this space is moving.
Does This Actually Affect My Business?
If any of the following apply, the answer is yes.
- You have an in-house development team
- You outsource software development to an agency or freelancers
- Your business runs web applications, customer portals, APIs, or internal tools
- Your developers use open source libraries (which almost all of them do)
- Your team uses AI coding tools to help write or manage code
You do not need to be a software company to be exposed. Any business that has custom software built for it carries this risk. The exposure lives inside the code your developers wrote and, more specifically, in the third-party packages they used to build it.
What About Outsourced Development?
Outsourcing development does not remove the risk. In many cases, it increases it.
When you outsource software work, you have less visibility into the specific tools and packages being used. You have less control over the security practices of the team doing the build. And if something goes wrong, your business is still the one that carries the consequences.
This is not a criticism of outsourcing. It is simply a reality that needs to be managed with the right oversight in place.
What Can Your Business Do?
You do not need to understand every technical detail to start reducing your exposure. But you do need someone who does.
There are practical steps that make a real difference:
- Audit your dependencies: Know what packages your software relies on and whether any have been flagged as malicious or at risk.
- Pin your versions: Avoid automatic updates that could silently install a new, compromised version without your knowledge.
- Monitor for unexpected behaviour: Use tooling that alerts your team when a package starts behaving in a way it should not.
- Apply multi-factor authentication: Developer accounts that publish or maintain packages must be protected with strong, modern authentication.
- Vet your development suppliers: If you outsource builds, security obligations should be part of the contract and reviewed regularly.
- Review your AI coding tool permissions: If your team uses AI coding agents, make sure those tools are not running with more access than they need and that package installations are reviewed before they go in.
Most SMBs and their development partners are not consistently doing all of these. That gap is exactly what attackers are counting on.
Get a Security Review Before Something Goes Wrong
If you are not sure whether your business is exposed to this threat, that uncertainty itself is a problem. The good news is that it is a solvable one.
At Sentry Cyber, we work with businesses that have in-house development teams and those that outsource their builds. We can review your environment, identify whether compromised developer packages or other supply chain risks pose a threat to your systems, and give you a clear, practical action plan.
Our security assessments are designed for non-technical decision-makers. You do not need to know how npm works. You just need to know whether your business is protected.
We also offer security consulting for businesses that want ongoing expert guidance, and CISO as a Service for those who want a dedicated security lead without the cost of a full-time hire.
Conclusion
Software supply chain attacks are no longer a niche problem for large technology companies. They are happening every week, targeting tools that everyday development teams rely on. And the businesses most at risk are often the ones with the least visibility into their own software.
If you have a development team, you should know what they are building with. If you outsource software work, you need assurance that someone is keeping an eye on what goes into your code.
Sentry Cyber can give you that visibility. Get in touch today for a no-obligation security review.
FAQ
Q: Can AI coding tools like Claude Code or Cursor introduce compromised packages?
Yes. AI coding agents suggest and install packages automatically based on what is available in the npm registry. They have no built-in way to detect whether a package has been tampered with at the source. Attackers have started targeting AI coding tool configurations specifically, using compromised packages to persist malicious code that runs every time a developer opens their project. If your team uses AI coding assistants, the packages they install need to be treated with the same scrutiny as anything a human developer adds manually.
Q: What is a software supply chain attack?
A software supply chain attack targets the tools, packages, or third-party services that developers rely on to build software. Instead of attacking your business directly, attackers compromise something your developers already trust, such as a popular open source package, and use it to deliver malicious code into your environment automatically.
Q: How would I know if my software uses compromised packages?
In most cases, you would not know without a technical review. Compromised packages are designed to look and behave exactly like the legitimate version they replaced. A security assessment can identify whether your software relies on any packages that have been flagged as malicious or that carry an elevated level of risk.
Q: Does this only affect large companies?
No. Any business that has custom software built for it is at risk. In fact, smaller businesses are often more exposed because they tend to have fewer security controls, less visibility into their software dependencies, and less capacity to detect an incident when it occurs.
Q: What is npm and why should I care about it?
npm stands for Node Package Manager. It is a public registry where developers publish and download reusable code packages used to build software. With more than 2.5 million packages and billions of weekly downloads, it is one of the most widely used tools in software development. Because so many projects pull packages from npm automatically, a single compromised package can cascade across thousands of downstream applications.
Q: We outsource all our development. Are we still at risk?
Yes. Outsourcing development does not transfer the risk away from your business. You still carry the consequences if something goes wrong. The difference is that you have less visibility into what tools and packages your development partner is using. A security review can assess that exposure and help you put the right protections in place.
Q: What does Sentry Cyber actually do in a security assessment for this type of threat?
We review the software environments and dependencies associated with your business, identify whether any known malicious or high-risk packages are present, look at the security practices of your development team or suppliers, and provide clear, actionable recommendations. Everything is explained in plain language. No jargon, no overwhelming technical reports.