Blockchain analytics firm Bitquery traced 9,408 SOL transferred from wallets belonging to nine traders during the October 26 incident. Bloom pledged to reimburse the affected users in full, but its explanation of the attack has not yet been independently reconciled with the transaction-level evidence.
Bloom attributed the incident to a remote code execution vulnerability in a third-party software module and said no private keys had been accessed or compromised. Bitquery, however, found that every outgoing transfer was signed using the affected wallet’s own key, without a token approval, smart contract or additional signer.
The blockchain evidence establishes that the transactions were authorized using the wallets’ signing keys. It does not establish how the attacker obtained that signing authority or whether private keys were extracted from the system.
How Were 48 Bloom-Linked Wallets Drained?
Bitquery’s investigation found that the attacker used a coordinated sequence of small test transfers before executing the main withdrawals. The operation targeted wallets associated with nine traders, with the script generally emptying each trader’s wallets from the largest balance downward.
The main drain unfolded in 94 seconds. In total, 9,408 SOL left the affected wallets, with the transfers valued at approximately $953,000 at the time of the incident. Bitquery said almost all the stolen SOL had accumulated in a single receiving wallet and remained there when its investigation was published.
The attacker focused on SOL, leaving approximately $57,000 in USDC across the affected wallets. Bitquery also found that 24 of the 48 wallets had not traded through Bloom during the preceding month. Five had not traded through the bot since the first half of 2025.
Those inactive wallets are particularly relevant because they suggest that stopping trading through the service did not necessarily remove the access associated with the wallets. The evidence does not establish precisely how that access was retained, but it shows why users should not assume that an abandoned trading wallet is secure simply because it is no longer active.
Investor Takeaway
The incident affected nine traders across dozens of wallets, including accounts inactive for more than a year. Discontinuing a trading bot does not necessarily eliminate the security exposure associated with its wallet access.
Does Bloom’s Explanation Resolve the Private-Key Question?
Bloom said the attack exploited a remote code execution vulnerability in a third-party module. Remote code execution allows an attacker to run commands within a vulnerable software environment, potentially providing access to functions or resources available to that environment.
However, Bloom has not publicly provided enough technical detail to explain how the reported vulnerability enabled the attacker to authorize the transfers while maintaining that no private keys were accessed or compromised.
Bitquery’s findings do not independently prove that the keys were copied or extracted. A valid signature demonstrates that the transaction was authorized by the relevant key, but it does not establish how the attacker obtained the ability to use it. Compromised software surrounding a signing process could potentially create unauthorized transactions without requiring an attacker to extract a key directly.
A similar distinction emerged in the Bitget security breach, where investigators examined the transaction-signing trust chain rather than a straightforward private-key theft. The technical details differ, but both cases illustrate why the security of the systems that authorize transactions matters alongside the protection of cryptographic keys.
Bloom said it was investigating the incident and took its systems offline as a precaution. It also said unaffected wallets remained safe, although users should distinguish that assurance from an independently verified technical assessment of the vulnerability.
Will Bloom Reimburse the Affected Traders?
Bloom pledged to reimburse all affected users in full, with compensation sent directly to new, secure wallets designated by the traders. The company said it would cover the losses itself rather than rely on a community-funded relief effort.
The reimbursement commitment addresses the immediate financial consequences, but a promise to repay does not establish that the funds have already been returned. Bloom has not provided a confirmed completion date for all reimbursements in the information reviewed.
The incident also follows earlier attacks involving automated cryptocurrency trading services. In September 2024, Telegram trading bot Banana Gun reported a hack that initially involved approximately $1.9 million in losses, before its subsequent reimbursement announcement addressed a reported $3 million total. Such cases show that trading automation can introduce security risks beyond those associated with the underlying blockchain itself.
Investor Takeaway
Full reimbursement would limit the direct losses for affected Bloom users, but the longer-term test is whether the company can establish the root cause and demonstrate that its signing infrastructure is secure before services resume.
Why Does the Incident Matter for Telegram Trading Bots?
Telegram trading bots allow users to execute trades rapidly without manually approving every transaction. That convenience often depends on the bot holding or accessing the private keys required to authorize trades, creating a different risk profile from a wallet in which the user retains exclusive control of the keys.
The same broader exposure has appeared in other attacks targeting cryptocurrency users through messaging applications and trading software. FinanceFeeds previously examined macOS malware capable of compromising Telegram sessions and accessing cryptocurrency wallet data, illustrating how risks can arise from the software and devices surrounding a transaction rather than from a blockchain protocol itself.
For users, the practical distinction is between controlling a wallet and delegating the ability to transact from it. Funds held in a wallet accessible to an automated service remain exposed to weaknesses in the service’s software, infrastructure or access controls.
Bloom’s next important disclosures will be a more detailed technical explanation, evidence of completed reimbursements and a clear account of the safeguards required before trading resumes. Until those details emerge, the confirmed findings remain that 9,408 SOL was drained from 48 Bloom-linked wallets in 94 seconds and that the company has committed to covering the affected traders’ losses.
