Jscrambler's own npm package backdoored for two hours

There is something particularly awkward about a company that sells code protection watching its own package get backdoored. That is exactly what happened to Jscrambler over the weekend, when an attacker used compromised npm publishing credentials to push a malicious version of the firm's package to the registry.

The tainted releases (versions 8.14, 8.16, 8.17 and 8.20) ran an infostealer during the preinstall hook. That detail matters: developers did not even have to import the code for it to fire. Simply pulling the package was enough. It sat on npm for roughly two hours before Jscrambler noticed, deprecated the affected versions, and shipped a clean 8.22. In that short window, npm logged 1,479 downloads.

An unusual amount of care for a two-hour job

Researchers at Socket picked apart the payload and found it wrapped in ChaCha20-Poly1305 string encryption, which is a curious level of tradecraft for what turned out to be a smash-and-grab. The malware went after credentials and other developer secrets, hunting the sort of tokens and keys a build machine tends to have lying around.

The blast radius was also wider than the single library suggests. Jscrambler's package is a dependency for four of its other packages, so anyone who pulled those in the affected window inherited the same problem without ever installing the compromised library directly.

Compromised credentials, again

Jscrambler says the root cause was compromised npm publishing credentials. Those have since been revoked, and the company says it has added further controls to the publishing pipeline. What those controls are, and whether they include the kind of protections most maintainers would consider basic (mandatory 2FA on publish, provenance signing, restricted tokens), is not spelled out in the disclosure.

For anyone who pulled one of the affected versions, a clean reinstall is not enough. The right assumption is that the environment is dirty. That means:

• Rotate every secret the affected machine touched: npm tokens, cloud keys, git credentials, CI secrets, SSH keys.
• Rebuild from a known-good backup rather than trying to scrub the current state.
• Audit downstream anywhere those secrets were used, because the attacker had a two-hour head start.

The uncomfortable bit

Supply chain attacks on npm are no longer unusual. What makes this one land is the identity of the victim. Jscrambler exists to protect code. If a vendor in that business can lose a publishing token, so can anyone.

The wider point is one the ecosystem keeps re-learning. The trust developers place in a package name is really trust in whoever holds the publishing token. When that token goes, so does the vendor's reputation, at least until the incident report is out and the postmortem lands. Two hours is a short window on the calendar. It is a very long window when the code inside is stealing everything a build machine can see.