En el vertiginoso ecosistema de las finanzas descentralizadas (DeFi) y el comercio de memecoins, la velocidad es el principal motor de una transacción de trading efectiva, porque para los miles de comerciantes que buscan ejecutar operaciones en cuestión de milisegundos dentro de la red Solana, los bots de trading automatizados integrados en Telegram y extensiones web se han convertido en infraestructura esencial.
Sin embargo, la conveniencia operativa conlleva riesgos estructurales de ciberseguridad que han quedado expuestos tras el reciente incidente que afectó a la plataforma Bloom, ya que en un lapso de apenas 94 segundos, una sofisticada incursión logró sustraer 9.408 SOL (equivalentes a aproximadamente 947.000 dólares) desde 49 direcciones de billetera vinculadas al servicio.
Más allá de la cifra robada, el evento destaca por la naturaleza del vector de ataque utilizado, la precisión quirúrgica del ejecutor y, de manera notable, la inusual celeridad con la que el equipo de desarrollo asumió la responsabilidad financiera total para reembolsar a las víctimas en un plazo inferior a 24 horas.
Para los que no conocen a Bloom (frecuentemente identificado en redes y comunidades como Bloom Bot), es una herramienta de software orientada al trading algorítmico y ejecución automatizada de órdenes en cadenas de bloques de alta velocidad, principalmente Solana y entornos EVM.
Permite a los usuarios operar mediante interfaces simplificadas en Telegram o extensiones de navegador, ofreciendo funciones avanzadas como sniping de tokens recién creados, ordenes límite programadas y copy-trading de billeteras de alto rendimiento.
Para que este tipo de aplicaciones logre la velocidad de ejecución requerida en mercados volátiles, la arquitectura de software gestiona claves privadas o permisos de delegación en caliente (hot wallets) que aprueban transacciones de manera automatizada.
Si bien este modelo elimina la latencia de confirmación manual en dispositivos físicos de custodia, establece una superficie de ataque crítica, ya que si la infraestructura subyacente o sus librerías asociadas presentan una brecha, los activos expuestos corren peligro inminente.
Official Statement | Security Incident Update TL;DR: No private keys were compromised, unaffected wallets are safe, and all affected users will be fully reimbursed by Bloom. Following our investigation, we have identified the exact attack vector and confirmed the scope of the incident. The attack exploited a third-party module through a complex Remote Code Execution (RCE) vulnerability. No private keys were accessed or compromised, and we have ruled out broader exposure of users’ wallets. Incident Overview Affected: 49 wallet addresses belonging to 9 users. • Total losses: Approximately 9,408 SOL ($947,000). • Root cause: Exploited third-party module enabling an RCE vulnerability. • Refunds: Bloom will fully reimburse 100% of the stolen funds directly to secure wallets designated by the affected users. • We are also working to trace the stolen funds, explore recovery and freezing options, and identify the attacker. Our team has been developing software since 2018 and operating in crypto since 2021. We are an established team, committed to building for the long term and protecting the trust of our users. Security threats are an unfortunate reality of this industry, even with extensive precautions in place. Our commitment to user safety, transparency, and business continuity remains unchanged. The Bloom Team
— Bloom (@BloomTrading) October 26, 2026
En la declaración oficial de Bloom en la red social X, se señaló que: “El ataque explotó un módulo de terceros a través de una vulnerabilidad compleja de Ejecución Remota de Código (RCE). No se accedió ni comprometieron claves privadas, y hemos descartado una exposición más amplia de las billeteras de los usuarios”.
Tras congelar temporalmente los accesos e iniciar las investigaciones técnicas correspondientes, el equipo de Bloom emitió una declaración oficial precisando la causa raíz del incidente y explicando cómo el ciberatacante explotó una vulnerabilidad de RCE en un módulo de software provisto por un tercero e integrado en su pila tecnológica.
Una falla RCE permite a un atacante ejecutar instrucciones arbitrarias en el servidor de la víctima a través de la red sin necesidad de autenticación previa porque a través de esta rendija en el módulo comprometido, el atacante logró instruir a la aplicación para que firmara y transmitiera las órdenes de transferencia utilizando el mecanismo legítimo de procesamiento de transacciones.
Esto explica por qué la red validó los movimientos como legítimos del actor malintencionado, a pesar de que el equipo de Bloom insistió en que las claves privadas maestras no fueron expuestas de forma directa o extraídas del entorno seguro en texto plano.
Para entender un poco más la anatomía del ciberataque de 94 segundos y 49 billeteras afectadas en Bloom, los análisis forenses on-chain realizados inmediatamente después del incidente revelaron un patrón de ejecución altamente automatizado e implacable.
El atacante no hizo un barrido masivo e indiscriminado sobre toda la base de usuarios de la plataforma —la cual supera los 60.000 comerciantes registrados—, sino que centró su objetivo de manera quirúrgica en un grupo reducido de cuentas con saldos elevados (whales).
En total, el robo afectó a 49 direcciones de billetera pertenecientes a solo 9 usuarios, puesto que el script malicioso operó con una secuencia precisa de tres fases. Primero, abordó a Bloom con la prueba de viabilidad, ya que el atacante ejecutó primero pequeñas transacciones de prueba en una sola dirección de cada uno de los 9 usuarios identificados.
En segundo lugar, efectuó el drenaje jerárquico, tras confirmar que podía autorizar el movimiento de fondos, el programa procedió a vaciar los saldos de SOL de forma descendente, priorizando las billeteras con mayor volumen.
Y tercero, efectuó la exclusión de activos secundarios, ya que el barrido se limitó exclusivamente a los saldos nativos en SOL, dejando intactos activos en stablecoins (como USDC) almacenados en algunas de esas mismas direcciones.
Sorprendentemente, la lista de objetivos incluyó direcciones que no habían registrado operaciones dentro de Bloom en más de un año, lo que evidenció que las credenciales o permisos de autorización persistían en los registros analizados por el vector malicioso.
La industria cripto registra un extenso historial de plataformas y bots que, tras sufrir vulnerabilidades de esta magnitud, interrumpen operaciones de forma indefinida o trasladan las pérdidas de manera permanente a sus clientes.
Pero la respuesta de Bloom generó una marcada divergencia respecto a esa norma habitual, ya que efectuó el reembolso íntegro e inmediato. De hecho, pocas horas después de confirmar el alcance del robo, Bloom transfirió el 100% de los fondos sustraídos (los 9.408 SOL en su totalidad) directamente a nuevas billeteras seguras designadas por los 9 usuarios afectados.
All Refunds Successfully Processed | 9,408 SOL Refunded
We confirm that 100% of the affected funds, totaling 9,408 SOL, have been fully refunded to all 9 users impacted by the recent security incident.
As part of our commitment to transparency, all refund transactions are… https://t.co/60BlGtIpH0 pic.twitter.com/Ud43gkV15h
— Bloom (@BloomTrading) October 26, 2026
Las transacciones de compensación fueron publicadas abiertamente en Solscan para su verificación pública. Además, realizó el rastreo y negociación ya que paralelamente, el equipo anunció la recopilación de datos técnicos —incluyendo direcciones IP de origen y centros de datos utilizados por el atacante— e inició un contacto on-chain mediante mensajes en la red y correos oficiales.
Se le ofreció al ejecutor la posibilidad de conservar una fracción de los fondos como recompensa white-hat si devolvía el resto, bajo la advertencia de iniciar acciones legales internacionales de lo contrario.
El incidente sufrido por Bloom reabre una vez más el debate técnico sobre las fronteras de seguridad en el segmento de las herramientas de automatización comercial. Aunque el compromiso de liquidez asumido por la empresa logró contener el impacto financiero para sus clientes y preservar la reputación de la marca, el caso subraya riesgos ineludibles.
El riesgo de dependencias de terceros, como los módulos externos en proyectos de software financiero representan vectores de riesgo persistentes que demandan auditorías continuas e hipervigilancia de código.
Asimismo, llevar a cabo una rigurosa higienización de credenciales pasivas, para evitar la permanencia de permisos o datos en billeteras inactivas por meses demuestra la importancia de implementar mecanismos automáticos de revocación de acceso o caducidad de claves en caliente tras ciertos periodos de inactividad.
Y finalmente, mantener el aislamiento de capital de las Apps cuando no se van a utilizar por un tiempo, debe ser una práctica constante para los traders activos, para evitar que puedan ser víctimas en el futuro cuando no se monitorea la App de trading.
De allí que, la recomendación de la industria sigue siendo la misma, limitar los saldos en billeteras conectadas a bots, dejando exclusivamente el capital destinado a la operativa diaria y transferir los excedentes o ganancias acumuladas hacia soluciones de custodia fría de forma periódica.