Which versions of whs4_eud are malicious?

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

How do I remediate whs4_eud if I installed it?

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

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

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

Malicious package

whs4_eudnpm

whs4_eud is a confirmed malicious npm package (MAL-2026-11071) that steals credentials and exfiltrates sensitive data (malicious versions 1.0.0, 1.0.1). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in whs4_eud (npm)

MAL-2026-11071

Immediate action

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

npm uninstall whs4_eud

What this malware does

[email protected] declares a postinstall lifecycle script (node index.js) that fires unconditionally on npm install. On execution, index.js POSTs installer-side host information — the absolute path of the install location (which embeds the user's home directory), Node.js version, and platform/architecture — to a hardcoded Discord webhook under discord.com/api/webhooks/1530599209269465319/. The webhook URL is assembled by concatenating two string literals at runtime rather than appearing as a single literal, a light obfuscation of the exfiltration destination. The package name and layout are consistent with a dependency-confusion / typosquat beacon whose only functional behavior is to notify the author when an install occurs and to disclose where.

The OpenSSF Package Analysis project identified 'whs4_eud' @ 1.0.1 (npm) as malicious.

It is considered malicious because:

The package communicates with a domain associated with malicious activity.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

d906ecaf9f2ede0a31c6966b9d8402f4c80e57fb72eae7f9dfa1b3a7c583b8d4

6be47b29c887fd54b5cffc8789278f3ea7987b12d618e89c540e5670edea12b5

f8dcbecbaf2392f7cd7720244800fde67c971fa7fa34fb8cf21d61c580dd4713

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

References

Credits

Amazon Inspector · finder
OpenSSF: Package Analysis · finder

Detect & block this

O3 blocks whs4_eud-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

Explore

All malware advisories How O3 detects malware Vulnerability database