BTCVN4 tiene malas premoniciones.
El 31/8, Injective sufrió un exploit que causó daños de aproximadamente 4,9 millones de USD. Al principio, el incidente se describió como un ataque dirigido a algunas aplicaciones de Binary Options dentro del ecosistema.
Sin embargo, un informe de análisis del 3/9 plantea un problema aún más serio:
👉 La brecha podría haber interactuado con los módulos nativos/core de Injective en sí, en lugar de estar únicamente en una aplicación externa de Binary Options.
Y este es el punto al que los holders de INJ deben prestar especial atención.
1. Colisión de market-ID: el punto de partida del exploit
Según los análisis on-chain, el atacante explotó un fallo relacionado con la forma en que Injective genera el market ID.
El market ID se forma a partir de varios campos de datos, como:
• Tipo de oracle
• Ticker
• Denominación de la cotización
• Símbolo del oracle
• Proveedor del oracle
El problema está en cómo se combinan estos campos sin un mecanismo de separación/longitud lo suficientemente claro.
En teoría, esto puede crear una situación en la que:
Dos configuraciones de mercado diferentes → generan el mismo market ID.
El atacante aprovechó esta capacidad para crear mercados de Binary Options con una estructura especial y luego interactuó con la lógica de settlement/refund.
Los informes indican que el atacante creó unos 299 mercados en un período de aproximadamente 19 horas y finalmente retiró cerca de 4,9 millones de USD.
2. Pero la pregunta más grande es: ¿dónde está el fallo?
Esto es lo verdaderamente destacable.
Injective ha afirmado que:
• El consenso no fue comprometido
• El INJ nativo no se vio afectado
• El INJ staked sigue siendo seguro
• El incidente solo afectó a algunas aplicaciones que usan Binary Options
Esto es una buena noticia para los holders de INJ.
Pero algunos análisis independientes sostienen que la historia es más compleja.
Según el investigador Earthling Paddy, el exploit está relacionado con los módulos nativos de exchange e insurance de Injective.
En otras palabras:
Binary Options puede haber sido la “puerta” que usó el atacante, pero la lógica explotada estaba más profundamente dentro de los módulos del protocolo.
Esta es una diferencia extremadamente importante.
Si el fallo estuviera solo en un smart contract/aplicación independiente → el alcance del riesgo sería relativamente limitado.
Pero si una aplicación puede activar una lógica incorrecta dentro de los módulos nativos del protocolo, entonces la cuestión pasa a ser:
Ataque en la capa de aplicación → pero la superficie de ataque está en la capa de protocolo.
🔴 3. La evidencia más destacable: el parche de emergencia corrige la lógica del CORE
Uno de los detalles que más llamó la atención de BTCVN4 fue precisamente la actualización de emergencia:
v1.20.3-safeharbor.1
Esta release se desplegó en la mainnet de Injective durante el proceso de respuesta al incidente.
Según los informes de análisis, el parche introdujo cambios importantes como:
✅ Añadir verificación de denominación al insurance fund.
✅ Deshabilitar el settlement de Binary Options en la mainnet.
Lo notable es que estos cambios están en el código central de la blockchain.
Por eso, surge la pregunta razonable:
Si el problema estuviera completamente en una aplicación externa de Binary Options, ¿por qué el parche de emergencia tendría que corregir la lógica en la capa de protocolo/core?
Esto todavía no es prueba suficiente para concluir que el consenso de Injective o el INJ nativo hayan sido comprometidos.
Pero sí es una señal suficientemente fuerte como para que no simplifiquemos el incidente como “una aplicación externa hackeada”.
4. ¿La cadena realmente se “halted” o fue solo una emergency upgrade?
Este también es un punto que está generando debate.
Injective describió el evento como una actualización acelerada de la red y, al mismo tiempo, afirmó que la blockchain y el consenso seguían siendo seguros.
Sin embargo, datos on-chain analizados por algunos investigadores muestran que hubo aproximadamente 3 horas y 42 minutos sin nuevos bloques, mientras los validadores desplegaban la actualización de emergencia.
Algunos validadores incluso fueron puestos en jail por no completar la actualización dentro del plazo requerido.
Por lo tanto, técnicamente, hay una diferencia entre:
“el consenso fue comprometido” y “la producción de bloques se interrumpió para desplegar un parche de emergencia”.
Estas dos cosas no son lo mismo.
Por ahora, los datos respaldan la idea de que el atacante no tomó el control del consenso, pero la red sí sufrió una interrupción significativa durante la respuesta al incidente.
5. ¿Qué es lo que YA sabemos?
En este momento, hay varios puntos relativamente claros:
1️⃣ Se explotaron aproximadamente 4,9 millones de USD.
2️⃣ El atacante utilizó la colisión de market-ID en la lógica de settlement de Binary Options.
3️⃣ Se cree que aproximadamente 1.980 ETH fueron transferidos a Ethereum y actualmente siguen en la dirección relacionada con el incidente, según los informes publicados.
4️⃣ Injective desplegó la release de emergencia v1.20.3-safeharbor.1.
5️⃣ El settlement de Binary Options fue deshabilitado en la mainnet.
6️⃣ Se añadió verificación de denominación a la lógica del insurance fund.
7️⃣ Injective afirma que el consenso, el INJ nativo y los activos staked no fueron comprometidos.
Estos puntos muestran que el exploit fue contenido relativamente rápido y que el daño no se propagó hasta convertirse en un ataque a la capa de consenso.
6. Pero, ¿qué sigue SIN responder?
Esto es lo que BTCVN4 cree que los holders de INJ deben seguir de cerca.
❓ ¿Cuál es exactamente la ruta de ataque?
❓ ¿Con qué módulos interactuó la colisión de market-ID?
❓ ¿Por qué un fallo que empezó en Binary Options requirió corregir lógica en el core del protocolo?
❓ ¿Cuál es la pérdida total final?
❓ ¿Quién asumió realmente el shortfall de unos 4,9 millones de USD?
❓ ¿Se recuperaron o no los fondos explotados?
❓ ¿Existen otras variantes de la misma clase de vulnerabilidad?
❓ ¿Existe algún otro módulo nativo que use una lógica de market-ID similar y que deba volver a auditarse?
Y lo más importante:
¿Injective ha verificado toda la superficie de ataque de los módulos nativos o solo ha bloqueado el vector de Binary Options?
Un post-mortem técnico completo será muy importante para responder a estas preguntas.
Los informes actuales indican que Injective todavía no ha publicado un post-mortem técnico completo que describa toda la ruta de ejecución y la distribución del daño.
7. Entonces, ¿cómo deben entender este incidente los holders de INJ?
En mi opinión, todavía no debería concluirse que Injective sufrió un “core compromise”.
Porque por ahora no hay evidencia de que:
El consenso fue controlado por el atacante.
Se acuña INJ nativo de forma no autorizada.
INJ staked robado.
El conjunto de validadores fue tomado por el atacante.
Pero, al mismo tiempo, tampoco debe subestimarse el incidente.
Porque si se confirma en el post-mortem el informe sobre la colisión de market-ID y la interacción con el core module, la naturaleza del incidente sería considerablemente más grave que la de un smart contract de Binary Options con fallos.
Esto mostrará:
Una aplicación puede activar lógica peligrosa dentro de los módulos nativos del protocolo.
Se trata de un problema de la arquitectura de seguridad del protocolo, y no simplemente de un fallo de una dApp.
PERSPECTIVA DE BTCVN4
Creo que ahora hay dos capas de información que deben separarse:
Nivel 1 – La buena noticia:
Injective contuvo el exploit, el consenso no parece haber sido comprometido según la información actual, y INJ nativo y el staking siguieron protegidos.
Nivel 2 – Riesgos a vigilar:
Si la colisión de market-ID realmente proviene de, o puede afectar a, los módulos nativos de exchange/insurance, entonces necesitamos saber qué tan grande es el alcance de esta clase de vulnerabilidad.
Eso es lo que realmente determina el nivel de riesgo a largo plazo de INJ.
Por eso, en mi opinión:
👉 No hagan FUD diciendo que INJ fue destruido.
Pero también:
👉 No saquen conclusiones apresuradas de que “solo es Binary Options, así que no tiene relación con el protocolo”.
Estos dos extremos tampoco son correctos.
Lo que más vale la pena esperar ahora no es un tuit para calmar al mercado.
Sino:
UN POST-MORTEM TÉCNICO COMPLETO.
Si el post-mortem demuestra que la vulnerabilidad estaba limitada a Binary Options y que los módulos relacionados fueron auditados de forma exhaustiva → el riesgo se reducirá significativamente.
En cambio, si se descubre que la colisión de market-ID o una lógica similar existe en muchos otros módulos nativos → esto sí podría convertirse en un problema importante para la tesis a largo plazo de INJ.
Los holders de INJ deberían seguir de cerca especialmente 4 cosas en los próximos días:
Post-mortem técnico oficial.
Si se descubrió alguna vulnerabilidad adicional en los módulos nativos de exchange/insurance.
Si los ~4,9 millones de USD fueron recuperados o siguen en la cartera del atacante.
Si los validadores, el exchange y el ecosistema de Injective volvieron a funcionar con normalidad por completo.
Todavía no es momento de entrar en pánico. Pero sin duda sí es momento de aumentar la cautela.
BTCVN4 les desea buena suerte
