Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Malicious package

@frostnode/waitfornpm

Malicious code in @frostnode/waitfor (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-6305
Immediate action
Remove the package, then rotate any secrets the build/runtime could reach.
npm uninstall @frostnode/waitfor

What this malware does

@frostnode/waitfor (malicious versions 0.9.0, 0.10.3, 0.10.4, and 0.10.5, published by [email protected]) is a trojanized npm package belonging to the wshu.net credential-stealer campaign. The campaign published trojanized look-alike utility packages across 12+ scopes whose publisher accounts all follow the pattern <scope>-<6 random chars>@wshu.net, with every scope created on June 4, 2026 in a ~40-minute burst. This package masquerades as a wait/delay utility and ships real, working utility code so it passes a glance, while bundling a much larger malicious payload (lib/tickinit.js in the earliest variant, dist/cjs/tickinit.cjs thereafter). package.json declares a postinstall hook (e.g. "node ./dist/cjs/tickinit.cjs") that runs the payload automatically on npm install. The payload is heavily obfuscated with javascript-obfuscator (hex-named identifiers, a while (!![]) array-rotation IIFE, base64+RC4 string decoding, control-flow flattening, and runtime-decrypted module resolution to stay out of the static module graph). At runtime it is a Chromium browser credential stealer: it reads Chromium Cookies and Login Data and decrypts saved passwords protected by AES-256-GCM (the v10/v11 app-bound key schemes), then exfiltrates them over HTTPS using a spoofed Mozilla/5.0 user agent. Consistent with the campaign, the dangerous versions sit in mid-ranges while the latest tag (0.10.6) points to a scrubbed release with an empty scripts block. Malicious payload dist/cjs/tickinit.cjs (0.10.5) SHA-256: 2de602e6422a991346aaf0b74ed6bd525215f5177b9f7f267ccb4d82e919273d.

Package is published under scope @frostnode but its package.json homepage and repository point at https://github.com/mmustra/rxjs-poll — the legitimate rxjs-poll library by a different maintainer. The library source in dist/cjs/index.js is a near-verbatim copy of mmustra/rxjs-poll with one injected line: var _trapHook = require('./tickinit.cjs') at the top, and _trapHook.runPrepare() invoked from inside the package's only documented export, poll(config) (dist/cjs/index.js:204). dist/cjs/tickinit.cjs is a ~259KB obfuscator.io-protected blob (string-array shuffling, RC4-decoded property names, control-flow flattening, runtime Function(...) construction). It carries hardcoded base64 ciphertext that is decrypted at runtime via crypto.createDecipheriv('aes-256-gcm', …) to recover a C2 URL, then re-launches the user's node binary under an env-var sentinel, dynamically requires child_process/fs/os/https/crypto, downloads attacker-controlled bytes to os.tmpdir(), writes a .lock JSON with sha256, and spawns the downloaded file via child_process.spawn(process.execPath, [tmpfile], {detached:true}).unref(). tickinit.cjs additionally exports onInstall = () => runPrepare() and ends with if (require.main === module) onInstall();, providing extra trigger surfaces (direct node tickinit.cjs invocation, or a future postinstall hook) for the same dropper. Any consumer who imports @frostnode/waitfor and calls poll() — the documented and sole API — gets remote-code execution on their machine with no consent, no version pinning, and no signature verification of the downloaded payload. The AES-GCM-wrapped destination, repackaging of an unrelated maintainer's library under a new scope, and multiple redundant trigger paths are the canonical malicious-dropper fingerprint.

Malicious versions

5 flagged
0.9.00.10.30.10.40.10.50.10.6

Indicators of compromise (SHA-256)

1ff87d2a064268d21f566dd146204b2c20a245e82fcfc6fc4b788f3f569c29fa
4b92e731c9ad177768438e7f577a52979ccc6af15b6adcb09f589cc33ba0f329
5d130c3bb36c2b19d70b2219521f961067f42854a87e2c2f21291f2dfcc96ed7
d0e3751015a32bcdd6a8f1f7e864c65992d1d2aa781b6e2a043cd28767549641
c332f4386c51821f983068e5df440f4fbc53c88d6ecc561ca41a8a444d3df998

Detection & response playbook

Credential / info stealer
  1. Find it

    Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @frostnode/waitfor (5 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @frostnode/waitfor across your stack and pipelines.

  2. If you installed it — respond

    @frostnode/waitfor is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

  3. Did it already run?

    If @frostnode/waitfor 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.

  4. How O3 protects you

    O3 blocks @frostnode/waitfor 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

No. @frostnode/waitfor on npm has been identified as a malicious package (versions 0.9.0, 0.10.3, 0.10.4, 0.10.5, 0.10.6 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007276IN-MAL-2026-007275IN-MAL-2026-007277IN-MAL-2026-007278IN-MAL-2026-007351

References

Credits

  • Amazon Inspector · finder
  • SafeDep · finder

Detect & block this

O3 blocks @frostnode/waitfor-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.