La semana pasada, la red de Layer-1 Qubic experimentó uno de los incidentes de seguridad más reveladores y didácticos en la historia reciente de la infraestructura criptográfica porque en menos de dos horas, un atacante logró vaciar 1.404 billeteras de usuarios, drenando aproximadamente 2,94 trillones de tokens QU (valorados en más de 1,3 millones de dólares en el momento del suceso).
A diferencia de los ataques habituales en el ecosistema Web3 —que suelen involucrar exploits en contratos inteligentes, reentradas o robos de claves privadas mediante ingeniería social—, la vulnerabilidad de Qubic no residió en su protocolo central ni en su mecanismo de consenso de Prueba de Trabajo Útil (UPoW, «por sus siglas en inglés»).
Para los que no lo saben, Qubic es un protocolo de criptomonedas de capa 1 de alto rendimiento diseñado para ofrecer transacciones sin comisiones, finalidad instantánea y ejecución muy rápida de contratos inteligentes.
Utiliza un mecanismo de consenso denominado UPoW, impulsado por el algoritmo de minería de Qubic BPP-9000 y busca integrar redes neuronales artificiales avanzadas enfocadas en el desarrollo de la Inteligencia Artificial General (AGI, «por sus siglas en inglés»).
El fallo fue un error de desarrollo clásico en la capa del cliente, a través del uso de una función no segura criptográficamente para la generación de aleatoriedad, la conocida Math.random(). Y es que, básicamente el vector de ataque se centró en la creación de las frases semilla (seed phrases) en las billeteras oficiales basadas en entorno Web y dispositivos móviles.
Para que una clave criptográfica sea segura, debe ser impredecible. La impredecibilidad en ciencias de la computación se mide mediante la entropía, la cual representa la cantidad de incertidumbre o “caos” introducida en la generación de un dato.
En la versión v4.26.3 de la billetera de Qubic, las semillas de 55 caracteres (compuestas por letras de la “a” a la “z”) se generaban carácter por carácter utilizando la función nativa de JavaScript “Math.random()”.
Posterior a esta generación, la semilla se procesaba a través del algoritmo de hashing K12 para derivar la clave privada de 32 bytes de la cuenta (seedToBytes(seed) → K12 → clave privada) de manera que teóricamente, una cadena de 55 caracteres elegidos de un alfabeto de 26 letras posee una entropía nominal de: $$55 \times \log_2(26) \approx 258.5 \text{ bits}$$.
Security incident update. Between 23:42 UTC on 17 October and 01:26 UTC on 18 October, an attacker drained 1,404 Qubic wallets, totalling around 2.94 trillion QU.Here is what happened, what has been done, and what comes next. https://t.co/7aPJ26lEeZ
— Qubic (@_Qubic_) October 18, 2026
Un valor de 258.5 bits ofrece un margen de seguridad equivalente o superior al de la mayoría de los estándares de la industria (como las palabras clave BIP-39). Sin embargo, esta cifra era puramente ilusoria.
El problema fundamental es que “Math.random()” no es un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG). En la mayoría de los entornos de ejecución modernos, como el motor V8 de Google (que impulsa a Chrome, Brave, Electron y Node.js), “Math.random()” implementa un algoritmo denominado “xorshift128+”.
El algoritmo “xorshift128+” está diseñado para ofrecer una velocidad de ejecución rápida y una distribución estadísticamente uniforme en aplicaciones generales (como animaciones CSS, juegos sencillos o lógica de interfaz), pero nunca para seguridad ni criptografía.
Las limitaciones técnicas que explotó el atacante incluyeron: 1. Reducción masiva del espacio de claves: El estado interno de “xorshift128+” en el motor V8 se inicializa con tan solo 64 bits de entropía del sistema operativo derivados mediante MurmurHash3.
- Esto significa que el espacio real de búsqueda para cualquier semilla generada no era de $2^{258.5}$ combinaciones, sino de como máximo $2^{64}$. En términos computacionales modernos, un espacio de $2^{64}$ es completamente abordable mediante fuerza bruta o ataques precomputados en clústeres de GPUs.
- 3. Reversibilidad del estado: Algoritmos como “xorshift128+” son deterministas y reversibles. Si un atacante logra observar entre 2 y 4 salidas consecutivas del generador de números aleatorios (o secuencias de semillas generadas en el mismo entorno de ejecución), puede reconstruir con precisión matemática el estado interno del PRNG.
- Predicción bidireccional: Una vez reconstruido el estado interno, el atacante no solo puede predecir todas las semillas que se generarán en el futuro dentro de ese entorno, sino también deducir con exactitud las semillas que se generaron en el pasado.
El 17 de octubre de 2026, entre las 23:42 UTC y las 01:26 UTC del 18 de octubre, el atacante ejecutó un script optimizado para simular las secuencias de “Math.random()” generadas en navegadores vulnerables (especialmente Safari en macOS e iOS, y navegadores basados en V8 creados antes de las actualizaciones de seguridad).
Al derivar las claves privadas correspondientes a los estados de entropía reducida, el atacante tomó control de 1,404 billeteras y comenzó a transferir masivamente los fondos. Ante la velocidad del drenaje, la red de Qubic reaccionó mediante su estructura de gobernanza de Computors (nodos validadores).
Para evitar la pérdida total de los fondos del ecosistema, los validadores decidieron ejecutar una detención de emergencia del protocolo en el “tick” 85.371.949, “que es el equivalente directo a lo que en blockchains tradicionales (como Bitcoin o Ethereum) conocemos como un bloque” y por eso el siguiente tick 85.371.950 está vacío sin transacciones.
Gracias a esta pausa drástica, aproximadamente el 87.1% de los fondos robados permanecieron congelados dentro de la propia red, imposibilitando su movimiento posterior, aunque el 12.9% restante enviado al exchange MEXC fue interceptado y bloqueado rápidamente en coordinación con el equipo de seguridad de la plataforma.
Este incidente en Qubic pone de manifiesto una regla dorada del desarrollo de software seguro que a menudo se pasa por alto durante iteraciones rápidas de código: “jamás se debe utilizar un PRNG estándar para la generación de material criptográfico”.
En entornos JavaScript y de navegador, la única alternativa adecuada es el uso de la API criptográfica nativa del sistema: crypto.getRandomValues() (o crypto.generateRandomKey() en Node.js).
Estas funciones interactúan directamente con las fuentes de entropía del sistema operativo (como /dev/urandom en sistemas UNIX o BCryptGenRandom en Windows), garantizando una verdadera impredecibilidad criptográfica.
Aunque Qubic utiliza el concepto de UPoW, que es el pilar central de su diseño y representa una diferencia filosófica y técnica con respecto al Proof of Work tradicional (como el de Bitcoin), lo cierto es que es muy seguro y bastante rápido.
En las redes PoW convencionales como Bitcoin o Ethereum, los mineros gastan enormes cantidades de energía eléctrica resolviendo acertijos matemáticos aleatorios (funciones de hash) cuyo único propósito es asegurar la red y elegir quién añade el siguiente bloque. Una vez resuelto el acertijo, ese trabajo no tiene ningún valor en el mundo real.
Pero UPoW redirige esa potencia de cálculo hacia tareas computacionales con utilidad práctica, que en el caso de Qubic, en lugar de calcular hashes inútiles, se usa el poder de cómputo de los mineros para entrenar Redes Neuronales Artificiales (ANN) enfocadas en el desarrollo de Inteligencia Artificial General (AGI).
Sin duda que el caso de Qubic servirá como un recordatorio histórico de que la fortaleza de una red blockchain de capa 1 no depende únicamente de la complejidad de su Consenso o de sus algoritmos de Inteligencia Artificial, sino de la solidez técnica del eslabón más delgado en su cadena de implementación.