Which versions of wsh4_edu are malicious?

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

How do I remediate wsh4_edu if I installed it?

wsh4_edu establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.

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

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

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

Malicious package

wsh4_edunpm

wsh4_edu is a confirmed malicious npm package (MAL-2026-11072) that opens a backdoor for remote access (malicious version 1.0.0). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in wsh4_edu (npm)

MAL-2026-11072

Immediate action

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

npm uninstall wsh4_edu

What this malware does

The package's postinstall hook runs index.js, which POSTs the installer's absolute filesystem path (via __filename with sendFullPath: true), Node.js version, platform, and architecture to a hardcoded Discord webhook at discord.com/api/webhooks/1530599209269465319/. The same beacon also fires when the module is required, since index.js is the package main. The absolute path typically embeds the local username and home directory, giving the operator of the webhook a host/identity fingerprint of every machine that installs the package. The webhook URL is split across two string literals and concatenated at call time to evade casual string scanning, and the destination is not caller-configurable. The package name and README self-describe as a typo/beacon experiment.

The OpenSSF Package Analysis project identified 'wsh4_edu' @ 1.0.0 (npm) as malicious.

It is considered malicious because:

The package communicates with a domain associated with malicious activity.

Malicious versions

1 flagged

1.0.0

Indicators of compromise (SHA-256)

e68d4c62ae8440581c4400e1cdacb7877912eb23610e273432d18cea61574785

0757eee7b6324baca2e2b28261c7ff072c60d578c827a14c1fa54f690b1cd53a

Detection & response playbook

Backdoor / remote access

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for wsh4_edu (version 1.0.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging wsh4_edu across your stack and pipelines.
If you installed it — respond
wsh4_edu establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.
Did it already run?
If wsh4_edu 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 wsh4_edu 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. wsh4_edu on npm has been identified as a malicious package (version 1.0.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-011286

References

npmjs.com

Credits

Amazon Inspector · finder
OpenSSF: Package Analysis · finder

Detect & block this

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

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database