An October 26 investigation by blockchain analytics firm Bitquery traced 9,408 SOL — worth approximately $953,000 at the time of the attack — out of 48 wallets tied to the Bloom trading bot. According to the invest, half of the affected wallets had not traded through Bloom during the preceding month, and five had last done so between January and May 2025.

Bloom has promised full reimbursement. In a later statement reported by AMBCrypto, the company attributed the incident to a remote code execution vulnerability in a third-party module and denied that private keys were compromised. That type of flaw allows an attacker to run unauthorized code within a software environment. A third-party module, in turn, is a component a service incorporates rather than writes itself — meaning the flaw sat outside code the operator authored directly, yet inside the environment the operator runs.

Old trading wallets remained within reach

Bitquery measured past Bloom usage through trading-fee payments. The absence of a recent fee does not establish that an account was deleted, that a wallet was disconnected, or that all other transactions had stopped.

The researchers grouped the drained addresses into nine traders, with two groups relying mainly on withdrawal order for identification. Bloom's reported count was 49 affected addresses across nine users, compared with Bitquery's 48 drained wallets.

The main drain ran from 01:03:07 to 01:04:41 UTC, following preliminary tests — less than two minutes between the first full withdrawal and the last.

For anyone leaving an automated trading service, the relevant question is what access survives the final trade. A wallet can still hold assets while the infrastructure previously used to sign its transactions remains available. Months without trading do not, by themselves, demonstrate that this access has ended.

The signatures show spending authority, not how it was obtained

Bitquery found ordinary SOL transfers bearing each source wallet's own signature and identified no token-approval trap in the withdrawals. Solana's transaction documentation explains that signatures authorize changes to accounts. The network verifies that authorization, but it cannot establish whether the human owner intended the payment or whether someone abused a service capable of signing it.

A stolen private key and a compromised signing system can both produce valid signatures. In the second case, an attacker might cause software to authorize a transfer without extracting the key itself. That is a possible mechanism, not an independently verified explanation of the Bloom incident.

Bloom's reported denial of a key leak therefore cannot be resolved by pointing to the signatures alone. A fuller technical account would need to explain how the third-party module reached the signing process and why particular wallets were affected.

Changing wallet apps does not change the keys

Traders can remove an application from their routine while leaving the underlying credentials unchanged, and the security effect depends on what is actually replaced. Phantom's official migration guidance states that an existing recovery phrase cannot simply be changed; starting over requires a new wallet and asset transfers.

The same credential problem applies to restoring an exposed recovery phrase on a replacement device: the hardware changes, but an attacker's copy remains usable. That separate Ledger case involved a different attack method.

Retiring a wallet means checking more than its SOL balance

Phantom advises reviewing tokens, collectibles, staking and DeFi positions before abandoning a wallet. Some holdings require unstaking or withdrawal from an application before they can move. Future deposits also need a new destination; otherwise, funds can keep arriving under the old credentials.

There is an important exception to ordinary migration instructions. If funds disappear immediately after deposits, an automated sweeper may be active. Phantom's sweeper guidance warns against adding more funds or attempting to outrun it. The Bloom investigation does not establish that every affected wallet had such a sweeper.

Keeping long-term holdings separate from a bot's trading balance limits the amount exposed through that service. It also makes departure easier: users can identify what remains under automated signing access instead of treating an unused account as a retired wallet.

For Bloom's affected users, reimbursement remains a commitment until payments are confirmed. The security question is separate: what unauthorized access enabled the withdrawals, and what has been changed to prevent another transaction from being signed?

Source: Coindoo