Operation Navy Ghost is a software supply-chain campaign that targeted Python developers building Telegram bots. Attackers published trojanized forks of the legitimate Pyrogram library on the Python Package Index (PyPI), embedding a hidden backdoor capable of executing Python code or shell commands on infected servers after the bot launched. Organizations using the affected packages should remove them, rotate credentials, revoke Telegram bot tokens, and review systems for signs of compromise. The campaign reinforces why dependency security, endpoint visibility, and strong device management practices remain essential for enterprise development environments.
A newly disclosed software supply chain campaign has highlighted how a seemingly legitimate Python dependency can provide attackers with remote control over servers running Telegram bots. Dubbed Operation Navy Ghost, the campaign involved malicious PyPI packages masquerading as forks of the popular Pyrogram framework.
Once installed, the modified packages reportedly registered hidden Telegram command handlers capable of executing attacker-supplied Python code or shell commands on infected systems.
Rather than targeting Telegram itself, the attackers abused the trust developers place in public package repositories. The incident shows how third-party dependencies can become an attack vector capable of reaching production infrastructure through routine software development workflows.
The campaign, reportedly active since November 2025, involved at least eight malicious packages uploaded to PyPI as modified versions of the legitimate Pyrogram framework.
The trojanized packages preserved Pyrogram’s expected functionality while introducing additional malicious code inside a helper module named secret.py.
When an affected Telegram bot started, the malware reportedly:
Registered hidden Telegram command handlers
Accepted commands from attacker-controlled Telegram accounts
Executed arbitrary Python code
Executed shell commands on the host
Returned command output through Telegram
Read files accessible to the compromised application
Suppressed errors and logging to reduce visibility
Because the malware retained the expected behavior of the legitimate library, developers may not have noticed any operational issues after installation. This combination of normal application functionality and concealed backdoor logic is characteristic of modern software supply-chain attacks, where malicious code is designed to blend into trusted development workflows.
What Is Confirmed and What Remains Unclear
The published analysis confirms that the affected packages contained embedded backdoor functionality capable of providing remote command execution through Telegram-based command handlers.
It also confirms that the campaign specifically targeted developers using Pyrogram-based Telegram applications.
However, several important questions remain unanswered publicly:
The campaign has not been attributed to a known named threat group.
No victim organizations have been identified.
The number of compromised environments has not been disclosed.
Public reporting has not confirmed credential theft, data theft from named victim organizations, or follow-on intrusions resulting from the campaign, although the malware reportedly included data exfiltration capabilities.
Although the malware was capable of executing commands and accessing files available to the compromised application, organizations should avoid assuming every installation resulted in a successful compromise without further investigation.
Why Operation Navy Ghost Matters for Enterprises
Although the campaign specifically targeted Python developers building Telegram bots, the broader implications extend well beyond developer workstations.
Production bot applications often operate with access to valuable enterprise resources, including:
If a compromised application runs with access to these resources, attackers may be able to leverage the application’s existing permissions to expand their access. The privileges granted to the affected service determine the potential impact, and public reporting has not universally confirmed that impact across this campaign.
The incident demonstrates why organizations should treat dependency security as a core component of enterprise security. Malicious packages that preserve expected functionality can evade casual inspection, allowing compromised software to move from development into production unless organizations maintain strong software governance and endpoint visibility.
Ensure Software Supply Chain Security with Hexnode UEM
Learn how Hexnode helps strengthen software supply chain security with runtime visibility, and policy enforcement.
Recommended Mitigations
Organizations that suspect they may have installed one of the affected packages should prioritize containment and validation.
Recommended actions include:
Remove the malicious packages from development and production environments.
Revoke and regenerate Telegram bot tokens.
Rotate credentials that may have been accessible from affected systems.
Review endpoint telemetry and application logs for unexpected Python or shell activity.
Validate third-party software dependencies before deployment.
Maintain an inventory of packages used across production workloads.
Review developer workstations and internal package repositories for cached copies of the affected packages.
These measures can help reduce the likelihood that compromised dependencies remain active after package removal and support a more effective incident response.
How Hexnode Can Help
Responding to software supply-chain incidents requires visibility into affected endpoints, the ability to investigate suspicious activity, and consistent enforcement of endpoint policies.
Hexnode UEM can help organizations strengthen developer endpoint hygiene by:
Enforcing operating system update policies
Managing approved applications
Supporting managed application deployment
Applying device compliance policies
Restricting unauthorized software where appropriate
If suspicious activity is identified on managed endpoints, Hexnode XDR can support endpoint investigation and response by helping security teams:
Review historical endpoint activity
Investigate suspicious endpoint behavior using endpoint telemetry
Isolate affected devices from the network
Terminate suspicious processes as part of incident response
Featured resource
Introduction to Hexnode XDR
Learn how Hexnode XDR helps security teams investigate suspicious endpoint activity and respond to threats more effectively.
Organizations using Hexnode IdP can further strengthen access controls through multi-factor authentication (MFA), role-based access control (RBAC), Microsoft Entra ID integration, and device compliance checks.
While these capabilities do not prevent software supply-chain attacks, they can improve endpoint visibility, support investigations, and help organizations respond to suspicious activity across managed environments.
Organizations building applications on open-source ecosystems should make dependency governance a core security control. They should pair it with endpoint visibility, credential hygiene, and incident response. Organizations should verify third-party packages before deployment. They should also maintain endpoint visibility and respond quickly to suspicious activity. These practices can help reduce the operational impact of compromised dependencies.
While investigators continue to analyze this campaign, organizations should continuously validate software trust throughout the development lifecycle instead of assuming it at installation.
Secure Developer Endpoints with Confidence
Protect development environments with device compliance, and endpoint investigation capabilities designed to help reduce risk across your organization.
I write at the intersection of technology, process, and people, focusing on explaining complex products with clarity. I break down tools, systems, and workflows without any noise, jargon, or the hype.