Bloom Says 'No Private Keys Were Compromised.' Every One of the Drains Was Signed With the Wallet's Own Key, and It Took 94 Seconds

Bloom, a Solana trading bot, put out a security update on Monday with three promises:

“No private keys were compromised, unaffected wallets are safe, and all affected users will be fully reimbursed by Bloom.”

On-chain analytics firm Bitquery then traced the theft. Its finding was that every outgoing transfer was “a standard SOL transfer signed with the source wallet’s own key, with no token approval, smart contract or additional signer involved.”

So the bot says the keys weren’t compromised, and the chain shows the attacker signing with them. Whatever the full explanation turns out to be, someone other than the owners was able to sign for 49 wallets, and it took 94 seconds to empty them.

---

What Happened

Platform	Bloom (BloomTrading), a Solana trading bot used through Telegram, Bloom Manager and a Chrome extension
When	October 26, 2026. Onchain Lens flagged the outflows at 04:26 UTC
Stolen	9,408 SOL, about $947,000 by Bloom’s figure ($953K–$954K by on-chain estimates)
Victims	9 users across 49 wallets per Bloom (Bitquery counted 48)
Largest single loss	1,636 SOL, about $166,000
Drain time	94 seconds (Bitquery)
Left behind	About $57,000 in USDC (Bitquery)
Bloom’s explanation	A remote code execution (RCE) vulnerability in a third-party module
Status	All systems offline. Bloom has promised 100% reimbursement

---

How the Drain Played Out

Bitquery’s investigation describes an attack that was prepared in advance:

• Test transfers first. The attacker “first sent small test transfers from one wallet linked to each trader before beginning the main drain.”
• Biggest balances first. The script “emptied wallets trader by trader, generally moving from the largest balance downward.”
• SOL only. The attacker moved only SOL and left roughly $57K of USDC behind.
• One holding wallet. Almost all 9,408 SOL ended up in a single wallet, and when Bitquery checked, it hadn’t been moved again.

Then there’s the detail that should worry every bot user. Per Bitquery, half of the 48 wallets hadn’t traded through Bloom in the previous month, and five hadn’t traded through Bloom since the first half of 2025.

Those users had stopped using the bot, in some cases more than a year ago. Whatever gave the attacker signing power still covered their wallets.

---

”No Private Keys Were Compromised” vs. What the Chain Shows

Bloom’s position, in its post on X, is that a third-party RCE vulnerability caused the breach and no private keys were compromised. It hasn’t named the third-party provider or explained how the RCE led to signed transfers.

Bitquery stays careful on this point: “The blockchain proves valid key-based authorization but does not establish how that authority was obtained.”

That leaves room for an explanation that fits both statements. If the attacker ran code inside a system that could already sign for those wallets, it could produce valid signatures without ever copying a key out. For a user, though, there isn’t much difference: the attacker could sign for your wallet, so the wallet wasn’t safe.

As investingLive put it: “Until Bloom publishes a root cause, the claim that keys were not exposed should be read as the company’s position rather than a confirmed finding.”

---

What Bloom Is Doing

• Everything is offline. Bloom’s words: “All Bloom systems are currently offline as a precautionary security measure.” When it comes back, all users “will be required to log in again to Bloom Manager and the Chrome Extension.”
• Full refunds. “Bloom will fully reimburse 100% of the stolen funds directly to secure wallets designated by the affected users.” According to crypto.news, Bloom turned down a community relief fund and said it would cover the losses itself. There’s no payment date yet.
• Tracing. Bloom says it’s tracing the funds, exploring freezing and recovery options, and trying to identify the attacker. It hasn’t said whether anything has been frozen or recovered.
• New keys. Bloom has told users to move any remaining funds to new wallets with freshly generated keys.

---

What To Do If You Use a Trading Bot

• Treat any wallet a bot can sign for as a hot wallet. Keep in it only what you’re actively trading.
• Revoke or rotate wallets you’ve stopped using. Several of the drained Bloom wallets had been inactive for more than a year. A wallet you stopped using can still be drained if the bot can sign for it.
• Don’t reuse a bot wallet after a security incident. Generate a new one, as Bloom itself advises.
• Watch out for “refund” phishing. Fake reimbursement forms and “claim your refund” DMs tend to show up within hours of a hack like this. Only follow Bloom’s official channels.

---

Why This Matters for Crypto Jobs

Bot teams are now handling signing infrastructure, whether they planned to or not. A Telegram bot that can sign for user wallets is effectively a hot-wallet custodian. That means hiring for key management, HSM/MPC and signer-isolation engineers, the people who make sure a code execution bug somewhere else can’t turn into signed transactions.

Key lifecycle is a missing role. This attack worked partly because the bot could still sign for wallets nobody was using. Products need someone who owns session expiry, permission revocation and dormant-wallet policy. Exchanges and custodians already have that job. Most bot teams don’t.

Third-party dependency risk is a job too. Bloom blames a third-party module. Every bot is built on RPC providers, SDKs and libraries, and teams that hold signing power need supply-chain and AppSec engineers who audit what goes into the signing process.

On-chain investigators keep getting the first word. Bitquery and Onchain Lens had the attack timeline, the ordering and the holding wallet mapped before Bloom gave its root cause. Blockchain forensics and incident response remain some of the most in-demand security roles.

---

The Bottom Line

Bloom may well pay everyone back, and that would be the right thing to do. But “no private keys were compromised” doesn’t help much when the chain shows 49 wallets signing away their SOL in a minute and a half, including wallets their owners had stopped using a year earlier. If a bot can sign for your wallet, the bot’s security is your security. Keep bot wallets small, and stop using any you don’t need.

---

Want to build signing infrastructure that holds up when a dependency fails? Browse open security and Solana engineering roles on Cryptogrind →