Which versions of testudo-pack are malicious?

The following npm versions of testudo-pack are flagged malicious: 1.0.0. Treat any of these as compromised.

How do I remediate testudo-pack if I installed it?

testudo-pack establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.

I already installed testudo-pack — how do I know if it already compromised me?

If testudo-pack 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 testudo-pack part of a known attack campaign?

Yes — testudo-pack is associated with the IN-MAL-2026-009172 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 testudo-pack 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 testudo-pack (version 1.0.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging testudo-pack across your stack and pipelines.

Malicious package

testudo-packnpm

testudo-pack is a confirmed malicious npm package (MAL-2026-10075) that opens a backdoor for remote access (malicious version 1.0.0). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in testudo-pack (npm)

MAL-2026-10075

Immediate action

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

npm uninstall testudo-pack

What this malware does

The npm package testudo-pack is byte-for-byte identical (verified via diff) to testis-pack from the same npm publisher ioa2102 ([email protected]), differing only in its install hook: postinstall: node index.js instead of preinstall. It presents itself as a small binary packing/checksum utility (pack/unpack/checksum/inspect) but embeds an obfuscated dropper. The strings for the C2 host, path and dropped-binary name are not present in plaintext — they are reconstructed at runtime via String.fromCharCode() calls over hardcoded integer arrays, decoding to the host sloth-antagonist.vercel.app, path /service/assets/fetchBinary (Windows) or /service/assets/fetchLinuxBinary (Linux), and destination filenames WinService.exe (Windows) / WinMetrics (Linux) written into %LOCALAPPDATA%\Programs\WinMetrics or $HOME/.local/share/WinMetrics respectively — names chosen to masquerade as a legitimate Windows telemetry/service binary. When triggered, the code downloads the file from https://sloth-antagonist.vercel.app/service/assets/fetch(Linux)Binary, chmods it executable on Linux, then spawns it detached and unref'd (stdio: 'ignore', windowsHide: true on Windows) so it runs silently in the background, disconnected from the parent process. The routine is skipped on macOS.

Note on the trigger: the fetch-and-execute routine (_fetch()) is not invoked at the top level of index.js — there is no unconditional call anywhere in the module. It is instead called as the first statement inside the exported pack() function, so the bare node index.js invocation performed by the postinstall hook only defines and exports the functions without itself triggering the download. The dropper fires as a side effect the first time any downstream code calls the package's own pack() API — which is the package's entire ostensible purpose, making activation highly likely for any real consumer while still evading naive "executes immediately on install" detections.

Analysis performed via static review only (npm registry metadata and package source retrieved as text via the npm registry and unpkg CDN) — the package was not installed or executed.

package.json declares a postinstall hook that runs index.js. On install, index.js decodes String.fromCharCode arrays to reconstruct the host sloth-antagonist.vercel.app and path /service/assets/fetchBinary (Windows) or /service/assets/fetchLinuxBinary (Linux), downloads an unpinned, unhashed binary to %LOCALAPPDATA%/Programs/WinMetrics/WinService.exe on Windows or ~/.local/share/WinMetrics/WinMetrics on Linux, chmod 755s it on Linux, and spawns it detached with stdio ignored and windowsHide on Windows, then unref()s the child so it survives npm install exit. macOS is skipped. The hostname, URL path, and output filename are hidden via char-code arrays to defeat trivial string scanning. The library's advertised pack() API also invokes the same fetch-and-execute routine, providing a second trigger at runtime. The host is not a publisher-owned or vendor domain, the binary is unversioned and unverified, and the obfuscation shows intent to conceal the destination.

Malicious versions

1 flagged

1.0.0

Indicators of compromise (SHA-256)

3acd6c2813f34615e913c745f4bfe83a18ca057ec5a109cc30cdd51320eade1a

Detection & response playbook

Backdoor / remote access

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for testudo-pack (version 1.0.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging testudo-pack across your stack and pipelines.
If you installed it — respond
testudo-pack establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.
Did it already run?
If testudo-pack 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 testudo-pack 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. testudo-pack on npm has been identified as a malicious package (version 1.0.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-009172

References

Credits

Amazon Inspector · finder
SafeDep · finder
LPM Firewall · finder

Detect & block this

O3 blocks testudo-pack-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the C2 callback and severs the channel.

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database