Which versions of smtrlib are malicious?

The following PyPI versions of smtrlib are flagged malicious: 0.1.5, 0.1.6. Treat any of these as compromised.

How do I remediate smtrlib if I installed it?

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

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

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

Malicious package

smtrlibPyPI

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

MAL-2025-192690

Immediate action

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

pip uninstall smtrlib

What this malware does

Malicious copy of a standard library module that during class initialization downloads and executes remote code and after that attempts to cover its tracks by overwriting itself with non-malicious code. The remote code aims to collect and exfiltrate sensitive Telegram session files.

This campaign shares infrastructure and basic methods with previous 2025-11-uzip campaign.

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

Campaign: 2025-12-smtblib

Reasons (based on the campaign):

Downloads and executes a remote malicious script.
infostealer
target:telegram
exfiltration-credentials
action-hidden-in-lib-usage
covering-tracks
clones-real-package
typosquatting

Malicious versions

2 flagged

0.1.50.1.6

Indicators of compromise (SHA-256)

2c1075f7c4373ccaac9936bfd75a22a27f0c9ba06a5402a68a45fe8121f58783

a2f22b191147cb45609f235f11ad1e22cbddd3ea8fcbc48eae1b924c03c8581a

9d85a36c2c00ecd57e7e665998fe1ecb407321c3c31d98e236f7cf1d8d382e81

10033b8781afb1d5ce5c8e963a881098ccc3c451b91eeca2923530156685996e

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

Campaign

2025-12-smtblib

References

Credits

Kamil Mańkowski (kam193) · reporter

Detect & block this

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