Hackers drained 9,408 SOL from 48 wallets tied to Bloom, an automated Solana trading service, in a sweep that lasted barely ninety seconds. According to blockchain analytics firm Bitquery, the transfers ran from 01:03:07 to 01:04:41 UTC on October 26, and every drain was a plain SOL transfer signed by the wallets’ own keys. No second signer, no token approval, no exotic exploit contract. Just the owner key itself, authorizing the movement of funds.
Bloom’s side of the story
Bloom has denied that private keys were accessed or compromised. In an October 26 update, the service attributed the incident to a remote-code-execution vulnerability in a third-party module and said unaffected wallets were safe. Later the same day, Bloom announced that all nine affected users had been fully refunded, claiming a total of 9,408 SOL across nine transactions, with funds sent to secure wallets designated by the users themselves.
That leaves two separate issues sitting side by side: compensation, which Bloom says is complete, and the question of what exactly had the authority to move funds out of those wallets in the first place.
The withdrawal lock that did not matter
Here is where the story gets uncomfortable for anyone who relies on trading bots. Bloom’s own documentation tells users to keep their withdrawal address locked. The FAQ says the address cannot be changed while locked, and unlocking starts a 24-hour cooldown before any change is allowed. It is a sensible safeguard against someone hijacking a compromised service account and redirecting withdrawals to their own address.
But the lock only protects the withdrawal process inside Bloom’s interface. When the same wallet key is used through a different path, it retains the same authority over the funds. An attacker who copied the key material could simply create a fresh transfer to a brand-new destination, bypassing the saved withdrawal address entirely. As Solana’s own developer documentation explains, a transaction needs valid signatures from the accounts authorizing it, and for a wallet controlled by one private key, whoever holds that key controls the funds.
Dormant wallets were not safe either
The age of the affected wallets gives this incident consequences far beyond active bot users. Bitquery found that 24 of the 48 drained wallets had paid no Bloom trading fee in the preceding month, and five had last paid one between January and May 2025. The analytics firm associated all 48 wallets with Bloom through historical fee payments and grouped them into nine traders, while acknowledging that two of those groupings rest mainly on the drain order itself.
The lesson is stark: if someone copied a wallet’s controlling key, a long pause in trading does nothing to stop them from signing a new transfer years later, as long as funds still sit at that address.
The TradeWiz precedent
A separate incident documented by Bitquery shows how persistent this exposure can be. In the TradeWiz drain, dated September 30, the analytics firm counted 20,793 wallets swept for SOL. Fee-paying bot trades stopped 41 minutes into the sweep, yet the draining bot still collected 73 percent of the main-sweep SOL afterward, harvesting from dormant addresses. Most striking, two drained TradeWiz addresses received fresh deposits and were emptied again within four seconds, because depositing into an address whose controlling key has escaped simply hands the new funds to the same attacker.
What crypto users should take from this
The core distinction is between changing your access to a service and changing the authority over your assets. Rotating a password, revoking a session, or locking a withdrawal address secures the service’s processes. None of those actions erase a copy of a private key already held somewhere else. If a key may have escaped, the only real fix is moving assets to a fresh wallet governed by a new, uncompromised key, and keeping that new key outside any signing environment the attacker might still reach. Importing the same secret into another app preserves the exact same exposure.
For anyone with an old bot wallet gathering dust, this incident is a reminder to sweep it. The nine Bloom users got refunded, but the next service may not be so quick to make users whole, and dormant keys do not expire just because the bot stopped trading.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice.
94 seconds for 9,408 sol across 48 wallets, every transfer signed by an owner key. the sweep was rehearsed, the wallets were just waiting
94 seconds, 48 wallets, every transfer signed by the owner key itself. the keys just walked out the front door
bloom says third party RCE but if that module could sign transfers then functionally the keys were compromised. same result either way
Functionally compromised is the right framing. Whether an RCE held the key or copied it, the signature is identical on chain. The denial is semantics.
all 9 users refunded the same day though. whatever the root cause was, that part they handled fast
94 seconds, 48 wallets, 9,408 SOL, every transfer signed by the owner key itself. No approval exploit, no second signer. The key was the vulnerability.
Bloom blaming remote code execution in a third party module while insisting keys were never compromised is doing a lot of work. If the key signed, something held the key.
exactly, if an RCE could invoke the key then the key was compromised in every way that matters. that wording is for lawyers not users
Credit where due, all nine users were refunded the same day. Still, dormant bot wallets are the ones nobody watches. Rotate old keys or pull funds off automation you stopped using.
24 of those wallets hadnt paid a fee in a month. people forgot the bots existed and still got drained lmao, brutal
had a 2021 arb bot sitting with live keys because i forgot it existed. read the bitquery timeline and moved everything the same hour. dormancy is the risk nobody prices in
The withdrawal lock only guards the withdrawal flow inside the Bloom UI. The same key used through any other path keeps full authority. Every bot user needs to internalize that.
Exactly this. People think the lock is a security boundary because the UI frames it that way. The key signs anywhere, the lock is just a feature flag inside one app.