Pyronut Package Backdoors Telegram Bots With RCE

Malicious ‘Pyronut’ is a trojanized Python package that backdoors Telegram bots and userbots, giving attackers remote code execution over both the Telegram session and the underlying host system.

The malicious package, pyronut, was uploaded to PyPI as a fake alternative to pyrogram, a widely used Telegram MTProto API framework with around 370,000 monthly downloads.

Instead of offering new features, the author copied Pyrogram’s project description word-for-word and pointed to a GitHub repository URL that does not exist, a strong indicator of a fraudulent fork rather than a legitimate project.

Because the names “pyrogram” and “pyronut” are not similar enough for classic typosquatting, this package was likely pushed through Telegram groups, developer forums, or tutorial content, where developers are more inclined to copy-paste install commands without closely reviewing the package metadata.

Only three versions of pyronut were ever released 2.0.184, 2.0.185, and 2.0.186 and all of them were malicious.

Python package `pyronut` targeted Telegram bot developers by impersonating `pyrogram`, a popular Telegram API framework with roughly 370,000 monthly downloads.

Pyronut Package backdoor

Unlike many malicious PyPI packages that fire during installation via setup scripts, Pyronut activates its payload only at runtime.

The attacker modified the core Client.start() method pyrogram/methods/utilities/start.py to silently import a hidden module pyrogram/helpers/secret.py every time a Telegram client starts, wrapping the entire logic in a bare try/except: pass so that any errors are swallowed and the application behaves normally.

When the init_secret() function executes, it first checks if the current Telegram account matches one of two hardcoded owner IDs and exits if it does, ensuring the attacker’s own accounts are never backdoored.

For all other users, it registers two hidden message handlers that listen for /e and /shell commands from those attacker-controlled accounts, but only when messages are direct and not forwarded or sent via inline bots, improving the attacker’s operational security and reducing obvious traces.

The /e command turns the victim’s bot into a live Python console. Using the meval library, the handler evaluates attacker-supplied Python code inside the running Telegram client process with direct access to the full pyrogram.Client instance, message objects, raw Telegram API, and various helper modules.

This gives the attacker the ability to read chat history, access contacts, download media, send messages as the victim, and call low-level Telegram APIs, all from within the existing session context.

The /shell command provides a second, more traditional backdoor: it passes attacker-controlled input directly to /bin/bash -c via subprocess.run, returning both stdout and stderr to the attacker on Telegram.

With this, the attacker can browse the file system, steal credentials and keys, drop additional malware, and pivot to other systems using the same privileges as the Python process.

Importantly, all command results are sent back through Telegram itself, either as messages or as temporary text file attachments, so there is no external C2 domain or unusual outbound traffic pattern to flag in network monitoring tools.

Detection and response guidance

Because Pyronut’s payload runs at client startup, detection requires looking at both dependencies and runtime behavior.

Security teams should search dependency manifests (such as requirements.txt, Pipfile, or pyproject.toml) for pyronut versions 2.0.184–2.0.186, and also flag unexpected use of meval, which Pyronut pulls in specifically to power its Python evaluation backdoor.

Endpoint and system logs should be reviewed for suspicious /bin/bash -c child processes spawned from Python, as well as unusual file operations or network activity originating from Telegram bot processes.

If Pyronut is found, all related Telegram sessions and bot tokens should be revoked, and the affected environments rebuilt from a known-good baseline after uninstalling the package.

Because the attacker could access environment variables and local secrets through both Python and shell execution, all potentially exposed credentials, keys, and tokens must be rotated.

Longer term, organizations should tighten dependency vetting, verify that forked libraries have real, reachable source repositories, and integrate software composition analysis and runtime monitoring to catch similar malicious forks in the future.