Exploit de contabilidad en el pool de liquidez de NemTokenV2

El 22 de octubre de 2026, el contrato NemTokenV2 —un token de BNB Chain negociado en PancakeSwap y sin relación con la blockchain nativa NEM/XEM— fue explotado por aproximadamente 822.000 dólares. La pérdida se originó en un fallo lógico del propio código del token, no en una clave robada ni en una dependencia externa. Las firmas de seguridad SlowMist y CertiK señalaron el incidente el mismo día, y SlowMist estimó el daño en unos 821.920 dólares.

Qué ocurrió

NemTokenV2 incorporaba un mecanismo propio de contabilidad "sell-recycle" en su lógica de transferencia. El contrato trataba cualquier transferencia de tokens hacia su par de liquidez en PancakeSwap como volumen de venta sin verificar que un swap se hubiera liquidado realmente. Como el saldo real de tokens del par podía superar sus reservas registradas, ese excedente era susceptible de skimming.

El atacante explotó la brecha en un bucle ajustado: enviaba NEM al pool USDT/NEM, llamaba a skim() para limpiar el excedente e invocaba la rutina propia del contrato flushLpSellRecycle(). Según SlowMist, la secuencia se repitió unas 42 veces, reduciendo de forma sostenida las reservas de NEM del pool e inflando el precio del token. El atacante vendió entonces los NEM restantes al precio distorsionado a cambio de USDT y transfirió las ganancias a Ethereum mediante un puente.

Consecuencias

En el momento de las primeras divulgaciones, el equipo de NemTokenV2 no había publicado una declaración oficial, ni nombrado una corrección, ni reportado fondos recuperados. SlowMist afirmó haber publicado las direcciones del atacante, del contrato de exploit y del token, pero la cobertura pública no las reprodujo, y no se estableció ningún hash de transacción confirmado ni la identidad del atacante.

Por qué importa

La pérdida de NemTokenV2 recuerda que los hooks de transferencia de un token son en sí mismos superficie de ataque. La lógica a medida de "tax", "reflection" o "recycle" que modifica la contabilidad del pool de liquidez en cada transferencia invita exactamente a esta clase de error: cuando un contrato confía en su contabilidad interna por encima del estado liquidado del AMM, un atacante puede fabricar volumen de venta fantasma y quedarse con la diferencia. Es la misma distorsión de reservas y precio vista en Papertrade y Tectonic, y subraya por qué los contratos de token con contabilidad propia deberían reconciliarse contra los saldos reales del par, y nunca al revés.