Jscrambler npm Package Compromised: A Security Vendor Becomes the Supply Chain Risk
Published July 12, 2026. Last updated July 15, 2026 with confirmed download figures, additional malicious versions, affected plugin packages, and indicators of compromise.
TL;DR
On July 11, 2026, attackers used a compromised npm publishing credential to push malicious versions of the jscrambler npm package, starting with 8.14.0. Even as Jscrambler responded to the incident, the attacker published four more poisoned versions: 8.16, 8.17, 8.18, and 8.20. The malicious releases were downloaded 1,479 times before they were deprecated.
Each version ships a preinstall hook that silently drops and runs a Rust infostealer on Windows, macOS, and Linux. The payload targets cloud credentials, CI tokens, browser sessions, crypto wallets, Bitwarden vaults, and the config files of AI coding tools like Claude Desktop and Cursor. Researchers observed the malware actively using stolen credentials to query cloud APIs, not just collecting them. The first clean version is 8.22.
The takeaway is uncomfortable but unavoidable: your security vendors are third-party software too. If a client-side security company’s own distribution channel can be hijacked, every installed component in your stack deserves the same scrutiny you apply to marketing tags.
What happened
| Fact | Detail |
|---|---|
| Package | jscrambler (npm), used with Jscrambler’s Code Integrity product |
| Malicious versions | 8.14.0, 8.16, 8.17, 8.18, 8.20 (Jscrambler advisory) |
| Affected dependents | jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2, jscrambler-metro-plugin 9.0.2 |
| First published | July 11, 2026, 16:12:40 BST |
| Attack vector | Compromised npm publishing credential; pushed outside the normal release flow |
| Payload | Cross-platform Rust infostealer executed via npm preinstall hook |
| Detection | Flagged by Socket six minutes after publication; Jscrambler alerted within seconds via maintainer notifications |
| Confirmed downloads | 1,479 downloads of the malicious versions before deprecation, per Jscrambler |
| Safe versions | 8.22 or later per Jscrambler’s advisory |
| Status | Malicious versions deprecated but still present on npm; investigation ongoing |
The compromised releases required no import and no CLI call. Installing one was enough. The preinstall script selected a native binary for the host OS, wrote it to the temp directory under a random name, and launched it detached with hidden output.
The added files existed only in the published npm packages. Researchers at StepSecurity and SafeDep confirmed there was no matching commit, tag, or pull request in the public GitHub repository.
One detail separates this incident from a routine account takeover: the attacker kept publishing new malicious versions while Jscrambler was actively responding. Versions 8.16 through 8.20 went live during the remediation window. That points to sustained access to the publishing pipeline, not a single stolen password used once.
Because the core package is a dependency for Jscrambler’s build plugins, the compromise also flowed downstream. Installs of the webpack, gulp, grunt, and Metro plugin versions listed above pulled the malicious core package in automatically.
What the malware steals
The payload is a purpose-built developer infostealer. Its target list maps directly onto what a build machine or CI runner can reach:
- Cloud credentials: AWS, Azure, and Google Cloud keys, including CI metadata endpoints
- Developer tokens: npm and GitHub credentials available to the install process
- AI tool configs: API keys and MCP server credentials from Claude Desktop, Cursor, Windsurf, VS Code, and Zed
- Password managers: Bitwarden vault data and OS keyrings
- Browser data: stored passwords and cookies
- Sessions: Discord, Slack, Telegram, and Steam
- Crypto wallets: MetaMask, Phantom, and Exodus seed phrases
It also goes beyond ordinary theft. The Linux build can load an eBPF program into the kernel from memory. The Windows and macOS builds include anti-debugging checks and persistence: a hidden scheduled task on Windows and a LaunchAgent on macOS.
Exfiltration runs over TLS to two hard-coded IP addresses, with Tor infrastructure also observed at runtime. Socket’s analysis found the malware doing more than exfiltrating: it constructed live requests to cloud and orchestration APIs using the credentials it had just stolen. Stolen keys were being used, not merely warehoused.
Why this incident matters more than its download count
The jscrambler package sees roughly 15,800 downloads a week. That is small compared to the npm mega-compromises of the past year. But raw reach was never the point.
Jscrambler is a build-time tool. It runs exactly where the most valuable secrets live: deploy tokens, cloud keys, signing credentials, and source code. A stealer planted in a security vendor’s build tooling is aimed at the highest-value environment an attacker can reach through npm.
Four points stand out:
- The victim is a security vendor. Jscrambler sells client-side protection and supply chain security. Its own npm distribution channel was the vector. No vendor category is exempt from supply chain risk, including the vendors you buy to manage it.
- The attacker outpaced the response. New malicious versions were published while remediation was underway. Fast detection did not equal fast containment, because the publishing pipeline itself remained in the attacker’s hands.
- The timing was deliberate-looking. npm 12 shipped on July 8 with install scripts disabled by default. This attack landed three days later, exploiting the long tail of older npm clients that still run preinstall hooks automatically.
- The malicious versions are still on npm. They were deprecated, not removed. Any lockfile pinned to an affected version on an older client keeps installing the stealer.
To Jscrambler’s credit, detection was fast and the company published a transparent advisory. Maintainer notifications triggered within seconds, the versions were deprecated, and credentials were rotated. Speed limited the blast radius. It did not eliminate the underlying exposure, and 1,479 installs still happened.
What to do now
If your organization uses the jscrambler npm package or its build plugins:
- Upgrade to version
8.22or later per the vendor advisory - Audit lockfiles, package-manager logs, and CI records for
jscramblerversions8.14.0,8.16,8.17,8.18, and8.20, plus the affected plugin versions, from July 11 onward - Assume theft, not exposure, if a compromised version ran: rotate cloud keys, npm and GitHub tokens, and AI tool and MCP API keys; revoke browser, Slack, Discord, and Bitwarden sessions. Researchers already observed the stolen credentials in active use
- Hunt for persistence: hidden Windows scheduled tasks and unfamiliar macOS LaunchAgents
- Block the C2 indicators listed below
For everyone else, the checklist is broader:
- Inventory every installed security agent, SDK, and build-time tool in your stack
- Disable npm install scripts by default (npm 12 does this out of the box)
- Treat vendor tooling with the same third-party risk process you apply to any script or tag
Indicators of compromise
Malicious package versions: jscrambler 8.14.0, 8.16, 8.17, 8.18, 8.20
File hashes (SHA-256), from the 8.14.0 release:
| File | SHA-256 |
|---|---|
dist/setup.js | a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60 |
dist/intro.js | a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86 |
| Linux payload | fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd |
| Windows payload | b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903 |
| macOS payload | c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd |
Network indicators (defanged):
- C2 IP:
37.27.122[.]124 - C2 IP:
57.128.246[.]79 - Tor infrastructure:
check.torproject[.]org,archive.torproject[.]org
On-host artifacts: a randomly named hidden file in the system temp directory (.{random}, or .{random}.exe on Windows), plus a hidden Windows scheduled task or a macOS LaunchAgent for persistence.
The bigger lesson: installed components are attack surface
Every tool you install, whether it is a marketing tag, an npm dependency, or a security product, inherits your trust and your access. This incident did not exploit a vulnerability in Jscrambler’s product. It exploited the distribution channel, which is the part customers can neither see nor control.
That is the structural argument for remote, zero-installation monitoring over embedded tooling. The two approaches carry fundamentally different supply chain profiles:
Embedded vs. remote: the supply chain difference
| Embedded approach | Remote approach (Reflectiz) | |
|---|---|---|
| Deployment | Agent, SDK, script, or npm package installed in your environment | Runs externally, zero installation |
| Supply chain exposure | Vendor’s publishing channel becomes part of your attack surface | No vendor code enters your environment |
| If the vendor is compromised | A malicious update executes with your access, in your build or on your pages | No path into your site or pipeline |
| Performance impact | Adds code to pages or build time | None |
| This incident’s relevance | Direct: a compromised package ran on install, and kept shipping through the vendor’s own remediation | Not applicable by design |
Reflectiz runs entirely outside your environment. Nothing is installed on your site, in your build pipeline, or on your infrastructure. There is no Reflectiz package in your lockfile, no agent on your servers, and no script on your pages. A compromise of Reflectiz’s own distribution channel cannot become a compromise of yours, because there is no distribution channel into your environment in the first place.
Embedded tools protect you until their supply chain fails. Remote monitoring has no supply chain into your site to fail.
The same continuous visibility applies to what already runs on your web assets: every third-party and fourth-party script, tag, and iframe is mapped, baselined, and monitored for behavioral change. When a trusted component starts doing something new, you know before your customers do.
FAQs
Can security vendors be a supply chain risk?
Yes. Any vendor whose product installs code, packages, or agents in your environment is part of your supply chain, and its distribution channel is part of your attack surface. This incident shows that even client-side security vendors can be compromised at the publishing layer, and that attackers can retain access through the vendor’s initial response. Externally operated, zero-installation tools remove this class of risk because no vendor code enters your environment.
Did npm 12 prevent this attack?
Partially. npm 12, released July 8, 2026, disables dependency install scripts by default, which blocks preinstall hooks like this one unless explicitly approved. However, older npm clients still run install scripts automatically, and the malicious versions remain on the registry for pinned builds. The 1,479 confirmed downloads show the protection was not universal.
How do I know if I installed the compromised version?
Check lockfiles and package-manager logs for jscrambler versions 8.14.0, 8.16, 8.17, 8.18, or 8.20, and for plugin versions jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2, and jscrambler-metro-plugin 9.0.2. Review CI logs from July 11, 2026 onward for execution of dist/setup.js. The dropped binary uses a random name in the temp directory, so correlate install timestamps with child processes and temp-directory execution rather than searching for a fixed filename.
How many times was the compromised jscrambler package downloaded?
Jscrambler reports that npm data shows the malicious versions were downloaded 1,479 times before they were deprecated and replaced with clean versions. The company is continuing to investigate the incident.
Is it safe to use Jscrambler now?
Jscrambler’s advisory states that versions 8.22 and later are safe and that the incident was limited to the jscrambler npm package used with Code Integrity. Other products, including Webpage Integrity, were not affected. The investigation is ongoing, so monitor the vendor advisory for updates.
Was the jscrambler npm package hacked?
Yes. On July 11, 2026, an attacker used a compromised npm publishing credential to publish malicious versions of the jscrambler npm package, starting with 8.14.0 and continuing with 8.16, 8.17, 8.18, and 8.20 even while the vendor responded. The releases contain a preinstall hook that installs a cross-platform infostealer. The malicious versions were downloaded 1,479 times before deprecation. Jscrambler rotated its publishing credentials and added controls around its release process.
What does the jscrambler malware do?
It runs automatically during npm install via a preinstall hook, drops a Rust infostealer built for Windows, macOS, and Linux, and steals cloud credentials, CI tokens, browser passwords and cookies, crypto wallets, Bitwarden vaults, messaging sessions, and AI coding tool configs including MCP server credentials. It adds persistence on Windows and macOS, can load eBPF programs on Linux, and was observed actively querying cloud APIs with the credentials it stole.
What is the difference between embedded and remote client-side security?
Embedded security tools install code in your environment: an agent, SDK, script, or npm package. They gain deep access but inherit supply chain risk, because a compromise of the vendor’s publishing channel executes inside your build or on your pages. Remote security tools like Reflectiz operate entirely outside your environment with zero installation, so a vendor-side compromise has no path into your site, build pipeline, or infrastructure.
Which jscrambler versions are malicious?
Versions 8.14.0, 8.16, 8.17, 8.18, and 8.20 of the core jscrambler npm package are malicious. Because the core package is a dependency, plugin versions jscrambler-webpack-plugin 8.6.2, gulp-jscrambler 8.6.2, grunt-jscrambler 8.5.2, and jscrambler-metro-plugin 9.0.2 also pulled in the compromised code. The first clean version is 8.22.
Subscribe to our newsletter
Stay updated with the latest news, articles, and insights from Reflectiz.
AI Has Changed The Web.
Are You Ready for What’s Next?
Third-party code shifts by the hour. Supply-chain compromises strike without warning. AI-driven web attacks now evolve faster than traditional security can ever keep up.
Reflectiz delivers the continuous, real-time visibility needed to expose the risks traditional tools miss entirely.
Zero code changes. Zero access to your data. Ultimate peace of mind.
