Jscrambler: four npm versions hit, publish creds revoked
Jscrambler's post-incident report widens its July 11 npm compromise from one release to four (8.14, 8.16, 8.17, 8.20). 8.22 clean; publish creds revoked.
Loop The vendor’s own disclosure,
posted July 13 and picked up by BleepingComputer the same day, widens
the picture from what Socket caught on July 11.
The malicious release was not one version. It was four: jscrambler
8.14, 8.16, 8.17, and 8.20 on the npm registry, all pushed by an
attacker in possession of Jscrambler’s npm publishing credentials. The
next clean version is 8.22. Four dependent packages that resolved
against those malicious releases were deprecated and republished under
new versions in the same window.
The root cause the vendor states is the plain one — a compromised
credential on the account that has publish rights to the package. Not
a build-system takeover, not a maintainer social-engineering chain into
a co-maintainer, not a phishing kit against a dependency. A token
belonging to an account with publish on jscrambler was, at some
point, in someone else’s hands. Everything after that is a straight
npm publish. Jscrambler says the credential has been revoked and
that publishing-pipeline controls have been tightened; the internal
detail of how the credential left is not in the public disclosure yet.
The window
The compromised versions were live for about two hours before
deprecation and the clean 8.22 push. Downloads during that window:
1,479. That number is not “roughly 1,500 people typed npm install jscrambler” — the download counter includes CI systems that ran a
fresh install against latest, cache backfills against dependent
packages, and anyone who pinned to a specific bad version during the
window. It is a proxy for exposure, not a headcount.
If any environment ran npm install against jscrambler or against
a package that depends on it during the window between the first bad
push and the 8.22 clean push, treat the host as inside the blast
radius. The preinstall hook does not need import, invocation, or
opt-in — it runs during install unless --ignore-scripts is set.
What the payload takes
The infostealer’s targeting has not narrowed since the July 11
Socket writeup.
The vendor’s own report lists source code, cloud provider credentials
for AWS, Azure, and GCP, cryptocurrency wallets, browser session and
cookie data, and messaging-platform tokens as the classes it walks
for on the host. Encryption of the exfil channel is
ChaCha20-Poly1305; that is a detail about the malware’s own
transport, not about how it enters the host. The entry is still the
preinstall hook.
The practical rotation list on a suspected-compromised developer or CI host is unchanged from what Fuse laid out on July 11: long-lived cloud keys, browser cookies for anything the user was signed into on that host, wallet seed phrases (if the wallet software’s local files were touched), and any messaging-platform tokens the OS keychain had at the time. Do it from a clean host, not from the one you are cleaning.
Publish credentials as infrastructure
The pattern here is not new. What is worth pausing on is the shape of
it. A credential with publish on a package used as a dependency by
other packages is not just a maintainer’s password — it is a piece
of the delivery infrastructure that carries code into every install
of every downstream project. The registry treats a legitimate token
and a stolen one the same way. There is no re-authentication in the
publish path that could catch “the token is legitimate, but the
publisher isn’t.” The token IS the publisher.
npm has been moving the ecosystem toward tighter publish-credential
posture:
granular access tokens with per-package scopes and expiries, OIDC
trusted publishing from CI so long-lived tokens can be removed from
laptops entirely, and the 12.x default that turns install scripts
off unless a package opts in. Any one of those, in place at
Jscrambler, would have shortened one leg of the incident chain. The
OIDC change removes the “long-lived token on a laptop” step. The
scoped-token change limits blast radius when a token does leak. The
install-scripts default disarms the preinstall trigger in every
downstream install that has upgraded to npm 12 with default
settings, whether or not the upstream is compromised. None of these
were in place across the affected chain here. The credential was
long-lived, publish rights were unscoped in the sense that mattered,
and every downstream install with preinstall scripts on ran the
payload.
The publish credential is now revoked. The clean release is 8.22. The remediation the vendor recommends for anyone who installed during the window is a full environment credential rotation and a restore from a known-clean backup, which is the correct advice for a preinstall-hook infostealer regardless of vendor branding.
Related coverage:
- jscrambler 8.14.0 npm hijack: Rust stealer on install — Socket’s July 11 detection and the initial payload analysis
- npm 12 turns install scripts off by default — the ecosystem-level change that would disarm preinstall triggers by default
- Injective SDK 1.20.21 on npm shipped a wallet stealer — recent adjacent npm-credential compromise
- JFrog: rollup-polyfill and six other npm packages — the pattern viewed across seven packages last week
Sourcing
- Jscrambler vendor disclosure, via BleepingComputer, 2026-07-13
- Original Socket detection, via The Hacker News, 2026-07-11
- npm registry entry:
jscrambleron npm
Found this useful? Share it.
