@injectivelabs/sdk-ts npm supply-chain compromise (2026)

npm supply-chain wave status: jscrambler package compromised this week, extending the install-hook-evasion pattern seen in the injectivelabs SDK

The software-supply-chain pressure on the npm ecosystem that this pipeline has tracked as a sustained wave continued this week, with a fresh compromise that sharpens the evasion trend rather than repeating it.

On 2026-07-11 the jscrambler npm package — a code-protection/obfuscation build tool — was compromised via what Socket assesses as a stolen publishing credential or compromised build pipeline: a malicious v8.14.0 pushed directly to npm, bypassing the project's normal release flow, adding an undocumented preinstall hook that unpacks and detached-spawns a platform-specific Rust infostealer on npm install alone. The stealer targets cloud metadata-endpoint credentials, Kubernetes configs, browser secrets, crypto-wallet seeds, AI coding-tool configs and messaging tokens. The notable evolution: over roughly three hours the actor pushed four more malicious releases and, "starting with 8.18.0 the install hook is gone entirely—the identical dropper is instead injected as a self-executing function at the top of dist/index.js" — moving execution out of the very hook that install-script scanners watch (Socket, 2026-07-11). Socket "detected the compromised package 6 minutes after publication"; v8.22.0 is confirmed clean (The Hacker News, 2026-07-11). This is the same install-hook-evasion arc as this week's injectivelabs SDK compromise, though — unlike the Shai-Hulud worm strain — jscrambler has not been shown to self-propagate to other maintainers.

Builds on: 2026-07-10/injectivelabs-npm-runtime-keyhook-supply-chain-evasion · 2026-06-29/npm-supply-chain-worms-a-sustained-wave-across-the-week

npm supply-chain payload hides as runtime 'telemetry' with no install hook — defeating install-time dependency scanners

Aikido Security published (2026-07-09) a teardown of a compromised npm release of @injectivelabs/sdk-ts — an SDK pulling ~50,000 weekly downloads — that is notable less for its payload's purpose than for how it hid (Aikido Security, 2026-07-09). Introduced via what Aikido assesses as a GitHub account takeover (commits from an account with an established history), the malicious version was live for under an hour on 2026-06-08 before the maintainer reverted it, but in that window the attacker also republished the same version number across 17 other packages in the scope, each pinning the poisoned SDK — so any project depending on one of them resolved the stealer transitively without naming it directly.

The payload runs no install-time script. Diffed against the clean build, the artifacts differ by one injected block and two one-line hooks placed inside the SDK's own key-derivation entry points; each hook "fires before the real derivation runs, so the secret is captured on every legitimate call" during normal application use (Aikido, 2026-07-09). Because "the trigger is key derivation at runtime and not a lifecycle script, install-time scanners and sandboxes that only watch postinstall see a clean package" — the single most important detail for defenders, since it defeats the exact control (install-hook / postinstall inspection) that most software-composition-analysis programmes lean on. The exfiltration was built to blend in: the destination host was stored as an array of character codes and reassembled at runtime to defeat plaintext string search, the captured material was base64-batched and sent inside an HTTP request header (not the body) with a content type matching the SDK's own gRPC-web API calls, and every failure path swallowed errors silently. The injected block was even documented in its own comment as "anonymized usage metrics for SDK optimization".