jscrambler npm Attack: Compromised Releases Dropped Infostealer

Developers who installed jscrambler from npm on July 11 should check their lockfiles and build logs immediately. Security researchers found that several official jscrambler releases were compromised with a cross-platform Rust infostealer that could run on developer workstations and CI systems, giving the payload access to source code, environment variables, cloud credentials, browser data, wallet material, and other secrets available to the npm process.^[1]

The first flagged version was [email protected], published at 15:12 UTC on July 11. npm registry metadata reviewed by HowToFix shows that 8.14.0, 8.16.0, 8.17.0, and 8.20.0 are now marked as compromised or deprecated, while 8.22.0 is the current latest version. The same registry data also shows the risky nuance: 8.18.0 is still not deprecated, even though SafeDep and Socket both identify it as part of the malicious sequence.^[2]

Socket says the original malicious release added a preinstall hook that ran node dist/setup.js during package installation. That loader pulled a platform-specific native executable from dist/intro.js, dropped it under a random hidden name in the system temporary directory, marked it executable, and launched it detached. In practice, installing the package was enough; an application did not need to import the library for the first-wave payload to execute.^[1]

The campaign then changed shape. SafeDep’s timeline says 8.16.0 and 8.17.0 reused the install-hook dropper, but 8.18.0 and 8.20.0 moved the dropper into normal package code under dist/index.js and dist/bin/jscrambler.js. That matters because a scan limited to preinstall or postinstall scripts can miss the later versions, and npm install --ignore-scripts is not enough if a build later imports the module or runs the CLI.^[3]

A public GitHub issue opened by Socket’s threat research account reported the suspicious 8.14.0 release within minutes and noted that the package contained a roughly 7 MB executable payload with no matching activity in the public repository. The Hacker News later reported the same source-repository mismatch and described the incident as likely tied to an npm account or publishing-pipeline compromise rather than a normal source commit.^[4]

This is the same class of developer-supply-chain risk HowToFix recently covered in the Injective SDK npm compromise, the TeamPCP developer-tool campaign, and the PolinRider package attack. The uncomfortable part is that cleanup by a maintainer does not undo any execution that already happened on a workstation, build runner, container image, or cached CI environment.

What jscrambler users should check now

Start with dependency evidence. Search package-lock.json, pnpm-lock.yaml, yarn.lock, build manifests, CI logs, artifact caches, and container layers for [email protected], 8.16.0, 8.17.0, 8.18.0, or 8.20.0. If any of those versions were installed or executed, treat the affected machine or runner as compromised, not merely as “using a bad package.”

Upgrade or pin to a verified clean release, with 8.22.0 currently listed as npm’s latest. Rebuild from a clean dependency cache rather than trusting an existing node_modules tree. For the install-hook versions, look for execution of dist/setup.js; for 8.18.0 and 8.20.0, review any build or application step that required the module or invoked the Jscrambler CLI.

Then rotate secrets that may have been reachable from the affected context: npm tokens, GitHub and CI tokens, cloud keys, deployment credentials, Slack or chat tokens, browser-stored credentials, and wallet material. Socket’s analysis says the payload targeted developer and cloud-operator environments, including cloud metadata, browser profiles, crypto wallets, AI coding assistant and MCP configuration files, messaging apps, and local persistence mechanisms.^[1]

Finally, inspect host persistence. SafeDep lists hidden temporary-file artifacts, Windows scheduled tasks, and macOS LaunchAgents among the indicators. On Linux or CI runners, line up npm install timestamps with unexpected child processes, hidden files under temp directories, outbound TLS connections, and any new systemd or cron entries. The absence of an install script in a lockfile is not a clean bill of health for this incident.

References

1. Socket Research Team. “jscrambler npm Package Compromised in Supply Chain Attack.” Socket, July 11, 2026. https://socket.dev/blog/jscrambler-supply-chain-attack
2. npm registry metadata for jscrambler, reviewed by HowToFix on July 12, 2026. https://www.npmjs.com/package/jscrambler
3. SafeDep Team. “Official jscrambler npm Package Compromised Across Multiple Releases.” SafeDep, July 11, 2026. https://safedep.io/jscrambler-npm-supply-chain-compromise/
4. Socket Threat Research Team. “v8.14.0 compromised?” GitHub issue #322, July 11, 2026. https://github.com/jscrambler/jscrambler/issues/322
5. Swati Khandelwal. “Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install.” The Hacker News, July 11, 2026. https://thehackernews.com/2026/07/compromised-jscrambler-8140-npm-release.html