Bloom Hack: 9,408 SOL Drained From 49 Wallets

Nine users of Bloom, a trading bot for the Solana blockchain, lost about 9,408 SOL early on Monday 26 October when an attacker drained 49 of their wallets, moving most of the money in under a minute. Bloom puts the loss at $947,000 and says it will repay all of it.

The attack “exploited a third-party module through a complex Remote Code Execution (RCE) vulnerability”, Bloom said in a post on X at 09:12 GMT. A remote code execution flaw lets an outsider run their own commands inside someone else’s software. Bloom said “no private keys were accessed or compromised” and that it had “ruled out broader exposure of users’ wallets”. It has not named the module or the company that supplies it, and the attacker has not been identified.

In brief

Bloom says 49 wallets belonging to nine users were drained of about 9,408 SOL ($947,000) through a flaw in a third-party module.
The public ledger shows most of the money arriving at one address within about 51 seconds, then leaving in a single transfer three and a half hours later.
Bloom says it will repay 100% of the losses and has taken all its systems offline; it has given no date for either.

The ledger shows a 51-second drain

An address that the analytics account Onchain Lens linked to the attack, according to The Crypto Times, shows the pattern on the public ledger. TSN read all 73 of that address’s transactions through a public Solana node. Tiny test transfers of 0.001 SOL began arriving at about 01:00 GMT. Then, between 01:03:50 and 01:04:41 GMT, the bulk of the money landed. The largest single transfer was 1,636 SOL. In total the address took in about 9,408.2 SOL, in line with Bloom’s own figure.

It did not stay there long. At 04:30:56 GMT the address sent its whole balance, 9,408.21 SOL, to a second address in one transfer. It now holds nothing.

What Bloom has said so far

Bloom’s first public word came at about 03:00 GMT, when it said in a reply on X that it was “temporarily disabling some services”. By 04:37 GMT it was investigating “whether a third-party provider may have been compromised, especially given the recent wave of security incidents across the industry”. Minutes later it told users: “This is not an exit scam.”

Early alerts, including one from Coin Bureau, spoke of about 49 victims and losses of around $954,000. At 06:05 GMT Bloom corrected the count: “the 49 affected wallets belong to 9 individual users, not 49 separate victims”. It advised users to move any remaining funds to fresh wallets with newly generated private keys.

In its fuller statement, Bloom said it “will fully reimburse 100% of the stolen funds directly to secure wallets designated by the affected users”. It is also “working to trace the stolen funds, explore recovery and freezing options, and identify the attacker”. All Bloom systems are offline “as a precautionary security measure”, and users will have to log in again to Bloom Manager and the Chrome extension when they return. Bloom gave no time for either the refunds or the restart.

The money moved before tracing could start

The three and a half hours the coins sat at one address were the best chance to stop them. They left about 90 minutes after Bloom began switching services off, and before it publicly raised a third-party compromise. That matters for recovery. Native SOL has no issuer that can freeze it, unlike stablecoins such as USDC, so Bloom’s “freezing options” depend on the coins reaching an exchange or service willing to act. For compliance teams at exchanges, the two addresses above are the obvious entries for a watch list; the second one is where tracing now begins.

Third-party code keeps turning up in these incidents

Bloom’s explanation fits the pattern Hacken described when it said crypto hacks cost $1.18 billion in the third quarter, mostly through suppliers and developer tools. This month alone, the Polkadot Foundation said a wallet browser extension leaked users’ private keys, and Swell paused two tokens after a suspected hot-key compromise.

Bloom’s case leaves one question open. It says no keys were exposed, yet money left users’ wallets. Trading bots generally place trades automatically, so they need a way to authorise transactions; code running inside such a system could, in principle, order transfers without copying a key. Bloom has not said whether that is what happened, or why only nine users were hit. TSN’s crypto hacks hub tracks similar cases.

The promise to repay is now the measurable part. The test is whether 9,408 SOL reaches those nine users before the stolen coins reach an exchange.