An attacker hijacked Jscrambler's npm package with a stolen publishing credential and shipped an infostealer to developers between 11 and 13 July 2026. The malware harvested cloud tokens, wallets and AI-assistant credentials from any machine that installed it. For third-party risk teams, the lesson is that a trusted dependency is a supplier, and its release channel can become the attack path.
An attacker took over the npm package of Jscrambler, a company that sells JavaScript code-protection tooling, and used it to ship malware to the developers who trust it. Between 11 and 13 July 2026 the security firm Socket found five malicious releases of the popular jscrambler package (npm is the main registry for JavaScript code). Each dropped a hidden program that steals secrets from the machine it lands on. Anyone whose workstation or build system installed an affected version may have leaked cloud tokens, source-code access and more. Jscrambler confirmed the packages were published with a stolen credential of its own. The lesson: a supplier you trust to protect your code can become the route the attack takes in.
What happened
Socket reported the compromise on 11 July 2026 and updated it on 13 July 2026, and Jscrambler published a security advisory confirming the incident. On 11 July an attacker published a malicious version of the jscrambler package (8.14.0), followed by four more (8.16.0, 8.17.0, 8.18.0 and 8.20.0) over several hours. Jscrambler said the attacker was able to publish using one of the company's npm publishing credentials (the key that lets a maintainer release a package). The package draws about 15,800 downloads a week. The malicious releases dropped a Rust infostealer (a background program that harvests secrets) built for Linux, macOS and Windows. Early versions ran it through a preinstall hook, meaning it fired automatically on install. Later versions moved the code into the package files so it ran when the package was imported, a change Socket describes as evading scanners that only check install scripts. The payload targeted cloud credentials (Amazon, Google and Microsoft), cryptocurrency wallets, messaging apps, browser data, and, notably, the configuration files of AI coding assistants and their connected tools, which often hold API keys. Socket flagged the first release six minutes after publication. Jscrambler revoked and rotated the credential, deprecated the affected releases, and released a clean version (8.22.0). The number of machines that installed a bad version is not confirmed.
Why it matters for third-party risk
This is the trusted-dependency pattern, and a sharp version of it. The victim was not a typosquat or a look-alike name a developer might catch. It was the real package from a security vendor, hijacked at the source. Every open-source component a build pulls in is a supplier, and this supplier's release channel was the weak link. The exposure does not stop at one laptop. Stolen build tokens, cloud keys and repository access reach the systems and customers downstream of any affected pipeline. The targeting of AI-assistant and connected-tool configuration is the new edge: those files increasingly hold live credentials, so the developer supply chain now includes the secrets sitting inside developer tooling.
What teams should take from it
Treat your dependency registry as a supplier estate, not a free shelf. Pin exact versions, review changes before they enter a build, and prefer releases that have aged rather than installing the newest tag automatically. Then assume any secret that ever reached a build environment is reachable: rotate the cloud, repository and AI-tool credentials on any machine that installed an affected version, and check that AI-assistant configuration files are not storing long-lived keys in the clear.
For teams mapping which of their software suppliers could carry this kind of risk, see how continuous vendor and dependency monitoring works.
FAQ
Was Jscrambler's own product breached?
Jscrambler confirmed its npm package was published without authorisation using a stolen publishing credential. The company said it rotated the credential and related secrets and added controls around publishing. The scope of any wider access is not detailed in the advisory.
Which versions are affected, and which are safe?
Socket lists 8.14.0, 8.16.0, 8.17.0, 8.18.0 and 8.20.0 as malicious. Version 8.13.0 (before the hijack) and 8.22.0 (the fix) are described as clean. Teams should move to 8.22.0 and audit any machine that installed one of the bad versions.
What should a team do if it installed a bad version?
Rotate every credential reachable from the affected workstation or build system, including cloud keys, repository tokens and any API keys stored in AI-assistant configuration files. Search dependency trees and continuous-integration logs for the affected versions, and treat exposed secrets as compromised rather than waiting for proof.
Want this applied to your supplier ecosystem? See the platform in action and map your top vendor risks live in one walkthrough.
