Bot de trading Bloom: 9.408 SOL retirados, qué vigilar ahora

El bot de trading de Telegram Bloom comunicó el 26 de octubre de 2026 una salida de 9.408 SOL. Según el propio análisis de Bloom, están afectados nueve usuarios con 49 direcciones de monedero. El proveedor señala como punto de entrada una vulnerabilidad de ejecución remota de código en un módulo de un tercero, promete el reembolso íntegro y ha apagado todos sus sistemas por precaución.

Para ti, como usuario de un bot de trading, el dato decisivo no es la cifra, sino la arquitectura que hay detrás: en Bloom es el proveedor quien genera la clave privada, no tú. Eso es precisamente lo que separa un monedero de bot de un monedero del que dispones tú mismo, y es precisamente lo que decide de quién es, al final, un incidente así.

Salida en Bloom: 9.408 SOL desde 49 direcciones de nueve usuarios

La cantidad es la misma en los dos informes analizados: 9.408 SOL. En el contravalor las cifras divergen, porque se calcularon en momentos distintos. Bloom cifra el daño en unos 947.000 dólares, según Bitcoin.com News, mientras que un primer análisis de las transacciones llegó a unos 954.000 dólares. Queda por tanto una horquilla de 947.000 a 954.000 dólares, y quien la convierte en un millón redondo calcula a la ligera.

También el número de perjudicados merece una mirada precisa. Las primeras informaciones hablaban de 49 víctimas. Bloom lo ha matizado después: se trata de nueve usuarios que controlaban en conjunto 49 direcciones. Cryptobriefing menciona una horquilla de 48 a 49 direcciones afectadas. La mayor salida individual ascendió a 1.636 SOL, es decir, unos 166.000 dólares, medidos por la cuenta de vigilancia Onchain Lens y citados por news.bitcoin.com. Algunos operadores afectados informaron de pérdidas de hasta 80.000 dólares.

Un servicio de vigilancia llamado Onchain Alert considera que la suma final podría ser más alta, porque los fondos se agruparon en un monedero presuntamente de vaciado. Es una valoración, no una cifra establecida, y aquí figura como tal.

Ejecución remota de código: Bloom señala un módulo de un tercero

Bloom atribuye el incidente a una vulnerabilidad RCE compleja. RCE significa remote code execution, es decir, una debilidad que permite a un atacante ejecutar su propio código en un servidor ajeno. Quien tiene esa capacidad actúa en el servidor con los mismos derechos que el software que allí corre.

El origen de la vulnerabilidad no cambia nada para los afectados

Que la debilidad estuviera en un módulo adquirido y no en el código propio resulta indiferente para quienes perdieron fondos. Técnicamente, un servicio ejecuta todo lo que corre en su nombre, bibliotecas de terceros incluidas. Qué punto de acceso se forzó exactamente, Bloom no lo había revelado a la fecha de este análisis. Cryptobriefing deja constancia expresa de que hasta ahora no hay una causa confirmada y de que los usuarios afectados sospechan que la debilidad está en el propio servicio, sin que eso se haya comprobado.

Monedero custodiado: en los bots de Telegram el proveedor genera la clave

Aquí está la parte de la historia que va más allá de este único incidente. Un bot de trading de Telegram pretende ser rápido. Y lo es porque puede firmar órdenes sin pedir confirmación, y solo puede firmar si la clave privada está accesible allí donde el bot corre. Cryptobriefing describe por eso a Bloom como un servicio que genera él mismo las claves privadas de sus usuarios, y nombra los riesgos conocidos de esa arquitectura: claves presentes en el lado del servidor y cuentas de Telegram secuestradas.

Un monedero custodiado es un monedero en el que un tercero guarda la clave y dispone en tu lugar. Así es en un mercado de criptomonedas y también en un bot de trading. Entonces tienes un derecho de crédito frente al proveedor, no un acceso inmediato a las monedas. Qué proveedores de bots custodian de qué manera y qué cuestan lo pone uno al lado del otro nuestro panorama de bots de trading cripto.

Ninguna clave privada salió: el punto abierto en el relato

Según el informe de news.bitcoin.com del 26 de octubre de 2026, Bloom declaró en X que no había salido ninguna clave privada, que los monederos no afectados estaban seguros y que todos los perjudicados serían reembolsados por completo.

Con ello queda una pregunta abierta, y la plantea el propio informe: si no salió ninguna clave, ¿cómo obtuvo entonces el atacante la facultad de mover los fondos? Una transferencia en la blockchain de Solana solo se ejecuta si está firmada con validez. Ambas afirmaciones encajan si la clave nunca abandonó el servidor, pero allí era utilizable por el atacante. Bloom no lo había aclarado a la fecha de este análisis, y sin divulgación la laguna del relato permanece. Lo que realmente ocurrió no puede deducirse de ahí.

Para ti eso tiene una consecuencia sobria. La garantía de que los monederos no afectados están seguros se apoya en la misma investigación que todavía no ha podido nombrar la causa. Es un compromiso del proveedor, no un hallazgo comprobado.

SOL salió, USDC se quedó donde estaba

El atacante no se llevó todo lo que había en las direcciones. Según los primeros análisis que resume Cryptobriefing, la salida apuntó casi en exclusiva a SOL, mientras que los saldos en USDC de esos mismos monederos quedaron intactos.

Esa selección es reveladora. Quien trabaja con prisa se lleva el activo que puede moverse más rápido y con menos fricción. Una stablecoin de un emisor identificado puede congelarse a petición; SOL no. Que los saldos en stablecoins se quedaran apunta por tanto a una decisión deliberada del atacante y no a un descuido.

Reembolso al 100 %: Bloom no ha fijado ningún plazo

Bloom se ha comprometido a asumir el daño completo, y a pagarlo en monederos que los propios afectados designen. No hay ningún plazo sobre la mesa. news.bitcoin.com constata que no se ha fijado fecha para el reembolso, ni momento alguno para la vuelta de los servicios.

En paralelo, el proveedor rastrea los fondos, examina las posibilidades de congelación y recuperación e intenta identificar al atacante. Anuncios de este tipo son habituales en incidentes de esta magnitud. Por el momento, lo único sólido de ese compromiso es que se ha dado.

MiCA y custodia: qué rige para las claves ajenas en Alemania

Quien custodia y administra criptoactivos por cuenta de otros en la Unión Europea presta con ello un servicio de criptoactivos en el sentido del reglamento MiCA, y necesita una autorización para ello. En Alemania la autoridad competente es la BaFin, y los proveedores autorizados figuran en un registro público que mantiene la autoridad europea de mercados ESMA. Si un servicio que usas está inscrito allí puedes comprobarlo tú mismo; este artículo no se pronuncia al respecto.

La segunda parte importa igual: una autorización no es un fondo de garantía de depósitos. Los 100.000 euros protegidos por cliente en un banco no se aplican a los criptoactivos, tampoco en un custodio autorizado. Un compromiso de reembolso como el de Bloom es por tanto una prestación voluntaria de la empresa y no un derecho derivado de un sistema de garantía.

Qué preguntas cuentan antes de activar un bot

Tres puntos se aclaran antes del primer ingreso, no después: quién genera la clave, dónde está y qué importe es accesible para el bot en cada momento. En el tercer punto tienes tú mismo la mano en la palanca, con independencia de lo que prometa un proveedor.

Autocustodia en lugar de monedero de bot: la diferencia en el control de la clave

Autocustodia significa que la clave privada está solo en tu poder y que ningún software de un tercero puede usarla. Un monedero de hardware lo impone guardando la clave en un chip que nunca la entrega; la firma se hace en el dispositivo, tras confirmación en el dispositivo. Qué modelos lo resuelven de qué manera y qué cuestan figura en nuestra comparativa de carteras de hardware.

Esta arquitectura es más lenta que un bot, y ese es su propósito. Un bot que firma sin confirmación puede comprar y vender en segundos; pero el mismo mecanismo trabaja también para cualquiera que consiga acceso al entorno de ejecución. La decisión se reduce por tanto a una ponderación entre velocidad y control de la clave, y no tiene que ser la misma para todo tu saldo.

Lo habitual es una división en dos. En el monedero de operaciones está el importe que el bot debe mover, y nada más. El resto está en un monedero al que no tiene acceso el software de ningún proveedor. En el caso de Bloom esa separación no habría impedido la salida, pero habría limitado el importe accesible. Esa es la parte del riesgo de la que dispone el usuario en solitario.

Bloom Manager y extensión de Chrome: nuevo acceso tras el reinicio

Para el periodo posterior a la reanudación, Bloom ha hecho un anuncio que afecta a todos los usuarios, también a quien no se vio afectado. En cuanto los servicios vuelvan, todos los usuarios tendrán que acceder de nuevo en Bloom Manager y en la extensión de Chrome. Los afectados deben contactar con el soporte y trasladar los valores restantes a monederos recién creados; así recoge news.bitcoin.com las instrucciones del proveedor.

Esta fase es el momento en el que, por experiencia, arranca el phishing. Una invitación a volver a acceder es una plantilla para los atacantes, porque es auténtica. Todo mensaje que te presione para acceder o para introducir una frase de recuperación lo tratas por tanto como un intento de fraude, hasta que hayas comprobado la dirección de forma independiente. Tras la fuga de direcciones de entrega en un fabricante de monederos en octubre, la misma maniobra ya se había puesto en marcha.

Salida en Bloom: sin claves propias solo queda el compromiso de reembolso

De este incidente se desprenden tres pasos, y valen con independencia de que uses Bloom o no:

1. Limita el saldo en los monederos de bot. Deja accesible solo el importe que el bot deba mover en los próximos días. Qué proveedor custodia de qué manera lo muestra la comparación de bots de trading.
2. Pon el resto bajo tu propio control de claves. Un dispositivo que no entrega la clave cierra la vía que aquí ha quedado abierta. Los modelos y sus costes figuran en la comparativa de carteras de hardware.
3. Elige el mercado por su forma de custodia. Quien opera sin bot necesita un proveedor con custodia trazable y autorización; los candidatos figuran entre los exchanges de criptomonedas regulados.

(27 de octubre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)