In the fast-paced and high-stakes world of decentralized finance and Telegram-based trading tools, security incidents can unfold with devastating speed. Hackers managed to steal nearly $1 million from wallets linked to the Telegram trading bot Bloom in a matter of seconds, sending shockwaves through the digital asset community and prompting an immediate pledge of restitution from the project’s developers.
According to a detailed report published Monday by blockchain analytics company Bitquery, the malicious attack successfully drained $953,000 in just 94 seconds. The funds were siphoned from 48 cryptocurrency wallets belonging to nine individual traders who had previously utilized the Bloom trading bot for their digital asset transactions.
Bitquery’s investigation into the incident revealed that each individual fund drain executed during the breach was structured as a Solana transfer. Crucially, these transactions were officially signed using the affected wallet’s private key, raising immediate questions across the crypto community regarding how unauthorized actors gained access to such sensitive signing mechanisms.
Despite the initial alarm caused by the nature of the Solana transfers, Bloom moved swiftly to reassure its user base and mitigate panic. The team behind the trading bot pledged to reimburse all affected traders in full, ensuring that no individual user would bear the financial brunt of the security breach.
In a subsequent statement released on Monday, Bloom shed further light on the technical vector behind the incident. The project attributed the breach to a remote code execution vulnerability located within a third-party module integrated into their systems. Crucially, Bloom maintained that no private keys were ever directly accessed or compromised by the hackers, suggesting that the vulnerability in the external module allowed the attackers to bypass standard authorizations or manipulate execution pathways without directly stealing underlying key material.
The incident highlights a persistent structural vulnerability inherent to the design of Telegram trading bots. Because these applications are engineered to execute trades rapidly on behalf of users directly through chat interfaces, many bots hold or interact with users’ private keys to facilitate seamless transactions. This operational model can leave lingering security risks that persist long after a trader stops actively using the service.
Highlighting this exact risk, Bitquery noted in its findings that five of the wallets drained during the Bloom attack had actually been completely inactive on the bot since the first half of 2025. The persistence of access or authorization pathways for dormant accounts underscores the complex security challenges facing developers of automated trading interfaces in the Web3 ecosystem.
This latest security breach is far from an isolated incident within the niche yet popular sector of Telegram-based trading tools. Over the past few years, as these bots have gained massive traction for allowing retail traders to snipe new token launches and execute rapid swaps, they have increasingly become prime targets for sophisticated threat actors seeking high-value bounties.
A similar high-profile disaster occurred in September 2024, when developers of the popular Telegram trading bot Banana Gun reported a major security breach that resulted in 11 users losing approximately $3 million in Ether. Prior to that, in October 2023, users of competing Telegram trading bots Maestro and Unibot suffered substantial financial losses when a combined $1.1 million was drained due to critical exploits targeting their underlying router contracts.
As the ecosystem continues to grapple with these recurring vulnerabilities, the pressure is mounting on developers to implement rigorous security audits, isolate third-party dependencies, and establish transparent safety protocols to protect retail participants in the decentralized economy. Meanwhile, Bloom’s commitment to fully reimbursing the nine affected traders offers a measure of relief, even as investigations into the precise mechanics of the third-party module exploit continue.
Comments (0)