Two attacks, four days apart
The npm registry absorbed two distinct supply-chain compromises inside a single week in July 2026. On July 11, attackers published malicious versions of jscrambler, a JavaScript obfuscation tool pulling roughly 15,800 weekly downloads. Socket detected the tampering six minutes after publication, but the operators pushed four additional poisoned versions over the next three hours, including 8.16.0 through 8.20.0, before a clean 8.22.0 restored trust. Six minutes is fast detection by any standard, and it still was not fast enough to spare every automated build that ran during the window.
Then on July 14, Microsoft Threat Intelligence identified a coordinated compromise of the @asyncapi npm organization, affecting five versions across four packages including @asyncapi/generator and @asyncapi/specs. The two incidents used different entry techniques, and they rhymed all the same. Both abused the trust developers place in the registry, both moved to auto-publish through legitimate release machinery, and both hunted the same prize: the secrets sitting on developer machines and inside CI/CD pipelines. Seeing two unrelated projects fall in one week underlines that this is a campaign against the ecosystem rather than a run of bad luck for two maintainers.
jscrambler: stolen credentials, a preinstall hook
The jscrambler attack followed the classic playbook. Jscrambler confirmed the attacker published the package using a valid npm publishing credential, then added an undocumented preinstall hook that invoked dist/setup.js to deploy platform-specific binaries. The malware targeted cryptocurrency wallets including MetaMask and Phantom, cloud credentials across AWS Secrets Manager and SSM Parameter Store, GCP Secret Manager, and the Azure IMDS endpoint, plus developer tools including Claude Desktop, Cursor, and Windsurf. The breadth of that target list shows how much sensitive material now lives on a typical developer workstation, from blockchain keys to production cloud access to AI-assistant tokens, all reachable by a single poisoned install.
Socket researchers recovered roughly 2,400 encrypted configuration strings protected with per-string ChaCha20-Poly1305, mapping the campaign's full targeting surface. The inclusion of AI coding assistants in the target list is a notable evolution, since those tools increasingly hold API keys and repository access. Jscrambler revoked the compromised publishing credential and rotated related secrets, but the six-minute detection window still left downstream builds exposed during the interval before the malicious versions were pulled.
AsyncAPI: a CI/CD misconfiguration did the work
The AsyncAPI compromise is the more instructive of the two because no credential was phished or stolen. Microsoft traced it to a malicious pull request, PR #2155, submitted around 05:08 UTC on July 14. A GitHub Actions workflow using pull_request_target checked out the untrusted head commit of that PR, which handed attacker-controlled code access to the privileged asyncapi-bot personal access token. With that token, the attacker pushed to auto-publish branches and shipped malicious packages through the project's own legitimate release pipeline.
The pull_request_target trigger is a well-known GitHub Actions footgun, and it keeps catching maintainers because it runs with elevated permissions in the context of the base repository while checking out untrusted fork code. The timeline was fast: the first three packages republished around 07:10 UTC, and downstream consumers were observed pulling the tainted versions by 08:49. A single misconfigured workflow was enough to turn a trusted open-source project into a malware distribution channel.
Why ignore-scripts did not save anyone
The AsyncAPI payload broke a defensive assumption many teams rely on. Microsoft found the malicious code, which it tracks as Miasma, executed at module-load time, meaning at import or require rather than during installation. The common mitigation of running npm install with the ignore-scripts flag blocks postinstall hooks, so it does nothing against a payload that fires when the code is first imported at runtime or build time. Teams that adopted ignore-scripts after last year's wave of postinstall attacks may believe they closed this class of risk, and this campaign quietly demonstrates that they did not. The execution simply moved to a trigger the flag never covered.
That distinction matters for anyone who has told themselves ignore-scripts is a sufficient guardrail. Miasma reached for more than 100 environment variables, including GITHUB_TOKEN, NPM_TOKEN, AWS credentials, and Azure secrets, plus files like .npmrc, .aws/credentials, and kubeconfig. A build agent that imports a poisoned package will surrender whatever secrets its environment holds. The uncomfortable conclusion is that dependency execution during a build is inherently dangerous, and script-blocking flags address only part of the exposure.
The registry is the shared weak point
Palo Alto Unit 42 and others have been tracking a sustained rise in npm supply-chain attacks through 2026, and npm itself is shipping a v12 release designed to block install scripts by default in response. That is a meaningful hardening step for postinstall-style attacks. It would not have stopped AsyncAPI, though, which is precisely why registry-level fixes cannot be the whole answer. The attack surface spans publishing credentials, CI/CD workflow permissions, and runtime import behavior all at once.
For enterprise engineering leaders, the pattern relocates the perimeter into the dependency graph and the build pipeline itself. Two independent teams, jscrambler and AsyncAPI, both got compromised in one week through completely different weaknesses, which tells you the systemic exposure is broad rather than a fluke of one sloppy maintainer. Any organization pulling from npm at scale sits one poisoned transitive dependency away from a secrets breach, and the incident rate now justifies treating that as an operational certainty. The registry has become load-bearing infrastructure that no single company controls, and the security model has not caught up to that reality.
What to actually change this quarter
The mitigations are concrete and mostly boring, which is the good news. Scope publishing tokens tightly and require hardware-backed multi-factor on npm accounts to blunt credential theft. Audit every GitHub Actions workflow for pull_request_target usage and strip write permissions and secret access from any job that checks out untrusted PR code. Enable npm package provenance and enforce it in your install policy so unsigned or unexpected publishers get rejected before they reach a build.
Beyond the registry-specific steps, the durable fix is isolating the build environment. CI/CD runners should hold the minimum secrets required, use short-lived credentials, and run in ephemeral, network-restricted sandboxes so a rogue import cannot exfiltrate long-lived keys or reach production. Pinning dependencies by hash and gating updates through a review queue slows down auto-propagation of the kind that spread both of these attacks. None of this is novel, and that is the point: the fundamentals were sufficient, and most shops have not finished implementing them.
