Which versions of shiroai are malicious?

The following npm versions of shiroai are flagged malicious: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1.0, 2.2.0. Treat any of these as compromised.

How do I remediate shiroai if I installed it?

shiroai 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.

I already installed shiroai — how do I know if it already compromised me?

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

Yes — shiroai is associated with the IN-MAL-2026-004531, IN-MAL-2026-004571, IN-MAL-2026-004528, IN-MAL-2026-004579, IN-MAL-2026-004530, IN-MAL-2026-004529 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 shiroai 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 shiroai (6 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging shiroai across your stack and pipelines.

Malicious package

shiroainpm

Malicious code in shiroai (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-4669

Immediate action

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

npm uninstall shiroai

What this malware does

shiroai is advertised as a CLI where the installer authenticates with their own API key (via shiroai login <KEY>). In practice, cli.js ignores any user-supplied key and sends every chat request to https://inference.do-ai.run/v1/chat/completions with a hardcoded Authorization: Bearer doo_v1_... token belonging to the author's DigitalOcean GenAI account (cli.js line ~19 sets API_URL; line ~245 attaches the hardcoded bearer). All caller-supplied data — user prompts plus project context auto-loaded by getProjectContext (package.json, Cargo.toml, and other files in the working directory) and tool-call read_file outputs — is routed through a destination the caller did not choose and was misled about. This is a silent-relay pattern: the advertised API surface ("bring your own key") is a cover for funneling caller data through an author-controlled third-party account, exposing potentially sensitive source code and prompts to both the author and DigitalOcean under the author's identity rather than the installer's. The same hardcoded doo_v1_... token is shipped in every install, so any installer can extract and abuse it against the author's quota, but the primary installer-side harm is the undisclosed redirection of their inputs and file contents.

Malicious versions

6 flagged

2.0.42.0.52.0.62.0.72.1.02.2.0

Indicators of compromise (SHA-256)

5bc127758bf7441b20e55dae50c7a719c250ee253ef106fb8c8270236ed4a744

8cde2f64fd59e62071433f92eab83a4817f0b306ff1735aa8c31ae31dcaf9830

8ecf975548646b17ed1c53831a81e29d77e83b1d7e4a7fe3590b4137d2e42290

95daa936a966544b2c598bbd6a6fc771b43e03453aaff47e5cd83e4b02333e21

9bc8c3b7d67f4a8ab3c0466068012b0bcffac805213849504f3ddd7144f8bf6c

faee19fd1f85f957ad93ed0f6eb64bea5e1db5d63b2160df137a2ef417b4a8d4

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for shiroai (6 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging shiroai across your stack and pipelines.
If you installed it — respond
shiroai 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.
Did it already run?
If shiroai 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 shiroai 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. shiroai on npm has been identified as a malicious package (versions 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1.0, 2.2.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-004531IN-MAL-2026-004571IN-MAL-2026-004528IN-MAL-2026-004579IN-MAL-2026-004530IN-MAL-2026-004529

References

Credits

Amazon Inspector · finder

Detect & block this

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

Malware detection Runtime egress monitoring