
Wallets that had not traded through Bloom for more than a year were among those drained in a near-$1 million theft, according to Bitquery’s investigation.
Bitquery’s October 26 investigation traced 9,408 SOL, worth approximately $953,000 during the attack, from 48 wallets. Half had not traded through Bloom in the preceding month; five last did so between January and May 2025.
Bloom has promised full reimbursement. In a later statement reported by AMBCrypto, it blamed a remote code execution vulnerability in a third-party module and denied that private keys were compromised. That type of flaw lets an attacker run unauthorized code within a software environment.
Old trading wallets remained within reach
Bitquery measured past Bloom use through trading-fee payments. No recent fee does not establish that an account was deleted, a wallet disconnected or all other transactions stopped.
The researchers grouped the addresses into nine traders, with two groups relying mainly on withdrawal order. 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, after 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 retain 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. It identified no token-approval trap in those withdrawals.
Solana’s transaction documentation explains that signatures authorize changes to accounts. The network verifies that authorization; 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 app from their routine while leaving the underlying credentials unchanged. The security effect depends on what they actually replace:
| Action | Effect on spending access |
|---|---|
| Stop trading or disconnect an app | Does not invalidate a private key previously shared or copied. |
| Import the same key into another wallet app | Preserves the same signing identity. |
| Revoke a token approval | Removes that permission, without invalidating the wallet’s key. |
| Create fresh keys and transfer assets | Places successfully transferred assets under different credentials. |
Phantom’s official migration guidance says 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 withdrawing from an application before they can move. Future deposits also need a new destination; otherwise, money 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 trying 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?



Be the first to comment