Resumen semanal de incidentes de seguridad Web3 | 2 de marzo – 8 de marzo de 2026

Durante la semana pasada (2026/03/02 - 2026/03/08), BlockSec detectó y analizó siete incidentes de ataque, con pérdidas totales estimadas de aproximadamente $3.25M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se presentan en las subsecciones siguientes.

*El incidente BUBU2 fue omitido en el informe de la semana pasada y se incluye aquí por completitud.

1. Incidente BUBU2

Breve resumen

El 1 de marzo de 2026, el token BUBU2 en BNB Chain fue explotado, resultando en pérdidas de aproximadamente $19.7K. La causa raíz fue un fallo de diseño del token: el contrato incorpora un mecanismo deflacionario acumulado en el tiempo que deduce directamente tokens de las reservas del par AMM al momento de la transferencia. El propietario del contrato redujo el intervalo de activación a un valor irrazonablemente pequeño antes del ataque, causando que cientos de rondas de quema se acumularan y ejecutaran en una sola llamada. El atacante aprovechó un préstamo flash para activar este mecanismo, colapsando las reservas del par e inflando el precio del token, y luego realizó un intercambio inverso a la tasa distorsionada para obtener ganancias.

Antecedentes

BUBU2 es un protocolo de token ERC-20 deflacionario desplegado en BNB Chain. El protocolo incorpora un motor deflacionario periódico controlado por burnAndMintSwitch: una vez habilitado por el propietario mediante setBurnAndMintSwitch(true), cualquier transferencia no exenta que active el gancho _update() invocará _triggerDailyBurnAndMint(), que quema tokens proporcionalmente del balance BUBU2 del par de trading según el número de períodos TRIGGER_INTERVAL transcurridos desde el último activador, y sincroniza las reservas en consecuencia.

Análisis de la vulnerabilidad

La causa raíz es un fallo de diseño en el contrato del token BUBU2 (0x3fF3...ee52). El contrato incorpora un mecanismo deflacionario periódico en su gancho _update(): cuando se activa, `_triggerDailyBurnAndMint()` calcula el número de períodos `TRIGGER_INTERVAL` transcurridos desde la última ejecución, y quema una cantidad proporcional de `BUBU2` directamente del par de trading ([0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)), seguido de un sync() para actualizar las reservas. De manera crítica, el propietario puede reconfigurar TRIGGER_INTERVAL sin ningún bloqueo de tiempo ni protección de límite mínimo.

Antes del ataque, el propietario llamó a setBurnAndMintSwitch(true) y luego a setTriggerInterval(120), comprimiendo el intervalo de las 6 horas predeterminadas a 120 segundos. Dado que lastTriggerTime todavía estaba anclado varias horas en el pasado, el siguiente activador calculó cientos de rondas acumuladas, y la cantidad quemada escaló linealmente con las rondas. Esto causó que una sola transferencia drenara una cantidad masiva de BUBU2 del par, colapsando sus reservas e inflando el precio del token aproximadamente 11x.

Análisis del ataque

El siguiente análisis se basa en la transacción 0x1bc0...141c,0x191c...1ee4,0xd6e5...51a6.

• Paso 1: El propietario del token primero habilitó el mecanismo deflacionario periódico mediante setBurnAndMintSwitch(true), luego acortó el intervalo de activación de las 6 horas predeterminadas a 120 segundos mediante setTriggerInterval(120). El atacante posteriormente tomó prestados 18 WBNB mediante un préstamo flash y los intercambió por aproximadamente 18,715,856 BUBU2 del pool.

• Paso 2: El atacante inició una pequeña transferencia, activando _triggerDailyBurnAndMint(). El balance de BUBU2 del pool disminuyó aproximadamente 1,025,988,664e18 tokens, dejando solo 6,493,352e18 BUBU2 restantes en la reserva después de que sync() se ejecutara, lo que infló el precio de BUBU2 aproximadamente 200x.

• Paso 3: El atacante vendió los BUBU2 adquiridos en el Paso 1 de vuelta al pool al precio inflado, recibiendo aproximadamente 50 WBNB. Tras devolver el préstamo flash, la ganancia neta fue de aproximadamente 32 WBNB.

Conclusión

El exploit de BUBU2 surgió de un fallo de diseño crítico en el contrato del token. El propietario configuró un TRIGGER_INTERVAL irrazonablemente pequeño, lo que permitió que el tiempo transcurrido se acumulara en cientos de rondas y drenara las reservas del par de trading en una sola llamada, causando un violento aumento en el precio de BUBU2.

Para reducir riesgos similares en el futuro:

• Proteger parámetros críticos como TRIGGER_INTERVAL con límites o bloqueos de tiempo.

• Limitar o restringir las rondas de ejecución acumuladas.

2. Incidente ACPRoute

Breve resumen

El 2 de marzo de 2026, el protocolo ACPRoute en Base fue explotado, resultando en pérdidas de aproximadamente $58K. La causa raíz fue una lógica de negocio defectuosa en el contrato del gestor de pagos: el estado del trabajo se cargó como una copia en memoria en lugar de una referencia de almacenamiento, por lo que el seguimiento acumulado de desembolsos nunca se persistió en la cadena. Esto permitió al atacante crear un trabajo, activar la liberación automática del pago durante la transición de fase, y luego reclamar los mismos fondos en custodia una segunda vez a través de una función de reclamación sin permisos.

Antecedentes

ACP (Agent Commerce Protocol) es un protocolo de comercio en cadena modular diseñado para interacciones entre clientes y proveedores. Estructura la actividad en tres capas: Cuentas, Trabajos y Memos. Los trabajos siguen un ciclo de vida fijo (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED), y los pagos son retenidos en custodia por el contrato PaymentManager durante la fase TRANSACTION. Cuando un trabajo llega a COMPLETED, el protocolo libera los fondos en custodia al proveedor mediante la función releasePayment(). Para evitar la doble reclamación, el protocolo rastrea los desembolsos acumulados por trabajo usando el campo amountClaimed en el struct Job. Se espera que cada llamada a la función releasePayment() compare la cantidad solicitada con amountClaimed para garantizar que los fondos solo se liberen una vez.

Análisis de la vulnerabilidad

La causa raíz se encuentra en la función releasePayment() del contrato PaymentManager (0x56c3...0684), donde el estado del trabajo se carga como una copia en memoria en lugar de una referencia de almacenamiento. Aunque el protocolo rastrea los desembolsos acumulados mediante amountClaimed para evitar la doble reclamación, el incremento job.amountClaimed += amount opera únicamente sobre una copia local transitoria y nunca se escribe de vuelta al almacenamiento en cadena. En consecuencia, cada invocación de la función releasePayment() observa amountClaimed == 0, permitiendo a un atacante llamar a la función claimBudget() y drenar el contrato víctima (0x307e...d6e8) una segunda vez después de que la transición de fase ya haya activado la función releasePayment() automáticamente.

Análisis del ataque

El siguiente análisis se basa en la transacción 0xe94a...f9a0.

• Paso 1: El atacante tomó prestados 97,000e6 USDC mediante préstamo flash como capital para el ataque posterior.

• Paso 2: Dentro del callback, el atacante llamó a la función createJob() en el ACPRouter, mientras desplegaba un nuevo contrato proveedor (0x1ee502dd...) para recibir los fondos.

• Paso 3: El atacante llamó repetidamente a la función createMemo() e invocó el propio exec() del contrato proveedor para avanzar la fase del trabajo, hasta que se activó la transición a la fase COMPLETED, llamando automáticamente a la función releasePayment() y liberando el saldo completo al contrato proveedor. En este punto amountClaimed debería haberse actualizado, pero su valor en almacenamiento permaneció en 0.

• Paso 4: El atacante llamó a la función claimBudget() y reclamó exitosamente los 97,000e6 USDC en custodia una segunda vez como ganancia.

Conclusión

Este incidente fue causado por un fallo de persistencia de estado que permitió que los fondos en custodia fueran reclamados dos veces dentro del mismo ciclo de vida del trabajo.

Para reducir riesgos similares en el futuro:

• Asegurarse de que las variables de estado críticas (por ejemplo, amountClaimed) se actualicen usando referencias de almacenamiento.

• Restringir las funciones de pago sensibles o aplicar una validación de estado estricta antes de la ejecución.

3. Incidente del Mercado sDOLA Llamalend

Breve resumen

El 2 de marzo de 2026, el Mercado sDOLA Llamalend en Ethereum fue explotado, resultando en pérdidas de aproximadamente $239K. La causa raíz es la manipulación de precios. Específicamente, sDOLA es un token ERC4626 cuyo precio puede ser manipulado mediante donate(). Llamalend es un mercado de préstamos basado en AMM, y debido al mecanismo de LLAMMA, los usuarios aún pueden volverse liquidables incluso cuando el precio del colateral sube. Por lo tanto, un atacante puede usar donate() para elevar el precio de sDOLA, llevar la salud de las posiciones de los usuarios por debajo de cero, y luego liquidar a esos usuarios para obtener ganancias.

Antecedentes

LLAMMA (Lending-Liquidating AMM Algorithm) es un mercado de préstamos basado en AMM utilizado por Curve [1]. A diferencia de los protocolos de préstamos tradicionales, LLAMMA coloca el colateral del usuario en bandas de precios dentro del AMM. A medida que el precio del oráculo $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ se mueve, el colateral se convierte progresivamente entre el token de colateral y crvUSD a través de intercambios impulsados por arbitraje entre bandas (liquidación suave), reduciendo gradualmente el riesgo de las posiciones en lugar de activar liquidaciones abruptas.

Si la liquidación suave no puede reducir el riesgo de una posición con suficiente rapidez, se activa la liquidación forzosa [2], que se desencadena cuando la salud de una posición cae por debajo de cero. La salud se calcula mediante get_x_down() [3], que no simplemente marca el colateral a mercado. En cambio, simula una conversión de ida y vuelta de la posición del usuario para evaluar su valor recuperable. Esta conversión de ida y vuelta utiliza dos anclajes de precio diferentes: uno derivado del $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ actual (se mueve con el oráculo en vivo), y otro derivado de los límites de banda del usuario (fijos cuando se creó la posición).

Análisis de la vulnerabilidad

Los contratos con errores incluyen el Controlador crvUSD (0xad44...fb86) y el AMM LLAMMA (0x0079...a1f7). El contrato víctima es el mercado sDOLA Llamalend (0x2b08...4fbe).

sDOLA es un token de bóveda ERC4626 cuyo precio de participación está determinado por la proporción de activos totales a participaciones totales. Dado que cualquiera puede llamar a donate() para agregar activos a la bóveda, el precio de participación puede inflarse dentro de una sola transacción. Este es el oráculo manipulable del que depende la función de salud de LLAMMA.

Como se describe en los Antecedentes, get_x_down() calcula la salud simulando una conversión de ida y vuelta a través de dos anclajes de precio: uno derivado de $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ (dinámico, se mueve con el oráculo en vivo), y otro derivado de los límites de banda del usuario (estático, fijo en el momento de creación de la posición). El protocolo no aplica ningún retraso ni verificación de coherencia al leer $P{}_{oracle}P\backslash \backslash \_\{oracle\}$. Por lo tanto, cuando el precio del oráculo se infla, el anclaje dinámico sube pero el anclaje estático permanece igual. En efecto, la simulación convierte crvUSD a colateral al precio inflado del oráculo y convierte de vuelta al precio de banda original, por lo que el valor recuperable evaluado se reduce a medida que aumenta la brecha entre los dos anclajes. Esto lleva la salud por debajo de cero, aunque el precio del colateral haya subido.

Análisis del ataque

El siguiente análisis se basa en la transacción 0xb935...d8a4.

• Paso 1: Manipular el estado de LLAMMA (grandes intercambios) para mover active_band y llevar a muchos usuarios a una postura de solo x (solo crvUSD).

• Paso 2: Manipular el precio de sDOLA mediante donaciones, luego usar un intercambio de cantidad cero (swap(0)) para escribir el precio manipulado en el pool AMM.

• Paso 3: Activar el recálculo de salud mediante users_to_liquidate() -> _health() -> get_x_down().

• Paso 4: Debido a que get_x_down() calcula el valor recuperable a través de dos anclajes de precio divergentes (el anclaje dinámico, ahora inflado, frente al anclaje estático, sin cambios), la conversión de ida y vuelta produce un descuento en el valor efectivo, y muchas posiciones cruzan por debajo de cero en salud.

• Paso 5: Liquidar forzosamente a esos usuarios en lote para obtener ganancias.

Además, la traza incluye dos llamadas a create_loan(). El primer préstamo se utilizó principalmente para financiar operaciones de intercambio de crvUSD de gran tamaño. El segundo préstamo se usó para obtener crvUSD para pagar la deuda de la primera posición y reciclar capital. Estos dos préstamos son principalmente segmentos de financiamiento/liquidación y no son los pasos principales del exploit en sí mismos.

Conclusión

El incidente es un ataque de manipulación del precio del colateral. El atacante manipuló el precio de sDOLA dentro de la transacción y, debido al mecanismo de salud basado en rutas de LLAMMA, llevó a los usuarios a condiciones de liquidación. Una consecuencia clave es que las posiciones aún pueden volverse liquidables incluso cuando el precio del colateral aumenta. Direcciones recomendadas de fortalecimiento:

• Usar precios de colateral retrasados o TWAP para la liquidación.

Referencias

• [1] Documentación de Curve crvUSD LLAMMA: [https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)

• [2] Explicación de liquidación de Curve LLAMMA: [https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)

• [3] Documento técnico de Curve stablecoin: [https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. Incidente del V4 Router por z0r0z

Breve resumen

El 3 de marzo de 2026, el V4 Router por z0r0z en Ethereum fue explotado, resultando en pérdidas de aproximadamente $42K. El ataque fue causado por una lógica de autorización defectuosa en swap(), donde el router dependía de un desplazamiento de calldata fijo en ensamblado en línea para verificar que el pagador coincidiera con msg.sender. Debido a que la codificación ABI para tipos dinámicos no garantiza un diseño fijo, el atacante fue capaz de construir calldata no estándar pero válido que omitió la verificación, se hizo pasar por una víctima previamente aprobada como pagador, y redirigió la salida del intercambio a una dirección controlada por el atacante.

Antecedentes

El protocolo hereda del Router de Uniswap v4 y sobreescribe algunos de sus métodos. En esencia, funciona como un router de intercambio, permitiendo a los usuarios evitar interactuar directamente con el pool correspondiente y utilizar el router como punto de entrada unificado.

Análisis de la vulnerabilidad

La causa raíz es una lógica de negocio defectuosa en el contrato V4 Router (0x0000...ce97). El contrato víctima es 0x65a8...7675. La función swap() acepta dos parámetros: data (bytes) y deadline (uint256). Dentro de la función, una verificación de autorización utiliza un bloque de ensamblado en línea para comparar calldataload(164) con caller(), asegurando que el pagador codificado en data coincida con msg.sender. El protocolo asume que el desplazamiento de bytes siempre es 0x40, colocando al pagador en la posición de byte 164 (0xa4).

Sin embargo, la codificación ABI no garantiza este diseño: los parámetros dinámicos almacenan solo un desplazamiento en el encabezado, y ese desplazamiento puede apuntar legalmente a cualquier ubicación alineada en el calldata. Al construir una codificación válida pero no estándar donde el desplazamiento de bytes se mueve a 0xc0, un atacante puede insertar relleno arbitrario entre el encabezado y la cola real. El atacante coloca su propia dirección en la posición de byte 164 para pasar la verificación de ensamblado, mientras que el payload de bytes real en la cola reubicada codifica la dirección de la víctima como pagador. Al seleccionar una víctima que haya aprobado previamente el router y establecer el receptor como su propia dirección, el atacante puede redirigir la salida del intercambio y robar fondos.

Análisis del ataque

El siguiente análisis se basa en la transacción 0xfe34...466a.

• Paso 1: Seleccionar un usuario que haya aprobado previamente el router como objetivo.

• Paso 2: Construir el calldata para eludir la verificación de autorización.

• Paso 3: Especificar a la víctima como pagador en los datos, establecer la propia dirección del atacante como receptor del token, y luego robar los activos de la víctima.

Conclusión

Este incidente fue causado por depender de un desplazamiento de calldata codificado de forma fija para la autorización en la ruta de intercambio. Debido a que la codificación ABI para tipos dinámicos no garantiza un diseño fijo, el atacante eludió la verificación con calldata no estándar pero válido, se hizo pasar por una víctima aprobada como pagador, y redirigió la salida del intercambio.

Para reducir riesgos similares en el futuro:

• Nunca depender de desplazamientos de calldata codificados de forma fija para parámetros ABI dinámicos.

• Decodificar y validar entradas estructuradas usando decodificación ABI canónica en lugar de suposiciones posicionales manuales.

• Asegurarse de que el pagador real, el receptor y el flujo de tokens sean validados consistentemente con respecto al llamador previsto y el contexto de ejecución.

5. Incidente del Contrato BitcoinReserveOffering

Breve resumen

El 5 de marzo de 2026, el contrato BitcoinReserveOffering en Ethereum fue explotado, resultando en una pérdida de aproximadamente $2.7 millones. La causa raíz fue una lógica de negocio defectuosa: al procesar un depósito completo de SFT ERC-3525, la lógica de acuñación se ejecutó dos veces dentro de una sola llamada, una vez durante un callback de transferencia y otra en el flujo principal. El atacante explotó este comportamiento de doble acuñación a través de ciclos repetidos de quema y acuñación, inflando exponencialmente su balance de tokens BRO, y luego canjeó el exceso por SolvBTC para realizar la ganancia.

Antecedentes

BitcoinReserveOffering es un contrato envolvente que convierte posiciones SFT ERC-3525 en tokens ERC-20 BRO transferibles. Los usuarios pueden llamar a la función mint() para depositar SFTs elegibles, y el contrato acuñará una cantidad correspondiente de BRO basándose en una tasa de cambio configurada. Si un usuario deposita solo parte del valor de un SFT, el contrato transfiere la cantidad especificada a su posición retenida internamente y luego acuña el valor correspondiente de BRO. Si un usuario deposita un SFT completo, el contrato transfiere el token completo al contrato envolvente y acuña BRO basándose en el valor total del SFT. Los usuarios pueden luego llamar a la función burn() para canjear BRO de vuelta a su posición SFT ERC-3525 correspondiente, convirtiendo el valor ERC-20 envuelto de vuelta en una posición SFT.

Análisis de la vulnerabilidad

La causa raíz es que el contrato BitcoinReserveOffering (0x15f7...cfcf) ejecuta la lógica de acuñación dos veces al procesar un depósito completo de SFT ERC-3525 en la función mint(). Específicamente, en la rama amount_ == sftBalance, mint() llama a ERC3525TransferHelper.doSafeTransferIn() para transferir de forma segura el SFT completo al contrato, lo que activa el callback onERC721Received(). Dentro de este callback, el contrato ya calcula el valor del SFT y acuña BRO al remitente. Después de que el callback regresa, mint() continúa la ejecución, recalcula el valor usando el mismo amount_, y realiza una segunda operación _mint(msg.sender, value). Este comportamiento de doble acuñación permite a un atacante inflar repetidamente su balance de BRO a través de un bucle de quema y acuñación.

Análisis del ataque

El siguiente análisis se basa en la transacción 0x44e6...958d.

• Paso 1: El atacante transfirió 135e18 tokens BRO al contrato de ataque como capital inicial.

• Paso 2: El atacante ejecutó el siguiente bucle:

1. Envolver 135e18 tokens BRO en un token SFT.

2. Llamar a mint() con el valor completo del SFT, lo que activa el callback onERC721Received() y acuña 135e18 tokens BRO; el mint() externo luego continúa y llama a _mint() nuevamente, resultando en una doble acuñación de 270e18 tokens BRO en total.

3. Envolver los 270e18 tokens BRO de vuelta en un token SFT.

• Paso 3: Después de repetir el Paso 2 22 veces, el atacante acumuló aproximadamente 567,758,816e18 tokens BRO, que finalmente se canjearon por 38e18 SolvBTC como ganancia.

Conclusión

Este incidente fue causado por la doble acuñación durante depósitos completos de SFT, permitiendo al atacante inflar exponencialmente su balance de BRO a través de ciclos repetidos de quema-acuñación y canjear el exceso por SolvBTC.

Para reducir riesgos similares en el futuro:

• Asegurarse de que la contabilidad de activos ocurra solo una vez por operación de depósito.

• Agregar verificaciones de invariantes para evitar que las cantidades acuñadas excedan el valor depositado subyacente.

6. Incidente MoltEVM

Breve resumen

El 7 de marzo de 2026, el protocolo MoltEVM en Base fue explotado, resultando en pérdidas de aproximadamente $127K. La causa raíz fue una lógica de control de acceso defectuosa en el contrato del token: la función de acuñación privilegiada estaba protegida por un modificador que solo verificaba si el llamador era un contrato con una interfaz específica, lo que podía ser fácilmente falsificado. El atacante desplegó un contrato malicioso para eludir la verificación, acuñó una gran cantidad de tokens, y los vendió a través del pool de liquidez para obtener ganancias.

Antecedentes

MoltEVM es un protocolo de token ERC-20 experimental desplegado en Base que explora un modelo de token autorreplicante. El sistema permite que un token genere nuevos tokens hijos ("tokens Moltling") una vez que se alcanzan ciertos umbrales de reserva. Cuando se crea un nuevo Moltling, un suministro inicial de tokens se distribuye a través de la función mintFromSpawner(), y se siembra liquidez automáticamente para establecer un mercado de trading para el nuevo token. Este diseño permite que el protocolo expanda su linaje de tokens de forma autónoma, con cada generación de tokens capaz de generar más descendientes.

Análisis de la vulnerabilidad

La vulnerabilidad reside en la lógica de control de acceso de las funciones mintFromSpawner() y setExemptFromSpawner() en el contrato MoltEVM (0x225d...501f). Ambas funciones dependen del modificador onlySpawnerToken, que estaba destinado a restringir las llamadas a contratos Moltling legítimos generados por el protocolo.

Sin embargo, el modificador realiza solo dos verificaciones débiles: verifica que msg.sender sea un contrato y que llamar a initialized() en el llamador devuelva true. Debido a que estas condiciones pueden ser trivialmente satisfechas por cualquier contrato arbitrario que implemente la misma interfaz, la verificación no proporciona una autenticación significativa de tokens de spawner legítimos.

Como resultado, un atacante puede desplegar un contrato mínimo que simplemente implementa una función initialized() que devuelve true. Una vez desplegado, el contrato malicioso puede llamar libremente a mintFromSpawner() para acuñar cantidades arbitrarias de tokens y también puede invocar setExemptFromSpawner() para agregar a la lista blanca direcciones controladas por el atacante. Esto efectivamente otorga al atacante control total sobre la ruta de acuñación y permite que los tokens recién acuñados sean vendidos en pools de liquidez para obtener ganancias.

Análisis del ataque

El siguiente análisis se basa en la transacción 0x10b7...e03d.

• Paso 1: El atacante desplegó un contrato mínimo que implementa una única función initialized() codificada para devolver true, lo que fue suficiente para pasar la verificación del modificador onlySpawnerToken.

• Paso 2: El contrato del atacante llamó a la función setExemptFromSpawner() protegida por el mismo modificador onlySpawnerToken vulnerable para agregar la dirección del atacante a la lista blanca de exención de impuestos. Esto aseguró que las posteriores ventas masivas de tokens no activaran impuestos de venta ni la lógica de intercambio interna, maximizando las ganancias.

• Paso 3: El atacante repitió la secuencia de funciones setExemptFromSpawner() + mintFromSpawner() contra mEVM primero, seguido de múltiples tokens hijos Moltling incluyendo CSPAWN, CCUTTL, LWORM y NHYDRA, acuñando tokens en lote en todos los objetivos y vendiéndolos en sus respectivos pools de liquidez para extraer ganancias.

Conclusión

Este incidente fue causado por un control de acceso insuficiente en las funciones privilegiadas de acuñación y configuración, permitiendo a un atacante hacerse pasar por un spawner legítimo y acuñar tokens arbitrarios para obtener ganancias.

Para reducir riesgos similares en el futuro:

• Aplicar un control de acceso estricto para las funciones privilegiadas de acuñación o configuración.

• Evitar depender de verificaciones de contratos fácilmente falsificables para la autorización.

• Validar la identidad del llamador mediante listas blancas explícitas o registros de contratos de confianza.

7. Incidente LEDS

Breve resumen

El 8 de marzo de 2026, el token LEDS en BNB Chain fue explotado, resultando en pérdidas de aproximadamente $64K. La causa raíz fue una lógica de negocio defectuosa: el contrato del token expone múltiples mecanismos deflacionarios independientes, cada uno capaz de quemar tokens directamente del par de liquidez, y ninguno está protegido por control de acceso o tiempo de espera. El atacante encadenó todas las rutas de quema dentro de una sola transacción, colapsando la reserva de LEDS del par a casi cero mientras la reserva de WBNB permanecía intacta, luego realizó intercambios inversos para drenar el pool desequilibrado para obtener ganancias.

Antecedentes

LEDS es un token deflacionario en BNB Chain con mecánicas de tarifa en transferencia incorporadas. Su _transfer() implementa múltiples mecanismos de quema diseñados para reducir gradualmente el suministro y apoyar el precio: una función de quema diaria triggerDailyBurnAndMint(), una quema diferida mediante acumulación de stor_18 en ventas, y una rama especial que quema tokens a 0xdead cuando el receptor del intercambio se establece en el Router de PancakeSwap. El token también presenta una función deposit() donde los usuarios envían BNB para acuñar LEDS y proporcionar liquidez, ganando recompensas LP reclamables a través de un distribuidor.

Análisis de la vulnerabilidad

La causa raíz es una lógica de negocio defectuosa en el contrato del token LEDS (0xfb62...a48f). La víctima es el par LEDS/WBNB (0xd109...6f3f). El token implementa múltiples mecanismos deflacionarios: triggerDailyBurnAndMint(), acumulación de stor_18 en la ruta de venta, y una rama de quema to == router en _transfer(). Cada uno de estos elimina independientemente LEDS del par de liquidez y llama a sync() para actualizar las reservas.

Si bien individualmente estos mecanismos sirven como herramientas de deflación gradual, pueden encadenarse juntos dentro de una sola transacción para multiplicar sus efectos. Además, la función pública 0x17a06174() permite a cualquiera vaciar el balance acumulado completo de stor_18 a voluntad, sin control de acceso ni limitación de velocidad. Al apilar secuencialmente estas rutas de quema, un atacante puede reducir la reserva de LEDS del par a casi cero mientras deja la reserva de WBNB intacta, creando una dislocación extrema de precio explotable mediante intercambios inversos.

Análisis del ataque

El siguiente análisis se basa en la transacción 0x2608...79da.

• Paso 1: El atacante obtuvo una gran cantidad de WBNB mediante préstamos flash (Moolah + préstamo de colateral Venus + Aave + PancakeSwap V4).

• Paso 2: Realizó múltiples llamadas a deposit() para acumular recompensas LP, luego activó triggerDailyBurnAndMint(), que quemó una porción de LEDS del par y envió recompensas al distribuidor, reduciendo la reserva de LEDS en el pool.

• Paso 3: Llamó a la función 0xde1b1942() para reclamar las recompensas acumuladas de tokens LEDS.

• Paso 4: Vendió los LEDS reclamados por WBNB. Dado que el balance de LEDS del par excedió el umbral después de la venta, la cantidad transferida se acumuló en stor_18 (quema pendiente).

• Paso 5: Compró LEDS a través de PancakeSwap con el receptor establecido en la dirección del Router. Esto activó una rama especial en _transfer() que quemó los LEDS comprados directamente del par a 0xdead, reduciendo aún más la reserva de LEDS del pool.

• Paso 6: Llamó a la función 0x17a06174(), que quemó el balance completo de stor_18 (acumulado en el Paso 4) del par a 0xdead y llamó a sync(), colapsando la reserva de LEDS del pool a solo 2 wei.

• Paso 7: Realizó intercambios inversos para drenar WBNB del pool ahora gravemente desequilibrado, devolvió todos los préstamos flash, y obtuvo una ganancia de 104.56 WBNB ($64K).

Conclusión

Este incidente fue causado por múltiples mecanismos deflacionarios sin protección que pueden encadenarse dentro de una sola transacción para agotar catastróficamente las reservas del par de liquidez.

Para cualquier contrato de token que implemente mecánicas deflacionarias o de quema automática, los desarrolladores deben:

• Nunca exponer funciones de quema del par sin el control de acceso adecuado, limitación de velocidad o aplicación de tiempo de espera.

• Evitar permitir que múltiples mecanismos de quema independientes se activen secuencialmente dentro de una sola transacción.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo del ciclo de vida completo de protocolos y plataformas.

BlockSec ha publicado múltiples documentos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares, y ha asegurado miles de millones en criptomonedas.

• Sitio web oficial: https://blocksec.com/

• Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam

• 🔗 Servicio de Auditoría de BlockSec : Enviar una solicitud

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance