18 Malicious npm Packages Targeting Alibaba Tools: Supply Chain Analysis
Has anyone caught the report on the new supply chain attack hitting npm? Researchers found a batch of 18 malicious packages specifically aimed at users of Alibaba developer tools.
The standout here is the deployment of a cross-platform RAT, which is concerning because it isn't limited to a single OS. The attack vector is sophisticated—it appears to rely on dependency confusion. For instance, the package lib-mtop is unscoped but shares the exact name of a private Alibaba package. If a developer's internal registry configuration isn't airtight, they might accidentally pull the malicious public version.
Detection & Mitigation
If you're managing Node.js environments, immediate auditing is required. The payload is hidden in the install scripts, so static analysis of source code isn't enough; you have to check the lifecycle scripts.
Run an audit on your current dependencies:
npm audit
You should also explicitly scan for the known malicious package names in your `node_modules` or lockfiles. Here’s a quick grep check for the mentioned package:
grep -R "lib-mtop" package-lock.
Discussion
Dependency confusion is getting harder to spot with these private namespace collisions. How are you configuring your internal registries to prevent unscoped packages from overriding internal ones? Are you relying strictly on scopes like @alibaba/lib-mtop, or do you have other hardening measures in place?
Great breakdown. From a SOC perspective, the cross-platform nature is the biggest headache. It means the EDR alerts might look different depending on the build agent's OS.
We've started monitoring npm registry traffic directly. If you're using a proxy like Artifactory or Nexus, set up alerts for packages with high install script complexity or base64 encoded blobs in the manifest. It’s not perfect, but it catches a lot of these RAT droppers before they execute.
This is exactly why I enforce strict scopes in every .npmrc. Unscoped packages are the wild west.
For anyone auditing this, don't just look at package.. Check the preinstall and postinstall scripts in the actual tarball. I’ve seen similar attacks where the malicious code only runs if a specific environment variable (like CI=true) is present, to evade manual testing. Always run npm pack --dry-run to inspect scripts without executing.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access