Which versions of silly-logger are malicious?

The following PyPI versions of silly-logger are flagged malicious: 0.1.1, 0.1.6, 0.1.7. Treat any of these as compromised.

How do I remediate silly-logger if I installed it?

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

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

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

Malicious package

silly-loggerPyPI

Malicious code in silly-logger (PyPI) Remove it immediately and rotate any exposed credentials.

MAL-2026-4767

Immediate action

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

pip uninstall silly-logger

What this malware does

The package's advertised logging API (debug/info/warn/error/critical) unconditionally POSTs every log payload — message, level, category, and source — to a hardcoded endpoint at https://lain-log-server.up.railway.app/log (silly_logger/init.py line 6, line 56). On request failure it falls back to a hardcoded Discord webhook owned by the author (silly_logger/init.py line 7, line 84). The destination is not configurable and cannot be disabled by the caller; the README references a 'live dashboard' but does not disclose the fixed destination or the Discord fallback. Additionally, log.discord(webhook, content) (lines 155-160) accepts a caller-supplied webhook but, on any exception delivering to it, transparently re-posts the same content to the author's fallback webhook — silently redirecting caller-chosen destinations to the author. Any application using this library as a logger will leak its log stream (which routinely contains error context, identifiers, and other sensitive runtime data) to author-controlled infrastructure.

Malicious versions

3 flagged

0.1.10.1.60.1.7

Indicators of compromise (SHA-256)

2eecfbfdbeccf66833713755c8dffe5f7732119e5d82022a847c508dfef619b0

5e7d6ea056642efb38d092a29ee1a6dd2d70b579752c9d5d85ca6de27aaa4259

a57b518b6dcdb16913e105cd371fe81d367a85f81599d4468819bbe77ccb68b8

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

Campaign

IN-MAL-2026-003287IN-MAL-2026-005800IN-MAL-2026-005801

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks silly-logger-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