El hackeo del bot Bloom en Solana ha dejado 9.408 SOL en manos ajenas en apenas 94 segundos. Son unos 953.000 dólares repartidos entre 48 wallets vinculadas a nueve traders, según la firma de análisis Bitquery.
Los movimientos ocurrieron el 26 de octubre de 2026. La firma de análisis Bitquery contabilizó retiros desde 48 billeteras asociadas a nueve traders en un lapso de 94 segundos, un patrón que encaja más con una ejecución automatizada que con un robo manual.
Bloom es un bot de trading que opera a través de Telegram: el usuario abre la aplicación, escribe la orden en el chat y el bot la ejecuta por él. Cómodo y rápido. Para que eso funcione, algún mecanismo de autorización tiene que permitir al servicio mover fondos en nombre del cliente, y ese es exactamente el punto que casi nadie revisa hasta que ocurre algo.
El dato técnico que publicó Bitquery es el que más pesa: los retiros fueron transferencias de SOL firmadas con la clave privada de cada billetera. En Solana, una transferencia solo se ejecuta si la firma criptográfica con la llave privada correspondiente es válida, y una vez confirmada no hay árbitro ni reversión posible. Quien tiene la llave, mueve el saldo.
Eso describe lo que se vio en la cadena, no quién lo hizo ni cómo obtuvo la firma. Un drenaje (drainer, en la jerga del sector) puede entrar por phishing, por un permiso de delegación que nadie revocó o por un componente del propio servicio comprometido. Quien quiera seguir el rastro de esos fondos puede hacerlo desde el explorador on-chain Solscan, bloque a bloque.
La velocidad no fue el problema. El problema fue tener 48 llaves privadas al alcance de un único punto de fallo.
Por qué la explicación de Bloom no cierra del todo
La versión de la empresa apunta a una vulnerabilidad de ejecución remota de código —RCE, el fallo que permite a un atacante ejecutar instrucciones propias en un servidor ajeno— en un módulo de terceros. Sobre esa base, Bloom prometió reembolsos completos a los afectados.
Sostiene además que las claves privadas no se vieron comprometidas ni fueron accedidas. Las dos afirmaciones conviven mal con la descripción de Bitquery, y ninguna viene acompañada de una verificación técnica independiente. No se ha identificado el módulo, no hay informe forense público y no se explica cómo una RCE terminó produciendo firmas válidas en 48 wallets distintas.
Tampoco hay calendario de pagos, procedimiento para reclamar ni detalle sobre de dónde saldrán los 953.000 dólares. Es una garantía pública, no un plan.
El detalle que más debería preocupar: wallets dormidas
Cinco de las billeteras drenadas no había tenido actividad en Bloom desde la primera mitad de 2025. Más de un año paradas y aun así entraron en la lista de las 48.
Eso desplaza el foco a una pregunta incómoda: qué permisos siguen vivos después de dejar de usar una aplicación. Si un servicio conserva capacidad de firma sobre una wallet, la inactividad del dueño no es ninguna barrera. De hecho, es el escenario ideal para un atacante: menos ojos pendientes del saldo.
El patrón de los bots y la parte que no ha cambiado desde 2023
No es la primera vez que el sector paga esta factura. En octubre de 2023, los usuarios de los bots Maestro y Unibot perdieron en conjunto 1,1 millones de dólares por fallos en sus contratos de enrutamiento. En septiembre de 2024, Banana Gun reconoció que once usuarios habían perdido cerca de 3 millones tras un exploit. Bloom sostiene que su caso es distinto —un módulo externo, no un contrato de enrutamiento— y probablemente lo sea. Lo que no cambia es la arquitectura del riesgo.
Solana es una red donde mover fondos cuesta céntimos y la finalidad llega antes de que termine un parpadeo. Esa eficiencia es la razón por la que un trader usa la red y, también, la razón por la que un drenaje se completa antes de que nadie pueda reaccionar. En 94 segundos no hay tiempo ni para escribirle al soporte.
El ecosistema lleva dos años reforzando la seguridad en la capa de protocolo: clientes validadores alternativos como Firedancer —el segundo cliente de validación desarrollado desde cero por Jump Crypto—, mejores prácticas de custodia y simulación de transacciones antes de firmar. Todo eso ayuda. Nada de eso protege a quien autoriza una operación maliciosa desde un bot de Telegram, porque el fallo no está en la red sino en el eslabón que el usuario decidió conectar.
Quedan preguntas por responder: cuál fue el módulo afectado, cómo se relaciona esa falla con las firmas observadas, si los reembolsos llegarán y en qué plazo. Mientras se aclara, la lección práctica cabe en una línea: cada permiso concedido a una herramienta es una llave más en el llavero de otro. Y las llaves no caducan solas.
