Which versions of env-threads are malicious?

The following npm versions of env-threads are flagged malicious: 1.5.0. Treat any of these as compromised.

How do I remediate env-threads if I installed it?

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

I already installed env-threads — how do I know if it already compromised me?

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

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

Malicious package

env-threadsnpm

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

MAL-2026-3759

Immediate action

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

npm uninstall env-threads

What this malware does

Package env-threads impersonates the legitimate dotenv package: its README, repository URL (git://github.com/motdotla/dotenv.git), homepage, description, keywords (dotenv, env, .env, environment, variables, config, settings), and public API surface (config, parse, populate) are copied from dotenv, but the package name differs. Unlike genuine dotenv — a small unobfuscated pure-JS parser — this package ships an 82 KB heavily obfuscated lib/main.js with hex-named identifiers and a string-array decoder (xIuLO2(0x...)). At module top level, the last executable statement runs SbEjWpp(path.join(__dirname, <decoded-filename>)), which resolves to lib/stest.jpg. The SbEjWpp function calls fs.readFileSync on that file and extracts an embedded payload via steganographic decoding, then executes it through child_process. Every consumer who adds env-threads to their dependency tree and requires it — typically expecting dotenv-like behavior — triggers arbitrary code execution from a payload hidden inside a JPEG shipped in the tarball. The combination of (1) verbatim typosquat of a top-tier npm package, (2) heavy obfuscation absent from the impersonated original, and (3) child_process execution of steganographically-hidden bytes at require-time is unambiguous supply-chain malware.

Malicious versions

1 flagged

1.5.0

Indicators of compromise (SHA-256)

cfb511e0bf06367ec0341939aa68ee55859344c6ca6cb8d9f55f7e62cdcc8656

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 env-threads (version 1.5.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging env-threads across your stack and pipelines.
If you installed it — respond
env-threads is a typosquat — you almost certainly intended a legitimately-named package. Remove env-threads, 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 env-threads 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 env-threads 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. env-threads on npm has been identified as a malicious package (version 1.5.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-002641

References

npmjs.com

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks env-threads-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