Bloom refunds 9,408 SOL after 48 bot wallets drained

Bloom, an automated trading service on the Solana blockchain, has fully refunded nine users for a total of 9,408 SOL lost from 48 linked wallets. The company stated that the incident was caused by a remote-code-execution vulnerability in a third-party module and denied that private keys had been directly accessed or compromised.

On-chain analysis by Bitquery indicates that the funds were moved through plain SOL transfers signed by the wallets’ own keys. The full drains occurred between 01:03:07 and 01:04:41 UTC on Oct. 26. Bitquery noted that no second signer or token approval was involved in these transactions, meaning the transfers were authorized solely by the private keys controlling the affected addresses.

Withdrawal Locks and Key Authority

Bloom’s documentation describes a withdrawal-address lock designed to prevent changes to a user’s withdrawal destination while the lock is active. Unlocking this address initiates a 24-hour cooldown period before any changes are permitted. This safeguard is intended to protect users if their service account is compromised, preventing an attacker from redirecting withdrawals through the standard service interface.

However, Bloom acknowledged that a copied private key retains authority over the funds regardless of the service’s internal settings. The company’s product homepage states that its Extension, Manager, and Telegram products share a common execution engine. Consequently, if the same wallet key is used across different interfaces, it maintains the same authority over the assets. An attacker who possesses a copy of the private key can create a fresh transfer to a different destination without needing to alter the withdrawal address saved within the Bloom platform.

Solana’s technical documentation explains that a valid owner-key signature can be consistent with either copied key material or the misuse of a signing path. Because the transfers were signed by the wallets’ own keys, determining the exact route to the signing authority remains unresolved. Bloom stated that changing access to the service does not erase a copy of a private key that has already been held elsewhere.

Refunds and Inactive Wallet Exposure

Bitquery found that 24 of the 48 affected wallets had not paid a Bloom trading fee in the month preceding the incident. Five other wallets last paid a fee between January and May 2025. The analysis grouped the 48 wallets into nine distinct traders based on earlier fee payments, although it acknowledged that two of these groups relied primarily on the drain order for their association with the service.

The presence of long-inactive wallets in the breach highlights that a pause in trading activity does not prevent an attacker with a copied key from signing new transfers if funds remain in the address. Bloom announced on Oct. 26 that all nine affected users had been fully refunded, linking nine transactions totaling 9,408 SOL. The company stated that the funds were sent to secure wallets designated by the affected users.

A separate incident involving TradeWiz occurred on Sept. 30, where 20,793 wallets were drained of SOL. In that case, fee-paying bot trades stopped 41 minutes into the sweep, but the bot continued to take 73% of the main-sweep SOL afterward. Two drained TradeWiz addresses received new deposits and were emptied again within four seconds, demonstrating that depositing into an address after its controlling key has escaped can place new funds under the same attacker’s authority.

For users managing bot wallets, the distinction between changing service access and changing asset control is critical. Moving assets to a fresh wallet governed by an uncompromised key removes the assets from the authority of the old key. Conversely, importing the same secret into another application or returning funds to the old address preserves the existing exposure.