Which versions of malipkghehe are malicious?

The following PyPI versions of malipkghehe are flagged malicious: 0.1.0, 0.1.1, 0.1.2, 0.1.4. Treat any of these as compromised.

How do I remediate malipkghehe if I installed it?

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

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

Yes — malipkghehe is associated with the RLMA-2025-03641, 2025-07-0x9xnx, RLUA-2026-00492 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 malipkghehe 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 malipkghehe (4 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging malipkghehe across your stack and pipelines.

Malicious package

malipkghehePyPI

Malicious code in malipkghehe (PyPI) Remove it immediately and rotate any exposed credentials.

MAL-2025-6544

Immediate action

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

pip uninstall malipkghehe

What this malware does

Series of packages mostly with an obfuscated infostealer attempting to collect Chrome data. While discord webhook is usually set to an example, there are other, correct uploading URLs

Some of related packages only test partial malicious code, like webhooks from overwritten setup.py

Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.

Campaign: 2025-07-0x9xnx

Reasons (based on the campaign):

infostealer
obfuscation
exfiltration-browser-data
exfiltration-crypto
The package overrides the install command in setup.py to execute malicious code during installation.

Malicious versions

4 flagged

0.1.00.1.10.1.20.1.4

Indicators of compromise (SHA-256)

fc099538c7865eb4a5fe831a49817002187c27f075608758fd4e5393c603337e

d0f7d1f3714d2767c3554cef1c9f8938c5bd51540e1e92342566803b20a3eb40

7d87e6aa802f74ebffe0dd2741a513b40db41629d41828bf5b9847ca87e7609e

19d23cde46d77a83971e2e78fc7fdf1ec9e735f59bb4e1bbe890a3eaa57a99ba

92cf427e5d2028599c9275b48d31dda6a2ee2ccf9325b02b7a7d883707e80cdf

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 malipkghehe (4 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging malipkghehe across your stack and pipelines.
If you installed it — respond
malipkghehe 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 malipkghehe 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 malipkghehe 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. malipkghehe on PyPI has been identified as a malicious package (versions 0.1.0, 0.1.1, 0.1.2, 0.1.4 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

RLMA-2025-036412025-07-0x9xnxRLUA-2026-00492

References

bad-packages.kam193.eu

Credits

Kamil Mańkowski (kam193)
ReversingLabs · finder

Detect & block this

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