Hackers drain 9,408 SOL from 48 Bloom-linked wallets

Hackers drained 9,408 SOL from 48 wallets linked to Bloom, an automated trading service, on Oct. 26. Blockchain transaction analysis found that each transfer was signed by the affected wallet’s own private key, raising questions about copied key material or access to a system that could sign transactions.

The transfers occurred between 01:03:07 and 01:04:41 UTC. Each was a direct SOL transfer with no second signer or token approval. On Solana, a wallet controlled by one private key can authorize transfers when that key produces a valid signature.

Bloom said in an Oct. 26 update that private keys had not been accessed or compromised. The company attributed the incident to a remote-code-execution vulnerability in a third-party software module and said unaffected wallets remained safe.

Later that day, Bloom said it had fully refunded all nine affected users. The company reported repaying 9,408 SOL through nine transactions and said the funds were sent to secure wallets selected by the users.

Bloom’s documentation describes a withdrawal lock that prevents users from changing their withdrawal destination. Unlocking the address starts a 24-hour waiting period before a new destination can be set. The lock can block changes made through Bloom’s withdrawal process, but it cannot stop someone holding a wallet’s private key from creating a separate transaction.

A copied private key could therefore allow funds to be transferred without changing the withdrawal address saved in Bloom. Moving to another Bloom interface would not change that authority if the same key remained exposed. Bloom’s product materials say its Extension, Manager and Telegram products use the same execution engine.

The 48 wallets were linked to Bloom through earlier fee payments and grouped into nine traders. Twenty-four had paid no Bloom trading fee during the previous month, while five had last paid fees between January and May 2025. A pause in trading did not remove the wallets’ ability to sign transactions.

A separate TradeWiz incident illustrates the same wallet-control issue, without establishing a connection to Bloom. The Sept. 30 drain involved 20,793 wallets. Two affected addresses received new deposits and were emptied again within four seconds. Funds sent to an address with an exposed private key can be taken again.

Assets moved to a new wallet controlled by an uncompromised private key are no longer authorized by the old wallet’s key. Changing a service login or interface does not remove a copied private key from an attacker’s possession.