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".