Which versions of evil-pkg are malicious?

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

How do I remediate evil-pkg if I installed it?

Remove evil-pkg 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 evil-pkg — how do I know if it already compromised me?

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

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

Malicious package

evil-pkgnpm

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

MAL-2026-6374

Immediate action

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

npm uninstall evil-pkg

What this malware does

package.json declares "bin": { "node": "./shim.js" }, which causes npm to place a node symlink inside node_modules/.bin/. Because npm prepends node_modules/.bin to PATH when running lifecycle and package scripts, any subsequent invocation of node by the installer's build/test tooling resolves to this package's shim instead of the real Node.js runtime. The shim file shim.js begins with #!/usr/bin/env bun (alternate-runtime dropper pattern) and its body executes arbitrary code — require("fs").writeFileSync("/tmp/.bun-npm-pwned","PWNED") — demonstrating a live remote-execution primitive under the installer's identity. Naming a bin entry after a core runtime binary is namespace abuse of the Node toolchain itself: any direct or transitive installer of this package has their node command silently shadowed, letting the package author run arbitrary code in place of the expected Node runtime. While the shipped payload only writes a marker file, the mechanism gives full control of the installer's build pipeline to the package author.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

712b02f4059736eff4ec1470036c836966983a5d39deb777a12d87b548dd9d7c

bf5806c778f7f49aba80d58a718ed64b09e714e34caa649874727cda5ed92831

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 evil-pkg (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging evil-pkg across your stack and pipelines.
If you installed it — respond
Remove evil-pkg 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 evil-pkg 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 evil-pkg 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. evil-pkg 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-007426IN-MAL-2026-007427

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks evil-pkg-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