The JavaScript ecosystem has been hit by another large software supply-chain incident, with more than 400 npm packages from multiple unrelated publishers reportedly compromised. According to Microsoft Threat Intelligence, attackers used malicious package releases to steal developer and CI/CD credentials, then attempted to use those credentials to spread the infection into additional projects.
The campaign is particularly concerning because several affected packages sit inside widely used JavaScript dependency chains. Names associated with ecosystems such as keyv, flat-cache and cache-manager were among those identified, meaning some developers could have encountered affected versions indirectly without installing them as top-level dependencies themselves.
The Malicious Releases Looked Like Normal Updates
One reason the campaign could easily slip past developers is that many compromised packages appeared as ordinary patch releases. Nothing about a small version bump would necessarily look suspicious during a routine dependency update.
Microsoft found, however, that numerous malicious releases had no matching source-code commit, pull request, release tag or other normal development activity. This strongly suggested that attackers were publishing altered package archives directly after gaining access to maintainer credentials rather than compromising every underlying source repository individually.
That distinction is important because developers often trust an npm release partly because it belongs to a familiar open-source project. In this case, the package name itself could still be legitimate while the newly published version was not.
The Attack Targets Developer And CI/CD Environments
Once an affected package was installed, the malicious code could execute during the normal package-installation process. From there, it attempted to determine whether it was running on an individual developer machine or inside a continuous integration environment.
CI/CD systems are especially attractive targets because build jobs frequently have access to credentials required for package publishing, source repositories, cloud platforms and other development infrastructure.
Microsoft says the malware searched compromised environments for credentials associated with services including npm, GitHub, cloud platforms, Kubernetes and secret-management systems. Stolen permissions could then give attackers access to additional repositories or packages, allowing the attack to move beyond the original infection.
That is what turns the incident from an ordinary malicious-package problem into a genuine supply-chain attack.
One Compromised Maintainer Could Affect Multiple Packages
A maintainer responsible for several npm packages represents an especially valuable target. If attackers obtain publishing privileges associated with that account, they may potentially tamper with more than one package.
Microsoft's investigation indicates that the campaign used compromised publishing credentials to create new malicious patch releases across packages accessible to affected accounts. This helps explain how hundreds of unrelated packages could eventually become involved in the same campaign.
The attack effectively exploited trust relationships already built into the open-source ecosystem. Developers trust maintainers, projects trust dependencies and automated build systems trust package registries. Once credentials inside that chain are compromised, the attack can propagate through those existing relationships.
Trusted Publishing Does Not Remove Every Risk
Modern npm security features such as trusted publishing and package provenance are designed to make releases safer by connecting a package publication with an authorised CI/CD workflow and its source environment.
Those protections remain extremely valuable, but the incident demonstrates an important limitation: a legitimate automated workflow can still be abused if the identity controlling that workflow has already been compromised.
Microsoft found cases where malicious releases could still appear to have valid provenance because they were published through an authorised workflow identity. In other words, provenance may confirm where a package came from, but organisations still need confidence that the workflow itself had not been taken over.
This is why software supply-chain security increasingly needs several independent layers rather than one trusted signal.
Transitive Dependencies Make Exposure Harder To Spot
Developers should also remember that npm projects rarely contain only the packages explicitly listed by the developer.
A project may install hundreds or even thousands of dependencies because those packages depend on other packages themselves. An affected release may therefore appear somewhere deep within the dependency tree without anyone deliberately selecting it.
That means checking only the project's top-level package.json is not necessarily enough. Microsoft recommends reviewing dependency trees, lockfiles, artifact repositories and CI caches for affected package versions.
Shared build environments deserve particular attention because cached dependencies can survive beyond the original job and potentially influence later builds.
Removing The Bad Package May Not Be Enough
If a malicious dependency already executed, simply downgrading or deleting it does not automatically return the environment to a trusted state.
The more important question becomes what the compromised process could access while it was running.
Microsoft recommends treating developer machines or build runners that executed affected packages with install-time scripts enabled as potentially compromised. Investigation may need to cover repository changes, package publishing history, cloud activity, secrets, build caches and software artifacts created while the environment was exposed.
Credentials available to the affected account should also be revoked and replaced from a known-clean system.
For higher-risk environments, rebuilding affected development machines, CI runners and trusted base images may be safer than trying to determine whether every possible trace has been removed.
Install Scripts Are Becoming A Bigger Security Concern
The incident also renews attention around npm lifecycle scripts.
These scripts exist for legitimate reasons and are commonly used during package installation, but they also give third-party dependencies an opportunity to execute code automatically as part of the installation process.
Newer npm tooling provides organisations with more control over which packages are permitted to run these scripts. For development teams managing sensitive repositories or CI pipelines, tightening those policies can significantly reduce exposure.
This reflects a broader security principle that is becoming increasingly important in software development: dependencies should not automatically receive more execution privileges than they actually need.
Waiting Before Adopting Brand-New Releases Can Help
Microsoft is also recommending that organisations become less aggressive about immediately installing newly published dependency versions.
A malicious package release often has its greatest opportunity shortly after publication, before maintainers, registries and security researchers have time to detect something unusual.
Features that enforce a minimum package age can create a short safety window before newly released versions enter production dependency trees.
That approach will not stop every supply-chain attack, but combined with version pinning, lockfile reviews and automated security scanning, it can make compromised releases harder to spread rapidly.
Software Supply-Chain Security Is Now A Credential Problem Too
Perhaps the biggest lesson from this incident is that package security is no longer only about inspecting source code.
Attackers increasingly target the identities and automation surrounding software development: maintainer accounts, CI/CD workflows, publishing permissions, cloud credentials and repository tokens.
A perfectly secure source repository does little good if someone steals credentials that allow them to publish a modified package directly.
Development teams therefore need to treat package publishing infrastructure with the same seriousness as production infrastructure. Strong authentication, limited token scopes, protected environments, approval controls and monitoring of unexpected publishing activity should all become standard practice.
Final Thoughts
The scale of this npm incident demonstrates just how quickly one compromised development identity can ripple through the modern software ecosystem.
More than 400 packages were reportedly affected, but the real danger extends beyond those package names. Compromised credentials can open paths into repositories, build systems, cloud services and additional packages, turning what begins as a dependency infection into a much broader supply-chain compromise.
For developers and organisations using npm, the lesson is not to stop trusting open source. It is to recognise that package provenance, dependency management, CI/CD security and developer identity protection all need to work together.
The days when updating a familiar package could automatically be considered low risk are increasingly behind us. In today's development environment, even a seemingly harmless patch release deserves to be part of a much stronger software supply-chain security strategy.
Comments 0