Bloom Trading Bot Hack Drains $953,000 From 48 Solana Wallets

The Bloom trading bot attack exposed a persistent risk in delegated crypto trading: a wallet can remain vulnerable after its owner stops using the service. Five of the 48 affected wallets had been inactive on Bloom since the first half of 2025, blockchain analytics firm Bitquery said. That detail matters because it separates the incident from a simple case of users trading at the moment their funds were taken. For those five wallets, the reported gap between activity and loss raises a harder question: what access can a service retain after a user has moved on?

The attack took $953,000 from wallets belonging to nine traders in just 94 seconds, according to Bitquery’s report published Monday. Each withdrawal was a Solana (SOL) transfer signed with the affected wallet’s private key. The speed suggests the withdrawals were executed in a tightly concentrated burst, though the information in the report excerpt doesn’t establish exactly how the attackers gained the ability to initiate them. That distinction matters: the transactions show how funds moved, while the explanation for the access remains a separate question.

Bloom cites third-party code

Bloom pledged to reimburse all nine traders in full. In a statement later Monday, the company blamed a remote code execution vulnerability in a third-party module and said attackers hadn’t accessed or compromised private keys. Those claims describe Bloom’s account of the incident; Bitquery’s finding that withdrawals were signed with affected wallets’ private keys describes what happened on-chain. The two statements address different parts of the event, and the available details don’t resolve how they fit together.

That gap is worth attention. A transaction signed by a wallet’s private key doesn’t, by itself, identify who controlled the signing process or whether a key was extracted. Bloom’s statement says the keys weren’t compromised, while its explanation points to vulnerable third-party code. Without further technical detail, readers can’t determine how that code enabled the transfers or what safeguards failed. The distinction isn’t academic: users need to understand whether the danger came from key theft, unauthorized use of signing access, or another mechanism.

Telegram trading bots typically ask users to delegate enough wallet access to execute trades. That convenience shifts some operational responsibility from the trader to the service and the software it depends on. A third-party module can become part of that trust chain even when users never interact with it directly. Here’s the thing: a service’s security boundary can extend well beyond the interface a trader sees.

What inactive wallets reveal

The five wallets that had reportedly been inactive on Bloom since the first half of 2025 sharpen the central concern. Stopping trades through an app may not automatically revoke permissions or remove access associated with a wallet. The source doesn’t say what those users did after they stopped using Bloom, or whether the wallets remained connected in a particular way. It does show why “I don’t use this anymore” and “this service can no longer affect my wallet” shouldn’t be treated as the same statement.

In systems built around delegated access, users may have to take a separate step to withdraw that access or move funds to a wallet they consider outside the service’s reach. The exact steps depend on how a product handles keys and permissions, and the available information doesn’t establish Bloom’s specific process. (And this is the part most people overlook.) Inactivity is a statement about a user’s behavior; it isn’t proof that the technical relationship has ended.

If you’re working in this space, the incident puts a practical design question in focus: how clearly does a service explain what access persists, and what action ends it? A good answer needs to be understandable before a loss occurs. Refunds can address the immediate financial impact for affected users, as Bloom has pledged to do, but they don’t by themselves clarify how the access was used or whether the underlying weakness has been fixed.

A recurring risk for bot users

Bloom is the latest Telegram trading bot linked to a major loss. In September 2024, Banana Gun said 11 users lost about $3 million. The previous October, exploits of router contracts used by Maestro and Unibot led to combined losses of $1.1 million. The incidents involved different services and, in the cited examples, different technical components. They don’t establish a single cause shared across all three cases.

They do show that losses tied to automated trading tools can arise at several points in the chain: the software users interact with, the components a service relies on, or the contracts that route transactions. The particulars matter. Treating every incident as the same kind of breach would obscure what users and developers need to learn from each one. Still, repeated losses make the broader trade-off difficult to ignore: automation can reduce friction, while delegated access creates another relationship that users must understand and manage.

Implications beyond the immediate loss

For traders, the Bloom incident points to a security question that outlasts active bot use: whether a connected wallet remains exposed after trading stops. This is more significant than it looks. A service can be easy to try and easy to abandon, while the permissions or access tied to it may require deliberate action to unwind. The available facts don’t show precisely what former Bloom users should have done, but they make the question of revocation hard to dismiss.

For providers, the episode puts third-party dependencies and clear user guidance under scrutiny. Saying that a vulnerability came from an outside module identifies a part of the software chain; it doesn’t tell users how the flaw affected wallet activity or what has changed since. Those details are what would help distinguish a contained failure from an unresolved access problem. And yet, a pledge to reimburse users is a concrete response to the reported losses, even as technical questions remain.

The immediate facts are stark: nine traders, $953,000 taken, and transfers made in 94 seconds. The longer-term lesson is less tidy. Users need a clear way to understand whether a bot still has access when they stop trading, and providers need to explain how that access works. Until those answers are explicit, an inactive wallet may still carry an active risk. A loose end.

Related: Cysic dangles a 10% bounty, hacker pours loot into Tornado Cash

Cointelegraph is committed to providing independent, high-quality journalism across the crypto, blockchain, AI, and fintech industries.

All news, reviews, and analyses are produced with full journalistic independence and integrity. For more details on our standards and processes, please read our Editorial Policy.