Owner-key signatures and old bot wallets reveal the stakes of service controls, while Bloom denies private-key compromise.

Bitquery’s reconstruction reports that 48 wallets associated with Bloom, an automated trading service, lost 9,408 SOL through transfers signed by the wallets’ own keys.

Bloom documents a lock that prevents changes to a user’s withdrawal destination, yet a copied key can authorize transfers outside that service interface.

In an Oct. 26 update, Bloom denied that private keys had been accessed or compromised. The account attributed the incident to a remote-code-execution vulnerability in a third-party module and said unaffected wallets were safe.

Later on Oct. 26, Bloom announced that all nine affected users had been fully refunded, claiming a total of 9,408 SOL and linking nine transactions.

That leaves two separate issues for users: compensation for the loss and the authority that could move funds from a wallet.

Bloom’s FAQ tells users to keep their withdrawal address locked, saying that the address cannot be changed while locked and that unlocking starts a 24-hour cooldown before changes are allowed.

The withdrawal guide places Set Address, Lock Address, and Unlock Address in the Withdraw menu, accessible from the home screen or through the /withdraw command. The documented safeguard delays replacement of the destination used in that process.

The lock gives someone with a compromised service account a barrier against withdrawal redirection through that process.

Bloom’s product homepage describes the Extension, Manager, and Telegram products as sharing an execution engine. When the same wallet key is used through a different interface, it retains the same authority over the funds.

Source link