@torbeck/heapnpm
Malicious code in @torbeck/heap (npm) Remove it immediately and rotate any exposed credentials.
What this malware does
@torbeck/heap impersonates the legitimate @datastructures-js/heap package: README.md line 1 reads # @datastructures-js/heap, package.json sets homepage/repository/bugs to github.com/datastructures-js/heap and author to Eyas Ranjous <[email protected]>, while the npm scope @torbeck is unrelated. The package re-exports the genuine Heap class so consumers get a working API. Appended to src/heap.js after exports.Heap = Heap; (around line 247) is a heavily obfuscated obfuscator.io payload (two rotated string-array RC4-style decoders, ~580 and ~700 entries, with Function.toString anti-tamper traps and console-method override checks). On require('@torbeck/heap') via the package's index.js main entry, the payload derives an AES key by XORing four hardcoded buffers, decrypts a hidden URL, issues an http/https.request to download a binary into os.tmpdir(), writes a PID lock and.meta.json with a sha256, chmods the file to 0755, and spawns it detached via process.execPath or bash -c with stdio:'ignore', windowsHide:true, and unref() — plus a re-exec wrapper that respawns the parent under a sentinel. Platform-specific branches handle win/linux/mac. There is no version pinning or signature check on the downloaded bytes, the URL is concealed by obfuscation, and the dropped binary's purpose is unrelated to a heap data-structure library. This is a typosquat carrying an install/require-time RCE dropper.
Malicious versions
Indicators of compromise (SHA-256)
Detection & response playbook
TyposquatFind it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @torbeck/heap (3 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @torbeck/heap across your stack and pipelines.
If you installed it — respond
@torbeck/heap is a typosquat — you almost certainly intended a legitimately-named package. Remove @torbeck/heap, install the correct package, and rotate any secrets exposed during the install since post-install scripts may have already run.
Did it already run?
If @torbeck/heap was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @torbeck/heap before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.
Frequently asked questions
Campaign
References
Credits
- Amazon Inspector · finder
Detect & block this
O3 blocks @torbeck/heap-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the malicious outbound activity and severs the channel.