A new npm supply chain attack has turned trusted software packages into a route for credential theft.
The campaign began after attackers compromised the maintainer account behind the widely used Keyv library, then used that access to push malicious releases across a growing number of projects.
The incident matters because npm packages are routinely installed automatically during development and build work.
A poisoned dependency can therefore reach laptops, servers, and automated pipelines without an employee ever visiting a suspicious website or opening a malicious attachment.
Microsoft and Socket identified the activity as an active Mini Shai-Hulud campaign, a self-spreading malware operation built to steal access tokens and reuse them.
Microsoft and Socket said in reports shared with Cyber Security News (CSN) that the attackers appeared to be using multiple stolen publishing tokens.
The scale expanded quickly. Socket reported 2,234 affected package artifacts across 444 unique packages while the activity was still spreading, showing how a single compromised maintainer can create a broad downstream risk for teams worldwide that rely on open-source code.
New npm Supply Chain Attack Began
The attack started with a compromise of the trusted account associated with Keyv, a commonly used key-value storage library.
Once the attackers gained publishing access, they could release altered packages that looked like ordinary updates and were available through the normal npm installation process.
That initial foothold gave the campaign an unusually large audience. Keyv has a substantial weekly download base, so its compromise placed a familiar dependency at the center of a wider incident and renewed concern over Keyv package compromise details, where trusted update channels become the delivery path.
The malicious releases use an install-time instruction to begin the attack before a developer can use the package.
Instead of stopping at one machine, the malware searches for credentials that can let it publish altered releases from other maintainers, producing a chain reaction across the registry.
This behavior makes the incident different from a simple one-off package poisoning.
The threat is designed to move through software publishing relationships, meaning each stolen token can open another path to developers, build systems, and organizations that depend on those packages.
The campaign also fits a troubling pattern seen in recent npm credential theft campaigns. In those attacks, criminal operators focus on the accounts and automation that publish code, knowing that one legitimate account can be more useful than a large volume of fake packages.
Stolen Tokens Fuel Wider Risk
After it runs, the malware hunts for credentials connected to npm, code-hosting accounts, cloud services, and continuous integration systems.
These secrets can provide access far beyond the affected project, particularly where a build system has permission to publish packages or deploy software.
The stolen information is sent out of the victim environment, after which publishing access is used to alter package archives, raise their version numbers, and release them again.
That automated loop helps explain why analysts saw the number of affected artifacts climb so fast.
Teams should treat any installation of a listed malicious release as a potential credential exposure, not merely a bad dependency update.
They should remove affected versions, rebuild dependency lockfiles from trusted information, and review recent package changes before allowing automated deployments to continue.
Credential rotation is equally important. npm tokens, code-hosting access tokens, cloud keys, and continuous integration secrets available on impacted hosts should be revoked and replaced, while maintainers should check repositories and publishing histories for unexpected releases or workflow edits.
Organizations can reduce future exposure by requiring multi-factor authentication for publishing accounts, using short-lived and narrowly scoped automation credentials, and separating build permissions from release permissions.
Monitoring unusual package versions and unexpected install behavior can also help catch a recurrence earlier.
For added context, readers can review coverage of the Mini Shai-Hulud attack wave and software supply chain defenses.
The immediate lesson is straightforward: trust in a package name is not enough in everyday production work when a maintainer account or its publishing token has been compromised.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| Compromised npm package | keyv@6.0.0 | Confirmed malicious package release |
| Compromised npm package | file-entry-cache@11.1.6 | Confirmed malicious package release |
| Compromised npm package | cache-manager@7.2.10 | Confirmed malicious package release |
| Compromised npm package | cacheable-request@13.0.20 | Confirmed malicious package release |
| Compromised npm package | qlik/api@2.14.2 | Confirmed malicious package release |
| Compromised npm package | cacheable/memory | Affected package identified in the campaign |
| Compromised npm package | cacheable/utils | Affected package identified in the campaign |
| Compromised npm package | cacheable/net | Affected package identified in the campaign |
| Compromised package scope | servicetitan/* | More than 17 affected packages, including eslint-config, anvil-themes, table, form, and log-service |
| Malicious file | setup.mjs | Obfuscated dropper launched through the malicious preinstall hook |
| Malicious file | Math_Symbol.js | Credential-stealing payload |
| Malicious file | Math_Init.js | Credential-stealing payload |
| Detection name | Trojan:npm/MalBun.A | Microsoft Defender for Endpoint detection name |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world
