# Bloom hack drains 9,408 SOL; full refunds promised Author: Abdullah Özkurt Language: English Published: 2026-10-26T17:54:32+03:00 Updated: 2026-10-26T18:25:23+03:00 ![Particles escape from a purple connector on a metal server module, a conceptual scene representing the Bloom security incident.](https://kriptometa.com/uploads/bloom-da-sol-calindi-tam-iade-sozu-c9e5639530cb_article.webp) ## Key takeaways - Bloom says 49 wallet addresses belonging to nine users lost about 9,408 SOL, valued at $947,000 in its statement. - The company attributes the incident to remote code execution and says other wallets were not exposed. It has not named the module or released a detailed technical report. - Refunds will go to secure wallets designated by affected users. Bloom also offered to negotiate terms for the attacker to return some funds; it has not announced completed repayments. Bloom says an attacker exploited a third-party software module. The company denies that private keys were compromised and has promised to cover the losses of all nine affected users. Trading platform Bloom said on October 26 that 49 [wallet addresses](https://kriptometa.com/en/glossary/wallet-address) belonging to nine users had lost roughly 9,408 SOL. According to its [latest security statement](https://x.com/BloomTrading/status/2114646392010359238), the attacker exploited a remote code execution vulnerability in a third-party module. Bloom pledged to cover the losses in full but did not give a firm repayment schedule. Users can trade on [Solana](https://kriptometa.com/en/glossary/solana-sol) and Ethereum-compatible (EVM) networks through Bloom’s web interface, browser extension and Telegram [trading bot](https://kriptometa.com/en/glossary/crypto-trading-bot). The platform provides wallet management, copy trading and automated orders through [connected tools](https://docs.bloombot.app/). The company reported the stolen amount in SOL; it did not say every supported network had been attacked. ## Bloom blames a third-party module In its statement at 09:12 UTC, Bloom said it had identified the attack method and confirmed which wallets were affected. It said the attacker had not accessed [private keys](https://kriptometa.com/en/glossary/private-key), unaffected wallets were safe and broader exposure had been ruled out. The company had said earlier that morning that it was investigating the cause. Bloom reported its own findings; it did not release an independent audit report. Remote code execution, or RCE, lets an attacker run code on another system. [OWASP](https://cornucopia.owasp.org/cards/AZQ) identifies unauthorized server-side code execution as a software security risk. Bloom has not identified the module or provider, supplied a vulnerability identifier or explained the technical fix. The company has not yet explained in a detailed incident report how the attacker used RCE to obtain signed transfers. > “No private keys were compromised.” Bloom’s assessment in its October 26 statement. ## 49 wallets belong to nine users Bloom corrected the victim count reported earlier that morning. Blockchain monitoring account [Onchain Lens referred to 49 victims at 04:26 UTC](https://x.com/OnchainLens/status/2114574282282160371). In a [clarification at 06:05 UTC](https://x.com/BloomTrading/status/2114599403059122649), Bloom said the 49 wallets belonged to nine individuals. The affected people used multiple wallets, so 49 addresses did not represent 49 separate users. Onchain Lens valued the roughly 9,408 SOL stolen at $954,000 in its morning post. Bloom later used $947,000 for the same amount. The dollar figures reflect the sources’ valuations at the time of their announcements, not a current market quote. Scope and repayment commitments in the October 26 announcements. | Issue | What Bloom says | What remains undisclosed or unfinished | |---|---|---| | Affected users | 49 addresses belonging to nine users | The users have not been publicly identified | | Loss | About 9,408 SOL, valued by Bloom at $947,000 | The $947,000 estimate dates to Bloom’s announcement | | Attack method | RCE through a third-party module | No named module, provider or detailed technical report | | Refunds | 100% of stolen funds | No firm payment date or completion announcement | | Recovery | The company is tracing funds and exploring ways to recover or freeze them | No announcement that funds have been recovered or frozen | Bloom says it will send refunds directly to [secure wallets](https://kriptometa.com/en/choose-crypto-wallet) designated by affected users. It had said earlier that it would cover losses verified as linked to the attack. It has not explained what evidence users must provide or the order in which it will pay them. The company did not limit its full-refund promise to whatever it might recover from the attacker. ## What does the on-chain research show? In its [October 26 investigation](https://bitquery.io/investigations/bloom-trading-bot-hack), Bitquery reported that 9,408.23 SOL left 48 wallets between 01:03:07 and 01:04:41 UTC, a span of 94 seconds. Bloom put the number of affected addresses at 49. Seeing each transfer [signed by its wallet’s own key](https://kriptometa.com/en/glossary/digital-signature), Bitquery inferred that the attacker held the keys. Bloom later denied that any private keys had been compromised. Bitquery also tracked 9,408.21 SOL to a second address at 04:30:56 UTC, with no outgoing transfer by 07:34 UTC. The published figures do not show whether the funds remain at that address or have been frozen. KriptoMeta did not conduct an independent chain scan. Users can manage several wallets within one Bloom account, create new wallets and import existing ones through the Telegram bot. In its [official wallet guide](https://docs.bloombot.app/manager/pages/wallets), Bloom asks users to store private keys securely and says it cannot recover lost keys. Users who hold their own private keys can still be affected by flaws in the trading software. **The fresh-wallet warning came earlier in the morning.** At 06:05 UTC, Bloom recommended moving remaining funds to wallets with newly generated private keys. At 09:12 UTC, it said unaffected wallets were safe. It did not provide a separate refund application link or payment deadline. ## Bloom seeks talks over a partial return In an [appeal to the attacker at 12:41 UTC](https://x.com/BloomTrading/status/2114698963508961652), Bloom offered direct, confidential discussions. The company said it had collected technical evidence, including IP addresses and data centers used in the attack. Bloom said it was willing to discuss refraining from legal action within its control if the attacker returned some funds. Any agreement would have to comply with applicable law and terms accepted by both sides. The offer covers only legal action within Bloom’s control; it does not grant immunity from investigations by other parties. Bloom has not announced that the attacker accepted or returned any funds. The company has not set firm dates for user repayments, asset recovery or restoring all service functions. In the October 26 post below, Bloom describes the attack method, gives the affected user count and promises full refunds. [Bloom’s October 26, 2026 security statement](https://x.com/BloomTrading/status/2114646392010359238)