Seguridad

Internet_token en Base sufre un exploit de control de acceso y se acuña cerca de 764 millones de INT

El token internet_token en Base fue afectado por un exploit de control de acceso vinculado al contrato LiquidityUnifier, según un reporte on-chain que atribuye al atacante la acuñación de aproximadamente 925 millones de INT. De esa cantidad, el actor retenía cerca de 764 millones de INT al momento del seguimiento.

El incidente se habría originado en una validación insuficiente del mecanismo que interactúa con pools de Uniswap V3, lo que permitió simular callbacks de pool y eludir la verificación de suministro. En la práctica, eso abrió la puerta a una acuñación no autorizada dentro del contrato afectado.

La falla apuntó al flujo de callbacks y validación de suministro

El análisis técnico publicado sobre el caso describe una debilidad de acceso en LiquidityUnifier que permitió usar un pool falso de Uniswap V3 para activar el flujo esperado por el contrato. Con ese camino, el atacante habría pasado por alto la validación de supply y ejecutado la acuñación de tokens sin permiso.

La misma investigación señala que la transacción del ataque y las direcciones implicadas pueden rastrearse en cadena. También indica que la vía de acuñación seguía abierta, lo que eleva el riesgo de nuevas emisiones no autorizadas mientras no se cierre el vector.

Un reporte adicional sobre el incidente coincide en que la cantidad emitida alcanzó unos 925,4 millones de INT y que el atacante conservó alrededor de 764 millones, con la referencia a la transacción concreta asociada al exploit.

Lo que muestran los datos on-chain

El seguimiento del incidente en Base deja ver un patrón consistente con una acuñación arbitraria, no con una emisión programada por el protocolo. Ese punto es importante: lo visible en cadena apunta a un fallo de control de acceso en el contrato, no a una expansión normal del suministro.

Hasta donde llega la información disponible, el foco del incidente está en el contrato LiquidityUnifier y en su interacción con el flujo de callbacks de pool. No hay, con los datos aportados, una confirmación pública adicional sobre una corrección definitiva del problema.

En este tipo de eventos, el dato central para el usuario no es solo la cantidad acuñada, sino si el mecanismo que permitió el exploit sigue activo. En este caso, la cobertura técnica indica que esa posibilidad no quedaba descartada en el momento del reporte.