Incidente Fetch.ai y NuNet del 19 de septiembre de 2026: una clave comprometida y controles de puente bajo presión
El incidente de Fetch.ai y NuNet muestra cómo una credencial privilegiada comprometida y controles asimétricos pueden ampliar el impacto de un puente.
Incidente Fetch.ai y NuNet del 19 de septiembre de 2026: una clave comprometida y controles de puente bajo presión
El incidente del 19 de septiembre, con conversiones de FET en Ethereum y una acuñación posterior de NTX, no debe resumirse como un simple “hack de token”. La evidencia pública apunta a una credencial de firma privilegiada comprometida, una autorización válida usada en TokenConversionManagerV3 y controles de diseño que habrían ampliado el radio de impacto.
Una clave de backend comprometida no equivale a una omisión de autenticación en el contrato. Tampoco prueba una vulnerabilidad del contrato de token FET o de NuNet. Los controles on-chain pueden ejecutar correctamente una autorización válida y, aun así, el sistema fallar porque la autoridad que la crea no está suficientemente protegida ni acotada.
Fetch.ai confirmó públicamente un exploit, afirmó que la clave de firma fue comprometida y describió el análisis on-chain enlazado como preliminar, no final. CryptoSlate aporta contexto técnico que debe leerse con esa cautela.
Cronología: de la conversión de FET a la acuñación de NTX
Según CryptoSlate, el 19 de septiembre salieron 8.721.530 FET, valorados en aproximadamente US$1,55 millones en ese momento, del TokenConversionManagerV3 del lado de Ethereum. El movimiento utilizó una firma de autorización válida. El medio atribuye la causa a una clave de firma de backend comprometida, no a un bypass de autenticación del contrato.
Esta es la primera separación analítica necesaria. Si el contrato valida una firma emitida por una autoridad autorizada, el contrato puede estar respetando su regla programada. El fallo sistémico se ubica entonces en el plano de la autoridad privilegiada, su custodia, su capacidad de revocación y los límites que restringen lo que una firma puede autorizar.
Como hallazgo preliminar y basado en reportes de CryptoSlate, veintinueve minutos después una cuenta minter inactiva de NuNet acuñó 408.532.878 NTX hacia la misma billetera receptora. La transacción de acuñación en Ethereum figura como exitosa. Según ese reporte preliminar, la coincidencia de la dirección receptora es evidencia coordinada a nivel de direcciones: vincula dos movimientos dentro de la misma secuencia observada. No identifica por sí sola a una persona, no prueba el vector completo y no establece que cada componente compartiera exactamente la misma debilidad.
El monto nominal de NTX tampoco debe comunicarse como pérdida líquida realizable. La liquidez limitada impidió realizar ese valor nominal. En incidentes de emisión, multiplicar unidades acuñadas por el último precio disponible puede producir un número llamativo, pero no mide necesariamente fondos extraíbles, profundidad de mercado ni daño económico consolidado.
Fetch.ai informó en su actualización oficial en X que, junto con SingularityNET, desactivó las billeteras y el contrato afectados. CryptoSlate también reportó que se pausaron las conversiones AGIX a FET y el puente del lado de Ethereum, mientras que las transferencias normales de FET continuaron. Esta contención sugiere una respuesta orientada a aislar las rutas de conversión y emisión, sin paralizar la transferencia ordinaria del token.
Qué está confirmado, qué se reporta y qué sigue abierto
Confirmado públicamente: Fetch.ai reconoció un exploit, señaló el compromiso de una clave de firma y comunicó acciones de desactivación junto con SingularityNET. La transacción de mint de NTX citada se ejecutó con éxito en Ethereum. También existe evidencia pública de que las rutas de conversión y el puente fueron pausados, mientras que las transferencias normales de FET permanecieron activas.
Reportado por terceros y sujeto a análisis preliminar: CryptoSlate informa que los 8.721.530 FET salieron mediante una firma válida y atribuye la firma a una clave de backend comprometida. CryptoSlate reporta que el límite de 1 millón de FET no aplicaba a la ruta conversionIn y que el mensaje firmado no vinculaba al destinatario final. Estos son hallazgos preliminares y basados en reportes, no una auditoría independiente de código fuente realizada por Seclat.
Evidencia coordinada, pero limitada: la misma dirección receptora aparece en la conversión de FET reportada y en la posterior acuñación de NTX. Eso respalda una relación operativa entre los movimientos. No basta para atribuir identidad, demostrar compromiso de cada clave administrativa ni declarar una vulnerabilidad probada de NuNet.
Abierto: faltan una cronología forense completa, el alcance de las credenciales afectadas, los controles exactos previos al incidente, las rutas de revocación disponibles y la causa de que una cuenta minter inactiva pudiera actuar. También permanece abierta la evaluación de pérdidas efectivas y recuperaciones. Cualquier conclusión adicional debe esperar evidencia técnica verificable y el informe final.
La lección de arquitectura: la firma no debe ser un cheque en blanco
El aspecto más instructivo del caso es la combinación de autoridad privilegiada y diseño permisivo. Una firma válida no debería poder convertirse en una autorización de alcance indefinido. Los puentes y conversores deben tratar cada autorización como una capacidad limitada: quién puede iniciar la operación, qué activo, qué cantidad, qué ruta, qué red, qué destinatario, hasta cuándo y cuántas veces.
El hallazgo preliminar y basado en reportes de CryptoSlate de que el límite de 1 millón de FET no se aplicaba a conversionIn describe un problema de simetría de controles. Un límite que protege una dirección del flujo pero no su inversa o ruta equivalente ofrece una seguridad aparente. Todo límite económico debe verificarse contra cada entrada, salida, conversión, acuñación, rescate y ruta de emergencia que pueda producir el mismo efecto financiero.
Del mismo modo, el hallazgo preliminar y basado en reportes de CryptoSlate de que una autorización no vinculaba el destinatario final indica que quien obtiene una firma válida puede tener margen para redirigir valor dentro de los parámetros que el contrato acepte. El mensaje firmado debe incluir explícitamente el destinatario, la cantidad, el activo, el identificador de cadena, el contrato verificador, un nonce y una expiración. El contrato debe consumir el nonce una sola vez y rechazar cualquier diferencia entre los campos firmados y la ejecución.
Controles que un equipo de protocolo debe priorizar
- Reducir privilegios y separar funciones. Ninguna clave de backend debería tener capacidad amplia por sí sola. Separar emisión, conversión, cambios de configuración y respuesta a incidentes, con roles mínimos y aprobaciones multifirma o umbrales cuando el riesgo lo justifique.
- Custodiar claves como producción crítica. Usar HSM o mecanismos equivalentes, controles de acceso fuertes, registros auditables, entornos segregados y prohibición de exportar material sensible. Una clave que firma autorizaciones económicas merece el mismo tratamiento que una clave de custodia.
- Diseñar rotación y revocación antes del incidente. Definir claves con vigencia corta, identificadores de versión, revocación on-chain o en el verificador, y un procedimiento probado para deshabilitar una autoridad sin detener innecesariamente todo el protocolo.
- Vincular el contexto completo en la firma. Destinatario final, importe, ruta, contrato, red, nonce, caducidad y emisor deben ser parte del payload verificable. Firmar solo una cantidad o un identificador parcial deja ambigüedad exploitable.
- Aplicar límites simétricos y acumulativos. El límite por operación no reemplaza límites por ventana temporal, por activo, por cuenta y globales. Las rutas equivalentes deben compartir la misma política de riesgo.
- Instalar rate limits y circuit breakers. Un salto anómalo de volumen, una conversión muy superior al patrón histórico o una emisión desde una cuenta inactiva debe poder pausar automáticamente la ruta de mayor riesgo y escalar a revisión humana.
- Monitorear invariantes, no solo errores. Alertar cuando la emisión neta excede umbrales, cuando reservas y pasivos dejan de cuadrar, cuando una dirección recibe activos de dominios no relacionados o cuando una cuenta dormida vuelve a tener privilegios efectivos.
- Ensayar respuesta a incidentes. La capacidad de pausar rutas, revocar firmantes, coordinar con exchanges y comunicar límites de certeza debe probarse mediante simulacros. El runbook debe asignar autoridad, tiempos de decisión y canales de evidencia.
Qué revisar ahora
Los equipos que operan conversores o puentes pueden transformar este caso en una revisión concreta. Inventarien todas las rutas que mueven valor, no solo las funciones más visibles. Para cada una, documenten qué rol puede aprobarla, qué campos quedan firmados, cuáles son los máximos por operación y por periodo, y cómo se revoca la autoridad.
Después, prueben los invariantes en escenarios adversarios: una clave de firma comprometida, una firma reutilizada, un destinatario sustituido, una ruta inversa sin límite, una cuenta inactiva que recupera permisos y una pausa parcial durante congestión. La pregunta no es si una firma puede verificarse, sino cuánto daño puede causar una firma válida en el peor momento posible.
Una auditoría útil debe cubrir contratos, servicio firmante, gestión de secretos, telemetría y procedimiento operativo. Revisar solamente el bytecode puede pasar por alto el componente que convierte una autorización legítima en una pérdida material.
Conclusión
La evidencia disponible no sostiene llamar a este evento un exploit probado del contrato de token FET ni una vulnerabilidad probada de smart contracts de NuNet. Preliminarmente, describe una autoridad privilegiada comprometida que habría interactuado con límites asimétricos y autorizaciones insuficientemente vinculadas al contexto.
En Seclat revisamos puentes, conversores y controles privilegiados como un sistema completo: contratos, firmas, custodia de claves, límites y respuesta. Si tu protocolo depende de autorizaciones off-chain para mover o emitir valor on-chain, una revisión de estas fronteras debe ocurrir antes de que una clave válida se convierta en un incidente.