Skip to main content
Bloom Trading Drain: Valid Signatures, No Leaked Keys
Security
Security
4 min read17 views

Bloom Trading Drain: Valid Signatures, No Leaked Keys

Floriano Righetti
Floriano Righetti

On Monday 26 October 2026, users of Bloom, a trading bot for the Solana network, had about 9,408 SOL drained from their wallets in a matter of minutes. By the same evening, Bloom said it had refunded all of it. (This Bloom is a trading-software company. It is not connected to the Monetary Authority of Singapore's BLOOM initiative.) We are covering the incident because it shows a risk that is easy to overlook: the software that holds signing authority for a wallet can become the weakest point, even when the blockchain and the keys themselves are not compromised.

What happened#

On-chain reconstructions published by TSN and Bitquery describe a fast, concentrated drain. TSN read the transactions of the receiving address through a public Solana node. Small test transfers of 0.001 SOL began at about 01:00 UTC, and the bulk of the funds arrived between 01:03:50 and 01:04:41 UTC. At 04:30:56 UTC the address forwarded its whole balance, 9,408.21 SOL, to a second address in a single transfer. Bitquery, as reported by The Crypto Guardian, counted 48 wallets drained during a 94-second window. It found that every drain was a standard SOL transfer signed by the affected wallet's own key, with no token approval, smart-contract exploit or second signer.

Bloom's first replies on X came during the night. Early public alerts spoke of about 49 victims, and Bloom corrected this at 06:05 UTC: "the 49 affected wallets belong to 9 individual users, not 49 separate victims". In its official statement at 09:12 UTC, Bloom said the attack "exploited a third-party module through a complex Remote Code Execution (RCE) vulnerability". It added that "no private keys were accessed or compromised" and that it had "ruled out broader exposure of users' wallets". It put the loss at approximately 9,408 SOL, or $947,000 at its own valuation. Bloom took all of its systems offline as a precaution and said users will have to log in again to Bloom Manager and its Chrome extension when service resumes.

At 20:37 UTC, Bloom announced that "100% of the affected funds, totaling 9,408 SOL, have been fully refunded to all 9 users". It linked nine Solana transactions as proof.

What we checked#

We queried those nine transactions on a public Solana mainnet node. All nine succeeded. They were sent between 15:37 and 20:33 UTC on 26 October from the same address, 35yDUV…uTKK, which Bloom also published as its on-chain contact address. In our reading, the recipients received about 9,399.2 SOL in total. That is slightly less than the 9,408 SOL Bloom stated. We have not established the reason for the difference of roughly 9 SOL. It may lie in rounding or in transfers not included in the nine links.

What is known and what is not#

Known: the loss sits in Bloom's off-chain software, not in the Solana protocol. The transfers carried valid signatures from the affected wallets, and Bloom says it has repaid the affected users in full.

Not yet known: Bloom has not named the third-party module or its supplier. It has not published a technical post-mortem, explained why only nine users were affected, or given a date for restoring service. It has also not explained how valid signatures were produced if, as it says, no keys were accessed. One plausible explanation, raised by both TSN and The Crypto Guardian, is that code running inside software already able to sign could order transfers without ever exporting a key. Bloom has not confirmed this. The attacker has not been identified. In a separate post, Bloom offered to negotiate a partial return of the funds.

Our view#

For us, the lesson concerns architecture rather than one vendor. When a service keeps a key "hot" so that it can sign automatically, every dependency in that service effectively shares the key's authority. Keeping the key secret is necessary, but it is not sufficient. What matters is who can cause a signature, under which limits, and how quickly unusual activity is stopped. We will update this note if Bloom publishes a post-mortem.

Sources#

Share this article

Related Articles

When the Server Lies: Electrum's Fee-Bump Attack

SecurityOct 26, 20264 min

When the Server Lies: Electrum's Fee-Bump Attack

A malicious Electrum server could swap a pending payment and wait for a fee bump. What the advisory confirms, what is unknown and what users should do.

Read article
Cysic Bridge Exploit: What the 10M CYS Mint Shows

SecurityOct 19, 20265 min

Cysic Bridge Exploit: What the 10M CYS Mint Shows

On 17 October an attacker minted 10M CYS through Cysic's bridge. What is verified, what is still unknown, and what it shows about bridge trust boundaries.

Read article