An attacker gained access to jscrambler’s npm publishing credentials and pushed five malicious versions of the widely used JavaScript obfuscation package over approximately three hours, each containing a preinstall hook that drops and executes a cross-platform Rust infostealer. The payload targets AWS, Azure, and Google Cloud credentials alongside cryptocurrency wallets, browser sessions, and configuration files for AI coding tools including Claude Desktop, Cursor, Windsurf, VS Code, and Zed — an explicit adaptation to the new generation of AI API keys and session tokens on developer workstations.
Five Malicious jscrambler Versions and the Rust Infostealer Payload
The attacker published five malicious versions in sequence: 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0. Version 8.15.0, published between the first and second malicious releases, remained clean, indicating the attacker did not have uninterrupted control over the package during the window. The safe upgrade path identified after the incident is version 8.22.0. Jscrambler is a commercial tool used in web development pipelines for JavaScript obfuscation and code protection, making its npm package a dependency in many production build processes.
AWS, MetaMask, Bitwarden, and AI Coding Tool Configs Targeted by the Infostealer
Each malicious version includes a preinstall hook — a script that npm executes automatically when the package is installed — that drops and runs a Rust infostealer binary with builds for Windows, macOS, and Linux. The infostealer targets a broad credential surface: AWS, Azure, and Google Cloud credentials; seed phrases for MetaMask, Phantom, and Exodus cryptocurrency wallets; Bitwarden vault data; browser-stored passwords and cookies; Discord, Slack, Telegram, and Steam session tokens; and configuration files for Claude Desktop, Cursor, Windsurf, VS Code, and Zed. The explicit inclusion of AI coding tool configuration files reflects that threat actors have specifically adapted infostealers to target the API keys and session tokens that AI development environments store locally on developer machines.
The root cause was a compromised npm publishing credential. No matching commit, tag, or pull request appeared in jscrambler’s GitHub repository for any of the five malicious versions, meaning the packages were published directly to npm without going through the project’s normal source control workflow — a signal that should have flagged the releases to any monitoring system watching for that discrepancy.
Socket’s Six-Minute Detection and jscrambler’s Zero Confirmed Download Count
Socket, a supply chain security firm, detected version 8.14.0 six minutes after it was published and flagged all five malicious versions. Jscrambler deprecated the malicious releases and reported zero confirmed downloads, though the company noted that npm download counts lag by hours and the figure was still being verified at the time of disclosure. The six-minute detection window is fast by supply chain monitoring standards but still represents time during which any developer running an automated install in a CI/CD pipeline could have fetched and executed the malicious package without any warning.
How a Security Vendor’s Own npm Package Became a Supply Chain Attack Vector
The choice of jscrambler’s npm package as the attack vehicle is significant. Jscrambler is itself a security-oriented product — a JavaScript obfuscation tool marketed to developers who want to protect their code. Developers and security teams who use jscrambler may extend more implicit trust to its dependencies than they would to an unfamiliar package. A compromised npm publishing credential bypasses code review, signing, and repository workflow controls entirely: the attacker does not need to compromise the codebase or the build pipeline, only the credential that authorizes publishing to npm.
No Commit or Tag in GitHub Repository: The Detection Gap the Attack Exploited
The absence of a matching GitHub commit or tag for the five malicious versions exposes a common security gap in npm package monitoring. Many organizations audit their direct dependencies by reviewing source repositories but do not independently verify that what was published to npm matches the repository’s source tree. An attacker with only a publishing credential — not repository access — can publish malicious versions to npm that are invisible to anyone relying solely on GitHub to monitor a package’s integrity. Supply chain monitoring tools that watch npm itself, rather than only the upstream repository, are required to catch this class of attack.
Jscrambler’s own investigation confirmed no corresponding source control activity for the malicious versions. Organizations that ran npm install or npm ci during the roughly three-hour window should audit their developer workstations for infostealer activity and rotate any credentials that were accessible from the affected machines.
