Modern websites and applications are built on layers of third-party software. That makes development faster and more powerful—but it also gives attackers another path into systems that may otherwise be well protected. The return of the Shai-Hulud npm supply-chain worm is a timely example of why developers and businesses need to pay closer attention to the code they trust.
A website does not have to be directly attacked to be compromised. Malicious code can enter an organization through a software dependency that a developer installs and trusts.
Shai-Hulud Resurfaced After 111 Days
On September 7, 2026, security researchers at Aikido Security reported finding four npm package versions containing a payload associated with the Shai-Hulud malware campaign.
What made the discovery especially notable was that researchers said the malicious file was not a newly modified version created to evade detection. It reportedly carried the same SHA-256 file hash as a payload previously identified during a May 2026 attack.
Aikido reported that the same payload had been absent for 111 days before appearing again.
The four package versions identified in the September discovery were:
feishu-docx-mcp@0.3.2bmc-i18n-extract-cli@1.1.1blueai-cli@0.7.0bmc-translate-utils@1.1.1
Why the npm Malware-Scanning Question Matters
The September incident is important for another reason.
GitHub announced in July 2026 that npm had introduced automatic malware scanning at publish time. Newly published packages are scanned before becoming publicly available for installation. Depending on the results, a package can be released, held for additional review or blocked.
According to Aikido’s analysis, the September packages contained the same known payload previously detected during the May campaign, yet the packages still became available on npm.
That does not mean npm’s security controls have no value. Automated scanning remains an important layer of defense. It does, however, demonstrate why developers should never depend on a single security control.
What Is a Software Supply-Chain Attack?
Traditional cybersecurity often focuses on protecting the final target: the website, server, workstation or employee account.
A software supply-chain attack approaches the problem differently. Instead of attacking the final organization first, an attacker targets something that organization already trusts.
That trusted component could be:
- an open-source package;
- a software library or dependency;
- a developer or maintainer account;
- a source-code repository;
- a build server;
- a CI/CD pipeline;
- a software-update mechanism; or
- a third-party development tool.
Once malicious code reaches a trusted component, it can potentially travel downstream into other projects and organizations.
Think of it this way: instead of attempting to break into 1,000 buildings individually, an attacker looks for an opportunity to compromise the company supplying electronic locks to all 1,000 buildings.
Software dependencies can create the same type of multiplier.
Why Shai-Hulud Is More Than a Malicious Package
The concern surrounding Shai-Hulud is not limited to one infected npm package.
Previous versions of the malware have been associated with credential theft and self-propagation through additional packages.
In August 2026, JFrog Security Research reported a large Shai-Hulud campaign affecting more than 400 npm packages across more than 1,700 package versions. The campaign included widely used software such as Keyv and Cacheable.
Singapore’s Cyber Security Agency also warned organizations that Shai-Hulud-related malware could steal developer credentials and propagate through compromised npm packages.
Why a Worm Is Different
A self-propagating attack can potentially create a chain: compromise a developer → steal credentials → compromise packages → reach additional developers → acquire additional credentials → continue spreading.
That ability to propagate is what makes software supply-chain worms particularly dangerous.
Developer Credentials Are High-Value Targets
A developer’s computer or build environment can contain access far beyond a single website password.
Depending on the organization, development systems may have access to:
- GitHub or other source-code repositories;
- npm publishing accounts;
- cloud platforms;
- deployment servers;
- API keys;
- database credentials;
- SSH keys;
- environment variables;
- authentication tokens; and
- production infrastructure.
If malware executes inside a development environment, the resulting compromise can extend far beyond the package that originally introduced it.
Your Website Could Be Affected Without Being Directly Hacked
This is one of the most important lessons for businesses to understand.
Imagine a company has properly secured its web server. Strong passwords are being used. Multifactor authentication is enabled. The firewall is configured correctly, and security updates are being installed.
Then a developer installs or updates an application dependency.
If that dependency contains malicious code, the attacker may gain an opportunity to operate inside a trusted development process rather than attacking the public website from the outside.
In other words, many traditional defenses may still be functioning exactly as designed.
The problem is that trust itself has become the attack vector.
Open Source Is Not the Problem—Blind Trust Is
Open-source software powers an enormous part of today’s Internet. It enables developers to build applications faster, avoid reinventing common functionality and benefit from the work of global development communities.
The answer is not to stop using open-source software.
The answer is to treat software dependencies as part of an organization’s security perimeter.
Before relying on a dependency, developers should increasingly ask:
- Who maintains this package?
- Is the package still actively maintained?
- Did ownership recently change?
- Why was a new version published?
- What changed in that release?
- Does it execute installation scripts?
- What other packages does it bring into the project?
- Does the application actually need it?
- What would happen if the package became compromised?
npm Is Changing How It Handles Installation Security
The npm ecosystem is also moving toward a more restrictive security model.
JFrog notes that with npm 12, dependency
preinstall lifecycle hooks do not execute by default.
This is significant because malicious packages have historically used
installation scripts as one way to execute unwanted code during package
installation.
npm has also added publish-time scanning and additional trusted publishing controls designed to reduce supply-chain risks.
These changes represent an important shift in software security: installed should not automatically mean trusted.
What Developers and Organizations Should Do Now
There is no single setting capable of eliminating software supply-chain risk. A layered approach is more effective.
Know which direct and transitive packages are actually present in your projects instead of assuming only explicitly installed packages matter.
Avoid treating every newly published dependency version as an automatic production upgrade.
Lock files help keep builds reproducible and reduce unexpected package-version changes.
Publishing tokens, API keys, cloud credentials and deployment credentials should be tightly controlled and rotated when compromise is suspected.
Where supported, favor short-lived credentials and trusted publishing mechanisms rather than permanent tokens.
Build and deployment pipelines frequently contain powerful credentials and should be treated as high-value infrastructure.
Developers should understand which dependencies can execute code during installation and take advantage of newer npm security controls.
An unexpected release, ownership change or installation behavior in a familiar dependency deserves investigation.
When a supply-chain incident is disclosed, organizations need to determine quickly whether affected software exists anywhere in their environment.
This Threat Is Bigger Than npm
Shai-Hulud is one example of a much broader cybersecurity challenge.
Modern applications are assembled from software written by developers, organizations and open-source projects around the world. One application can depend on hundreds or even thousands of other software components when transitive dependencies are included.
Every dependency provides functionality.
Every dependency can also introduce risk.
Attackers understand the leverage that creates.
Instead of attempting to compromise organizations one at a time, an attacker who successfully compromises a trusted component may gain a path toward many downstream systems.
That is why software supply-chain security has become one of the most important cybersecurity areas for developers and technology teams to monitor.
The Warning From Shai-Hulud
The September resurgence of Shai-Hulud provides a useful security reminder.
A known malicious payload disappeared for 111 days and then resurfaced. Researchers reported that the same previously identified file appeared in new npm package versions even after publish-time malware scanning had been introduced.
That does not mean developers should stop trusting npm, GitHub or open-source software.
It means trust must be verified and security must be layered.
Businesses increasingly need to understand where their software comes from. Developers need visibility into their dependencies. Development credentials need strong protection. Build pipelines need security controls of their own.
Authoritative Sources & Further Reading
- Aikido Security — Shai-Hulud Rises From the Dead After 111 Days
- GitHub — npm Publish-Time Malware Scanning and Dual-Use Metadata
- JFrog Security Research — Major Shai-Hulud Campaign Strikes npm Again
- Cyber Security Agency of Singapore — Ongoing npm Supply-Chain Attack Advisory
- GitHub — Multiple Trusted Publishing Configurations for npm
Is Your Website’s Technology Stack Secure?
Website security extends beyond passwords and updates. Dependencies, hosting environments, development workflows and third-party integrations can all affect the security of a modern website. Computer Technologies helps organizations build and maintain strong, practical digital foundations.
