Operation Navy Ghost: How Eight Malicious PyPI Packages Turned Telegram Bots Into Attacker Shells

Supply chain attacks used to feel like abstract risk — the kind you nod at in a security training and forget by lunch. Then someone publishes eight backdoored forks of an abandoned Telegram framework, racks up over 25,000 downloads, and gets remote shell access to every production server that imported them. That’s Operation Navy Ghost, and it’s a case study in how attackers now weaponize the exact places developers trust most: PyPI, popular libraries, and the muscle memory of pip install.

Why an Abandoned Library Became the Perfect Attack Vector

According to researchers at Checkmarx, a single threat actor published at least eight trojanized forks of the Pyrogram library to PyPI between November 2025 and June 2026. Pyrogram itself hasn’t been updated since April 2023, but it still pulls nearly 350,000 monthly downloads and has more than 1,400 GitHub forks — a dormant giant that developers keep reaching for because it works.

That’s exactly why the attack works. When a library is unmaintained but widely used, developers start hunting for forks that fix bugs, add features, or claim compatibility with newer Python versions. Typosquats like pyrogram-styled (over 15,370 downloads across 16+ versions) and pyrogram-navy slot right into that search behavior. The legitimate source code is still in the package, so nothing looks broken. The backdoor lives in a helper module called secret.py, quietly registering hidden Telegram command handlers when the bot starts.

If you’re a developer maintaining a Telegram bot and you searched PyPI last month for a Pyrogram fork with async improvements, this is the exact profile you’d fall for. Expect a wave of copycat campaigns targeting other popular-but-abandoned libraries — think older Node.js SDKs, legacy Ruby gems, deprecated data science packages. Attackers have found the pattern, and it scales.

What the Backdoor Actually Does to Production Servers

The technical details from Checkmarx read like a red-teamer’s wishlist. Once the compromised bot launches, the attacker can send /asu print(os.environ) and get arbitrary Python executed against the live Telegram client, session, contacts, and environment variables. Sending /asi cat /etc/passwd triggers /bin/bash -c on the victim’s server, with output returned via Telegram messages — or as a document attachment if the result exceeds 4096 bytes.

Telegram bots almost never run on a developer’s laptop. They run in production. That’s where the databases, cloud API keys, service tokens, and customer data live. Checkmarx explicitly notes the backdoor only activates on bot accounts, not user accounts — a deliberate choice: the attacker wants “access to databases, credentials, cloud APIs, and sensitive infrastructure.” The malware also suppresses errors and disables logging, so your observability stack sees nothing.

Imagine you’re a fintech team running a customer-support Telegram bot on a small EC2 instance that also holds an IAM role for reading a transaction database. A single pip install pyrogram-styled in your requirements.txt hands an attacker read access to that database, your .env file, your cloud credentials, and every DM the bot has ever processed. The decision between building custom AI tooling versus relying on off-the-shelf SaaS packages starts to look very different when the “cheap” open source path can lead directly to full server compromise.

How Attribution Held Up Across Eight Separate Accounts

The eight packages were published from different PyPI accounts, which is normally where attribution goes to die. Checkmarx tied them together anyway, using four signals: a shared hardcoded OWNERS list of Telegram IDs across all backdoors, identical backdoor code, matching command names (/asu, /asi), and overlapping infrastructure. The OWNERS list is particularly clever — it also functions as a kill switch, deactivating the backdoor when it detects it’s running on the attacker’s own system so the operator doesn’t accidentally infect themselves.

For defenders, it shifts how you triage a suspicious dependency. A single malicious package looks like an isolated incident. Eight linked packages, published over eight months, spanning multiple accounts, is a sustained operation — the kind you assume has more waves coming. The four indicators Checkmarx used are exactly what static analysis tools can be tuned to flag: hardcoded Telegram IDs, dynamic compile() calls in a networking library, and shell execution inside a helper module have no business existing in a legitimate Pyrogram fork.

If your team runs software composition analysis in CI, ask whether your rules would have caught any of these packages before they reached production. For most teams, honestly, the answer is no. PyPI and other package registries will face growing pressure to implement mandatory publisher verification for packages that fork popular libraries — a friction cost the industry has resisted for years but can’t dodge much longer.

Why Regulated Industries Should Care Most

The blast radius here is worst in environments where a Telegram bot might touch regulated data. A healthcare software stack handling patient records or pharma supply chain events that uses a bot for internal alerts is one bad pip install away from a HIPAA incident. A logistics platform with a shipping-status Telegram bot exposes carrier APIs, warehouse credentials, and shipment data the moment the backdoor lands. The malware doesn’t discriminate — it exfiltrates whatever the infected application could legitimately access.

Checkmarx’s remediation guidance is blunt and correct: developers who installed any of the listed packages should remove them immediately, rotate all credentials on the affected server, and revoke their Telegram bot tokens. Assume compromise until proven otherwise. The IOCs Checkmarx published — malicious Telegram IDs and attacker profile URLs — should go straight into your threat Intel feeds.

FAQ

Q: What is Operation Navy Ghost? A: Operation Navy Ghost is a supply chain attack campaign identified by Checkmarx that published at least eight malicious forks of the Pyrogram Telegram framework to PyPI between November 2025 and June 2026. The packages contain a hidden backdoor in a secret.py helper module that gives attackers remote code execution on any server running an infected Telegram bot.

Q: Which PyPI packages are affected? A: The confirmed malicious packages are VLifeGram, VLife-Gram, pyrogram-navy, pyrogram-styled, pyrogram-zeeb, kelragram, sepgram, and pyrogram-kelra. Combined download counts run into the tens of thousands, with pyrogram-styled alone accounting for more than 15,370 downloads across 16 versions.

Q: How do I know if I’m compromised? A: Check your requirements.txt, pyproject.toml, and lockfiles for any of the eight package names. If you find one, Checkmarx recommends removing the package, rotating every credential accessible from the affected server, revoking your Telegram bot tokens, and consulting the published indicators of compromise for attacker Telegram IDs.

Key Takeaways

• Unmaintained-but-popular libraries are now prime targets — audit your dependencies for packages whose upstream hasn’t shipped in over 12 months and treat forks with extra suspicion.
• Any bot running in production should be scoped to least-privilege IAM roles, isolated network segments, and secrets that can be rotated in minutes, not days.
• Static analysis rules that flag hardcoded Telegram IDs, dynamic compile() calls, and shell execution inside library helper modules would have caught Operation Navy Ghost — teams should add these to CI now.
• Expect PyPI, npm, and other registries to face renewed pressure for mandatory verification of packages that fork widely-used libraries; get ahead of the compliance conversation before it becomes mandatory.
• Treat supply chain compromise as an assumed threat model, not an edge case — the eight-package, eight-month scale of this campaign signals sustained investment by attackers, not opportunism.