Build with CoinStats’ all-in-one API. Learn more

Deutsch한국어日本語中文EspañolFrançaisՀայերենNederlandsРусскийItalianoPortuguêsTürkçePortfolio TrackerCryptocurrenciesPricingCrypto APIMCPIntegrationsNewsRWA MarketEarnBlogNFTWidgetsDeFi Portfolio TrackerDerivativesETF FlowsCrypto GamingPrediction Markets24h ReportPress KitAPI Docs

Un fallo en NEM drenó USD $820.000 del pool de PancakeSwap

3h ago•
bullish:

0

bearish:

0

Share

Un error en la lógica del contrato NemTokenV2 habría permitido manipular el registro de ventas y extraer repetidamente valor del pool USDT/NEM en PancakeSwap. Según las estimaciones citadas en el reporte, CertiK calculó las pérdidas en aproximadamente USD $820.000 y SlowMist en USD $821.920.
***

  • El incidente reportado afectó al pool USDT/NEM de PancakeSwap en BNB Chain y se atribuye a una falla lógica del contrato, no al robo de una clave.
  • El mecanismo de seguimiento habría confundido transferencias de tokens al pool con ventas, lo que permitió repetir el ciclo 42 veces.
  • Según el reporte, tras extraer valor de la liquidez el atacante trasladó los fondos a Ethereum; la operación también habría distorsionado el precio de NEM.


🚨 PancakeSwap: reportan drenaje de hasta USD 821.920 en el pool USDT/NEM

La falla en NemTokenV2 habría permitido repetir 42 veces una manipulación del registro de ventas.

Los fondos habrían sido trasladados a Ethereum, según los reportes. pic.twitter.com/kC87DwEuz2

— Diario฿itcoin (@DiarioBitcoin) October 22, 2026

Un fallo en NEM drenó USD $820.000 del pool de PancakeSwap

Una vulnerabilidad en el contrato inteligente NemTokenV2 habría permitido a un atacante extraer valor del pool de liquidez USDT/NEM de PancakeSwap, en BNB Chain, según reportes fechados el 22 de octubre de 2026. CertiK calculó las pérdidas en aproximadamente USD $820.000, mientras SlowMist estimó el daño en USD $821.920. Las cifras describen el impacto del mismo incidente, aunque difieren en su valoración.

De acuerdo con los análisis citados en el reporte, el caso no se habría originado en el robo de una clave privada ni en la intervención de un miembro del proyecto, sino en la lógica incorporada al contrato del token. El atacante habría aprovechado un mecanismo que confundía transferencias de NEM hacia el pool con ventas, repetido la operación 42 veces y, después de retirar valor, trasladado los fondos a Ethereum.

La lógica del contrato detrás de la explotación

El componente señalado se llama pendingLpSellRecycle y forma parte de NemTokenV2, el contrato asociado al token NEM en BNB Chain. Su propósito era seguir y procesar ventas que llegaban al pool de liquidez, pero, según el análisis citado, la implementación no comprobaba que cada transferencia al par de intercambio correspondiera realmente a una venta ejecutada.

Ese detalle habría permitido que el atacante enviara repetidamente tokens NEM al pool de PancakeSwap y aprovechara la diferencia entre el saldo real de tokens y las reservas que el pool mantenía registradas. En un intercambio descentralizado, esas reservas reflejan la liquidez disponible; si el saldo real supera el valor contable registrado, el excedente puede quedar expuesto a extracción.

Según los hallazgos descritos en el reporte, el seguimiento defectuoso de ventas habría permitido generar esa discrepancia de manera reiterada, en lugar de limitarla a una transferencia aislada. El atacante habría ejecutado el ciclo 42 veces, y cada repetición habría reducido los recursos del pool y alterado sus reservas.

La operación también habría impulsado artificialmente el precio del token mientras avanzaba, de acuerdo con el análisis del incidente. Esa alteración habría afectado la referencia de precio que podían observar quienes negociaban NEM durante el ataque. El reporte no identifica un catalizador de mercado independiente: atribuye el movimiento a la propia operación.

Daño para la liquidez y traslado de fondos

CertiK Alert habría comunicado la explotación el 22 de octubre de 2026 y situado las pérdidas en torno a USD $820.000. SlowMist estimó el impacto en USD $821.920. La información citada no explica el método detrás de cada valoración, por lo que conviene mantener ambas cifras diferenciadas.

El objetivo directo habría sido el pool USDT/NEM de PancakeSwap, donde los proveedores aportan activos para facilitar las operaciones de intercambio. Cuando se sustrae valor de un fondo común de liquidez, quienes lo suministran quedan expuestos a las pérdidas del pool; en este caso, el movimiento artificial del precio también habría perturbado las condiciones de negociación durante la explotación.

Una vez extraído valor, el atacante habría trasladado los fondos a Ethereum, según los datos reportados. La información citada no detalla el procedimiento de traslado ni identifica al responsable, por lo que no permite atribuir la operación a una persona o grupo específico.

La diferencia entre las dos estimaciones de pérdidas no cambia el núcleo del incidente descrito: el contrato habría permitido manipular la contabilidad vinculada al pool y el ataque se habría repetido decenas de veces. Esto no significa que todos los titulares de NEM perdieran directamente la misma proporción de sus activos: el impacto reportado recae sobre la liquidez afectada y las condiciones de negociación durante la operación.

Un patrón de riesgo para tokens con lógica personalizada

El reporte también menciona otros casos de 2026 en BNB Chain que habrían involucrado tokens con tokenómica compleja y vulnerabilidades relacionadas con la manipulación de reservas. Entre los proyectos mencionados figuran Movie Token, ATM y LULA, que habrían sufrido ataques comparables a principios de ese año.

El elemento compartido no sería simplemente que esos tokens operen en una misma cadena, sino que incorporen lógica personalizada a sus interacciones con los pools de PancakeSwap. Un contrato que administra reglas propias junto a las reservas del intercambio puede crear supuestos contables adicionales; si estos no reflejan las operaciones reales, un atacante podría intentar explotarlos.

Para los desarrolladores, la advertencia concreta es no inferir la intención de una operación únicamente a partir del lugar donde termina una transferencia. En el caso de NEM, según el análisis citado, el contrato habría tratado el envío de tokens al par de liquidez como señal de una venta sin verificar que esa venta hubiera ocurrido. Esa diferencia entre inferencia y comprobación habría abierto el camino al ciclo repetido.

La revisión de seguridad, por tanto, no debería limitarse a examinar el contrato del token de forma aislada, según las recomendaciones recogidas en el análisis. También importa probar cómo interactúa su lógica personalizada con los pools de intercambio y sus reservas, para detectar fallas antes de que puedan traducirse en pérdidas para proveedores de liquidez y participantes del mercado.

Qué deben observar usuarios y equipos de proyectos

Para los usuarios de NEM y quienes aportaban liquidez al par USDT/NEM, el reporte señala que el pool fue objeto de una explotación y perdió valor. La alteración del precio durante el ataque habría añadido incertidumbre para los traders que operaron en ese periodo, aunque la información citada no cuantifica por separado las pérdidas individuales ni ofrece un balance posterior de las posiciones afectadas.

Los equipos que diseñan tokens pueden tomar este caso como una advertencia sobre mecanismos que mantienen registros paralelos a los de un intercambio descentralizado. Si un contrato clasifica movimientos por su destino, en vez de comprobar qué acción ocurrió en la transacción, podría interpretar como venta una transferencia que no lo fue y permitir que se distorsione el estado del pool.

La transparencia sobre las reglas de liquidez también adquiere importancia para quienes evalúan proyectos. Explicar qué hace la lógica personalizada y someterla a pruebas que cubran su interacción con los pools permitiría a usuarios y proveedores comprender mejor los riesgos, aunque ninguna revisión elimina por sí sola la posibilidad de fallas en contratos complejos.

El reporte atribuye análisis del incidente a CertiK y SlowMist. Una alerta posterior al ataque no revierte el movimiento de fondos; según la información citada, estos habrían sido trasladados a Ethereum.


Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

3h ago•
bullish:

0

bearish:

0

Share
Manage all your crypto, NFT and DeFi from one place

Securely connect the portfolio you’re using to start.