Skip to content
PANTHER

Bloom Says Keys Weren’t Stolen. 9,408 SOL Still Left.

Bloom attributes its wallet drain to a third-party RCE flaw and promises refunds. The chain verifies movement—not whether private keys were stolen.

By Panther@0xPnthr

3 min read

PANTHER JOURNAL #061: conceptual illustration of a Solana coin in a black glass wallet beneath an old key. THE KEY STILL WORKED.
AI-generated conceptual illustration for Panther Journal; not documentary evidence.

Key points

  • Bloom reports 49 addresses across nine users and attributes the attack to third-party RCE, denying private-key compromise.
  • We independently checked the finalized consolidation transfer of 9,408.209917593 SOL.

The signature was valid. The transfer was not what the owner wanted.

That is the warning in the Bloom trading bot wallet drain reported on October 26. Roughly 9,408 Solana ($SOL) was taken, according to independent reporting. Bloom promises full reimbursement and now attributes the incident to a third-party module, while denying that private keys were accessed.

Bloom wallet drain: what the company says

In its October 26 statement, Bloom committed to repay losses directly to new wallets selected by affected owners. That initial reply was superseded by a security update at 09:12 UTC. Bloom reports 49 addresses belonging to nine users, approximately 9,408 SOL lost, and a remote code execution (RCE) vulnerability in a third-party module. It says no private keys were accessed or compromised and broader exposure has been ruled out. These are the company’s findings; Panther has not audited the underlying systems.

That is a reimbursement commitment, not evidence that repayments have arrived. The public statement does not provide enough technical detail for us to independently reproduce its forensic conclusion. We have not verified completed refunds.

Crypto Briefing independently reported approximately 9,408 SOL lost from roughly 48–49 user wallets, with some services paused. The difference between wallet counts matters: one person may operate several addresses. It should not become an inflated count of separate victims.

The transfer readers can check themselves

We independently inspected the consolidation transaction on Solscan. At 04:30:56 UTC on October 26, it records a finalized transfer of 9,408.209917593 SOL from collecting address 7kY8qx8MqJ7Rz2vMhgHETdZLHcTp1oM78AA9dmE9p8BQ to 6nYyCzJJzErbmfxvXqzbAqwoBzNvXUiwr15KCkcgmoe9.

The receipt establishes that movement. Attribution of the collecting address to this incident comes from the published investigation, not from a blockchain label proving a human identity. The transfer alone does not prove how unauthorized signing was enabled or who directed it.

Dollar loss estimates around $950,000 reflect SOL prices near the incident. They are not an additional loss on top of the SOL total.

A valid signature does not prove a stolen key

Bitquery’s investigation counted 48 drained wallets and grouped them into nine traders. It reported a 94-second drain and found that some addresses had not traded through Bloom since the first half of 2025. Its grouping is stronger for some traders than others, and its transfer review ends at 07:34 UTC on October 26.

The historical-wallet finding warrants attention, but it does not settle the intrusion route. An attacker could obtain a key, or abuse software authorized to sign without exporting that key. On-chain transfers alone cannot distinguish those scenarios. Bloom explicitly denies the first.

Pausing software can interrupt an abused signing service. If a key actually has leaked, a software pause cannot revoke the copy. Those are different threat models. Separating bot trading balances from longer-term holdings limits what a single compromised signing environment can reach. A newly generated wallet only provides that separation when its secret is kept outside the affected environment.

A cause under investigation is not a verdict

Bloom now says it has identified an RCE vulnerability. RCE means an attacker can run code in an environment they should not control. That is compatible with unauthorized transactions without proving key exfiltration. We have not verified the module’s identity, the exploit implementation or an independent postmortem. An insider accusation would outrun this evidence.

The same discipline applies to rescue claims. Refunds should be checked through actual payments and authenticated instructions. A fresh address supplied by an unsolicited support account is not proof of legitimate assistance. Never supply a recovery phrase to claim reimbursement.

Panther’s wallet recovery-phrase guide explains the distinction between an account password and the secret that authorizes blockchain transfers.

Panther Takeaway

A wallet can lose funds even when its secret was never exported. The permission to sign is itself valuable. Bloom’s promised refunds matter; the larger lesson is to scrutinize every service that can authorize transfers, not just where a recovery phrase is stored.

PANTHER JOURNAL #061. Verified October 26, 2026. Transaction movement checked independently; wider wallet counts and activity history attributed to their sources.

Responses

Links, wallet addresses and contact details are not allowed.

0/1000

No responses yet. Start the conversation.

Panther Journal — The intelligence brief

Stay ahead of the story.

Free. New investigations delivered when published. Unsubscribe anytime.

Launching something?

Work directly with Panther.

Start a project

More from Panther Journal