Resumen semanal de incidentes de seguridad en Web3 | 16 – 22 de mar de 2026

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

*El incidente de Venus no fue cubierto en el informe de la semana pasada y se incluye aquí por completitud.

1. Incidente Venus

Breve Resumen

El 15 de marzo de 2026, el mercado THE (Thena) del protocolo Venus en BNB Chain sufrió un ataque de donación combinado con manipulación de mercado, resultando en aproximadamente ~$2.15M en deuda incobrable. El límite de suministro del mercado THE solo se aplicaba a la ruta de acuñación, mientras que las donaciones directas de tokens al mercado seguían incrementando cash e inflando el exchangeRate. El atacante aprovechó este valor de colateral inflado para tomar prestados activos líquidos, adquirir más THE mientras impulsaba el precio de mercado del token THE, dejando finalmente al protocolo con deuda incobrable tras la liquidación forzada de la posición.

Antecedentes

Venus es un protocolo de préstamos bifurcado de Compound V2. En el mercado THE, los usuarios depositan THE y reciben tokens vTHE. El exchangeRate determina cuántos activos subyacentes del mercado representa cada vTHE, y su fórmula central es:

exchangeRate = (cash + borrows - reserves) / totalSupply

Aquí, cash es el saldo del token subyacente del mercado, borrows es la deuda total pendiente, reserves son las reservas propias del protocolo, y totalSupply es el suministro total de vTHE. El mercado THE también tiene un límite de suministro destinado a limitar la exposición total de colateral.

Análisis de Vulnerabilidad

Este incidente involucró dos vectores compuestos contra el contrato del mercado vTHE (0x86e0...739f).

Ataque de Donación

El protocolo deriva cash directamente del saldo de tokens sin procesar del contrato de mercado, lo que lo hace inherentemente susceptible a ataques de donación. Cualquier transferencia directa de THE al contrato del mercado vTHE incrementa cash y, por lo tanto, el exchangeRate. El atacante explotó esto para inflar el exchangeRate aproximadamente 3.81×, amplificando el valor de colateral de su posición vTHE existente.

Manipulación de Mercado

El token THE tenía poca liquidez en cadena, lo que hacía que su precio spot fuera susceptible a manipulación mediante una presión de compra relativamente modesta. El oráculo del protocolo está diseñado para rechazar precios que se desvíen demasiado de una referencia, lo cual rechazó correctamente los precios extremos durante aproximadamente 37 minutos durante el ataque. Sin embargo, la presión de compra sostenida finalmente empujó el precio del token THE a aproximadamente $0.51, aproximadamente el doble de su precio previo al ataque, que el oráculo finalmente aceptó.

Estos dos vectores se reforzaron mutuamente. El exchangeRate inflado por el ataque de donación amplificó el valor de colateral de cada unidad vTHE, mientras que el precio manipulado del token THE infló aún más la capacidad de endeudamiento. Juntos, permitieron al atacante acumular ~$14.9M en préstamos contra una posición que era 3.67× el límite de suministro.

Análisis del Ataque

El siguiente análisis se basa en la transacción de ataque de ejemplo 0xce6e3e...1f5fb0e.

• Paso 1: Una billetera vinculada al atacante recibió 7,447 ETH a través de 77 transacciones relacionadas con TornadoCash durante aproximadamente nueve meses. Ese ETH fue depositado en Aave y se tomaron prestados ~$9.92M en stablecoins para construir una posición vTHE de aproximadamente 12.2M THE, aproximadamente el 84% del límite de suministro de 14.5M THE.

• Paso 2: En la primera transacción de ataque, seis direcciones transfirieron aproximadamente 36M THE directamente al contrato del mercado vTHE. El contrato de ataque también tomó prestados 1.58M USDC, los resuministró, luego tomó prestados aproximadamente 4.6M THE y los transfirió directamente a vTHE. Esto elevó el exchangeRate en aproximadamente 3.81x.

• Paso 3: En las transacciones posteriores, el atacante tomó prestados activos líquidos, incluyendo CAKE, BNB, BTCB y USDC. El atacante siguió comprando THE con activos prestados y donando más THE a vTHE, creando un bucle que incrementaba tanto el poder de endeudamiento de la posición como el precio de mercado del token THE.

• Paso 4: El precio del token THE subió desde aproximadamente $0.2, con la fuente de precio de Binance acercándose brevemente a $4. El oráculo del protocolo rechazó los precios extremos durante aproximadamente 37 minutos antes de aceptar finalmente un precio de aproximadamente $0.51.

• Paso 5: Para las 20:42 UTC+8, la posición del atacante alcanzó aproximadamente 53.2M THE, aproximadamente 3.67x el límite de suministro, con una exposición total de préstamos de aproximadamente ~$14.9M.

• Paso 6: La posición entró entonces en grandes liquidaciones. Aproximadamente 42M THE de colateral fue liquidado en 8,048 transacciones de liquidación de 254 direcciones de liquidadores. A medida que continuaba la venta, THE cayó a aproximadamente $0.22. Los ingresos de la liquidación no pudieron cubrir la deuda total, dejando a Venus con ~$2.15M en deuda incobrable neta.

Conclusión

Este incidente no reveló ninguna vulnerabilidad novedosa. Demostró cómo un vector de ataque bien conocido, ejecutado metódicamente, puede abrumar toda la pila de riesgos de un protocolo cuando cada capa asume que las demás aguantarán. Las señales de advertencia habían sido visibles en cadena durante meses, pero la brecha entre la detección y la intervención no fue atendida. Cerrar esa brecha mediante parámetros de riesgo conscientes de la liquidez, disyuntores automáticos y monitoreo a nivel de posición es la lección central que este incidente deja para otros protocolos de préstamos.

Para un análisis detallado, consulte nuestra publicación en profundidad [1].

Referencias

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. Incidente dTRINITY

Breve Resumen

El 17 de marzo de 2026, dTRINITY, un protocolo de préstamos bifurcado de Aave V3 en Ethereum, fue explotado a través de su mercado de préstamos dLEND, resultando en una pérdida de ~$257.3K. La causa raíz fue la vulnerabilidad de mercado vacío inherente a las bifurcaciones de Aave V3. Cuando una reserva tiene una liquidez cercana a cero, la acumulación repetida de primas de préstamos flash impulsa el liquidityIndex a un valor extremo. Una vez distorsionada la contabilidad de la reserva, el atacante explotó la pérdida de precisión en las rutas de depósito y retiro para sobreestimar el colateral, tomar prestados dUSD y recuperar el cbBTC depositado obteniendo una ganancia neta.

Antecedentes

dTRINITY incluye el sistema de stablecoin dUSD y dLEND, un mercado de préstamos bifurcado de Aave V3. En el contrato central L2Pool (0xfda3...e19e84), cada activo tiene su propia reserva, y la contabilidad de la reserva se basa en saldos escalados y un liquidityIndex a nivel de reserva. El saldo subyacente actual de un usuario se deriva del saldo escalado multiplicado por el ingreso normalizado de la reserva.

Las primas de los préstamos flash se añaden a la contabilidad de la reserva a través de cumulateToLiquidityIndex(), donde:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

Cuando totalLiquidity se vuelve extremadamente pequeño, cada acumulación de prima puede empujar el liquidityIndex hacia arriba a una velocidad anormalmente rápida.

Análisis de Vulnerabilidad

La condición clave para el ataque era una reserva casi vacía en el mercado dLEND-cbBTC (0x504d...3acc). Una vez que la reserva fue comprimida a una sola participación escalada, las primas de los préstamos flash ya no se distribuían entre una base de suministro significativa. Los préstamos flash repetidos causaron por lo tanto que el liquidityIndex aumentara extremadamente rápido.

Tras inflar el liquidityIndex, la conversión de subyacente a escalado entró en un régimen de redondeo extremo. En este estado, un pequeño depósito podía acuñar una participación adicional, mientras que un retiro mucho mayor aún podía quemar solo una participación. Esta asimetría permitió al atacante sobreestimar el colateral aCbBTC y tomar prestados dUSD reales de una reserva diferente, porque las verificaciones de salud se realizaban a nivel del Pool y la reserva de cbBTC corrompida afectaba directamente el poder de endeudamiento entre activos.

Análisis del Ataque

El exploit consistió en dos transacciones: 0x8d33d6...40ae7139 y 0xbec4c8...4fc33260.

Transacción 1: manipulación del liquidityIndex

• Paso 1: Tomar prestado cbBTC de Morpho Blue.

• Paso 2: Depositar cbBTC en dLEND-cbBTC para acuñar 100 participaciones escaladas.

• Paso 3: Retirar 99 unidades de participaciones para que solo quede 1, comprimiendo la reserva dLEND-cbBTC a un estado de suministro escalado casi vacío.

• Paso 4: Transferir 80,000,000 unidades de cbBTC (es decir, 0.8 cbBTC) directamente al aToken de dLEND-cbBTC.

• Paso 5: Ejecutar 150 llamadas a Pool.flashLoan() para acumular prima en la contabilidad de la reserva, elevando el liquidityIndex a 6,226,621,999,999,999,999,999,999,979,728,276.

• Paso 6: Ejecutar ciclos repetidos de depósito y retiro para extraer el efectivo residual de la reserva.

• Paso 7: Reembolsar el préstamo flash.

Transacción 2: realización de ganancias

• Paso 1: Tomar prestado cbBTC nuevamente de Morpho Blue.

• Paso 2: Depositar ~7.72 cbBTC en la reserva ya manipulada para construir una posición de colateral aCbBTC sobreestimada.

• Paso 3: Usar el colateral sobreestimado para tomar prestados 257,328 dUSD del mercado dLEND-dUSD.

• Paso 4: Continuar la extracción de cbBTC mediante ciclos repetidos de depósito/retiro.

• Paso 5: Reembolsar el préstamo flash de Morpho y transferir los dUSD prestados a la EOA del atacante.

Conclusión

Este incidente es un ejemplo del ataque de mercado vacío que ha sido bien documentado en las bifurcaciones de Aave V3. Este patrón ha aparecido en múltiples protocolos, y la mitigación está bien establecida. Aplicar un umbral mínimo de suministro durante la inicialización de la reserva evita que la reserva entre en un estado donde el crecimiento del índice se vuelve incontrolable. Los protocolos que bifurcan Aave V3 deben por lo tanto tratar el arranque de reservas como una operación crítica y garantizar que se bloquee liquidez significativa en el despliegue, en lugar de depender del flujo de depósitos orgánicos para estabilizar el índice.

3. Incidente Fun.xyz

Breve Resumen

El 17 de marzo de 2026, Fun.xyz, un protocolo de infraestructura de pago en Polygon, fue explotado por ~$85.7K. La causa raíz fue que el CheckoutPool heredado exponía una función crítica bridge() sin control de acceso y sin vincular los datos de llamada del puente al destinatario previsto. Esta vulnerabilidad permitió al atacante redirigir la ejecución hacia la ruta de liquidación de confianza y transferir fondos a una cuenta inteligente controlada por el atacante.

Antecedentes

CheckoutPool es el contrato central de liquidación en la infraestructura de pago de Fun.xyz. En el flujo normal, un usuario crea un pago mediante deposit(), y un operador de confianza lo avanza a través de rutas de liquidación como bridge() y execute(). Para las operaciones de puente, bridge() ejecuta una llamada externa basada en bridgeParams.target y bridgeParams.callData proporcionados por el llamador.

Análisis de Vulnerabilidad

La causa raíz es que el CheckoutPool heredado (0x1304...2ec01a) exponía una ruta de enrutamiento de liquidación sensible a través de la función bridge() sin un control de acceso adecuado, al tiempo que tampoco validaba los datos de llamada del puente proporcionados externamente contra el destinatario previsto. Específicamente:

• La implementación heredada no aplicaba onlyOperator en bridge(), permitiendo que cualquier llamador externo invocara la función después de crear un pago mediante deposit().

• bridge() pasaba los bridgeParams proporcionados por el llamador a _bridgeToRecipient(), que realizaba una llamada externa sin validar el destinatario contra el registro de pago.

Una condición operativa adicional hizo que el exploit fuera práctico: el CheckoutPool heredado aún conservaba privilegios de operador en CheckoutPaymaster en el momento del exploit. Esto permitió que la llamada bridge() manipulada llegara a CheckoutPaymaster.activateAndCall(), que luego invocó la ruta más nueva CheckoutPool.execute(), transfiriendo fondos a una dirección bajo control del atacante.

Análisis del Ataque

El siguiente análisis se basa en la transacción de ataque 0x957bcf...1f4f5a.

• Paso 1: Crear la cuenta inteligente ERC-4337 0xb648 y designarla como tanto el remitente como el pagador en la UserOperation externa.

• Paso 2: Llamar a deposit() tanto en el CheckoutPool heredado como en el nuevo, creando un registro de pago en el nuevo CheckoutPool con un monto de liquidación de 85,730 USDC.

• Paso 3: Llamar a bridge() en el CheckoutPool heredado con bridgeParams maliciosos: establecer bridgeParams.target en CheckoutPaymaster y codificar bridgeParams.callData como una llamada a activateAndCall() que lleva la UserOperation externa como su carga útil interna.

• Paso 4: Llegar a execute() en el nuevo CheckoutPool (0x1929...0215), que transfiere 85,730 USDC a 0xb648, la dirección especificada como ops[0].sender en la UserOperation externa.

• Paso 5: Entrar en EntryPoint.handleOps(): debido a que 0xb648 sirve como tanto el remitente como el pagador, tanto la validación de la cuenta como la validación del pagador permanecen bajo el control del atacante, permitiéndole obtener una ganancia de 85,730 USDC.

Conclusión

Este incidente fue causado por la falta en el CheckoutPool heredado de control de acceso y de vinculación de datos de llamada al destinatario en su ruta bridge(), resultando en pérdidas de ~$85.7K. Para prevenir incidentes similares, los protocolos deben aplicar un control de acceso estricto en todos los flujos de enrutamiento y liquidación sensibles, garantizar que las cargas útiles proporcionadas externamente sean consistentes con los destinatarios derivados del protocolo, y eliminar los contratos obsoletos de las relaciones de privilegio de confianza una vez que se implementen los reemplazos parcheados.

4. Incidente Keom

Breve Resumen

El 18 de marzo de 2026, Keom, un protocolo de préstamos bifurcado de Compound V2 en Polygon zkEVM, fue explotado por aproximadamente $35K. La causa raíz fue una lógica de contabilidad defectuosa en redeemFresh(), llamada por redeemUnderlying(). La función limitó la reducción de participaciones al saldo real del usuario pero no recalculó el monto de retiro subyacente en consecuencia. Esta discrepancia permitió al atacante canjear muchos más activos de los que sus participaciones deberían permitir.

Antecedentes

Keom es un protocolo de préstamos bifurcado de Compound V2. Los usuarios suministran ETH al mercado y reciben kETH. Cuando un usuario canjea, el protocolo convierte las participaciones kETH de vuelta a ETH usando la tasa de cambio actual. Existen dos puntos de entrada de canje en el protocolo: redeem() para canjear por monto de participaciones, y redeemUnderlying() para canjear por el monto subyacente deseado.

Análisis de Vulnerabilidad

El fallo está en redeemFresh() del mercado kETH (0x4c6e...0403), llamado por redeemUnderlying(). El redeemAmountIn controlado por el usuario se asigna primero a redeemAmount, y luego se usa para calcular redeemTokens mediante la tasa de cambio actual. Si redeemTokens supera el saldo del canjeador, la función lo limita a accountTokens[redeemer]. Sin embargo, redeemAmount no se recalcula tras este límite y permanece igual al redeemAmountIn original. Esto permite al canjeador retirar el redeemAmount completo de activos subyacentes mientras solo quema una fracción de las participaciones correspondientes.

Como se muestra en el fragmento de código a continuación, redeemFresh() también realiza una verificación de salud mediante redeemAllowed(). En el diseño de Compound V2, redeemAllowed() verifica markets[cToken].accountMembership[redeemer] e invoca la verificación de liquidez solo cuando la cuenta ha ingresado a este mercado cToken; de lo contrario, la verificación se omite por completo. Dado que redeemAmountIn está controlado por el atacante y puede establecerse arbitrariamente grande, la verificación de liquidez fallaría si kETH aún cuenta como colateral. Esto significa que el fallo contable por sí solo no es directamente explotable sin primero eludir la verificación de salud.

Análisis del Ataque

El siguiente análisis se basa en la transacción de ataque 0x4ccde7...03d9dfd8.

• Paso 1: Invocar mint() con solo 0.001 ETH, obteniendo un saldo mínimo de kETH.

• Paso 2: Invocar exitMarket() para eliminar la membresía de la cuenta en el mercado kETH, de modo que redeemAllowed() omita completamente la verificación de liquidez (como se describe en el Análisis de Vulnerabilidad anterior).

• Paso 3: Invocar redeemUnderlying() para retirar todo el saldo de ETH del mercado (~38.6 ETH), explotando la contabilidad defectuosa para drenar ETH del mercado.

Conclusión

Este incidente fue causado por una vulnerabilidad contable que no recalcula redeemAmount después de limitar redeemTokens al saldo real del usuario, resultando en aproximadamente $35K en pérdidas. La lógica de canje debe recalcular todos los valores dependientes después de cualquier limitación o ajuste para preservar el invariante de participación a subyacente. Las bifurcaciones de Compound V2 deben revisar cuidadosamente esta ruta, ya que pueden existir fallos similares en otros derivados.

5. Incidente ShiMama

Breve Resumen

El 18 de marzo de 2026, ShiMama, un protocolo de token deflacionario en BNB Chain, fue explotado por aproximadamente $35K. La causa raíz fue la falta de control de acceso en la función executePairBurn(), que permitió a cualquier usuario desencadenar el retiro y quema de reservas del par, habilitando la manipulación de precios.

Antecedentes

El Protocolo ShiMama incluye un mecanismo de deflación en cadena destinado a extraer tokens del par AMM y quemarlos. Este mecanismo se implementa en ShiMama Protocol y ShiMama Token. La función executePairBurn() en ShiMama Protocol calcula un monto de extracción a partir de un parámetro referenceIn proporcionado por el llamador:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Luego llama a forcePullFromPair() de ShiMama Token, seguido de pair.sync() y una quema de los tokens extraídos.

Análisis de Vulnerabilidad

La causa raíz es la falta de control de acceso en executePairBurn() en el contrato ShiMamaProtocol (0x5049...0b49a). La función es llamable externamente sin restricciones, por lo que cualquier usuario puede desencadenar el movimiento de reservas privilegiado y la sincronización del par. referenceIn también está controlado por el llamador y no está vinculado a ningún monto de venta real. En ShiMamaToken.forcePullFromPair(), el protocolo puede mover directamente saldos del par Pancake sin ninguna restricción, permitiendo la eliminación arbitraria de reservas más sincronización inmediata y, por lo tanto, manipulación del precio spot.

Análisis del Ataque

El siguiente análisis se basa en la transacción de ataque 0x13959b...3c20e001.

• Paso 1: Tomar prestado WBNB del préstamo flash de Moolah.

• Paso 2: Transferir 30.78e18 ShiMama obtenidos previamente en una transacción anterior al contrato de ataque. Dado que las compras directas de ShiMama desde el par Pancake estaban deshabilitadas, el atacante obtuvo ShiMama proporcionando y retirando liquidez en ShiMama Protocol antes del ataque.

• Paso 3: Llamar a executePairBurn() para extraer 1,311,349,143.96 tokens ShiMama del par Pancake y quemarlos, inflando efectivamente el precio de ShiMama.

• Paso 4: El atacante intercambió 30.78e18 ShiMama por 52.98e18 WBNB en PancakeSwap al precio inflado.

• Paso 5: Reembolsar el préstamo flash, dejando 52.98 WBNB como ganancia neta.

Conclusión

Este incidente fue causado por la falta de control de acceso en executePairBurn(), que expuso una vía no autorizada para alterar las reservas del pool. Cualquier función que mute reservas es económicamente sensible y debe tener permisos estrictos. Las entradas controladas por el llamador deben estar vinculadas a valores derivados del protocolo para evitar la amplificación de la extracción de reservas.

6. Incidente BlindBox

Breve Resumen

El 19 de marzo de 2026, BlindBox, un protocolo de apuestas GameFi en BNB Chain, fue explotado por aproximadamente $99K. La causa raíz fue una aleatoriedad débil, que permitió al atacante predecir el resultado y lograr una tasa de victoria del 100%. Además, getTwapPrice() dependía de precios spot manipulables en lugar de un verdadero promedio ponderado por tiempo, lo que permitió al atacante inflar el precio del pool de antemano y realizar apuestas más grandes que los límites previstos del protocolo.

Antecedentes

BlindBox es un protocolo GameFi que permite a los usuarios realizar apuestas transfiriendo tokens ATM a la dirección muerta. El protocolo determina el resultado basándose en la paridad de un blockhash posterior. Si la apuesta gana, BlindBox paga 1.95x la cantidad original de ATM desde el capital de la dirección muerta. El protocolo usa getTwapPrice() para limitar el tamaño de cada apuesta.

Análisis de Vulnerabilidad

El contrato BlindBox (0x1F83...734c59) contiene dos vulnerabilidades:

1. Aleatoriedad débil: Cuando el tiempo de liquidación supera los 256 bloques, blockhash(bet.blockNum + 2) devuelve cero. El protocolo entonces recurre a la aleatoriedad derivada de block.prevrandao, betId y block.timestamp. Dado que estas entradas pueden simularse fuera de la cadena antes de enviar la transacción, el atacante podía invocar settle() solo cuando el resultado calculado era favorable, logrando una victoria determinista.

2. Límite de precio manipulable: El protocolo usa getTwapPrice() para restringir el tamaño de las apuestas. Sin embargo, esta función no implementa un verdadero precio promedio ponderado por tiempo; en cambio, lee el precio spot en el pool ATM/USDT. Esto permite a los atacantes eludir el límite manipulando el precio del pool antes de realizar su apuesta.

Análisis del Ataque

Los siguientes pasos ilustran el patrón de ataque. Los pasos 2 y 3 formaron una secuencia emparejada (p. ej., betId=5,284), y el atacante repitió este par múltiples veces para acumular ganancias.

• Paso 1: Manipular el pool ATM/USDT, inflando el precio spot de ATM para que getTwapPrice() permitiera un tamaño de apuesta mayor en el siguiente paso.

• Paso 2: Realizar una apuesta grande transfiriendo la cantidad de ATM con límite inflado a la dirección muerta (p. ej., 0x4be049...3af12c).

• Paso 3: Esperar hasta que hubieran pasado más de 256 bloques, de modo que blockhash devolviera cero y se activara la ruta de respaldo. El atacante entonces simuló resultados fuera de la cadena y llamó a settle() solo en un bloque donde el resultado calculado era favorable (p. ej., 0x68eedc...718ce8).

Conclusión

Este incidente fue causado por una aleatoriedad predecible, combinada con un precio spot manipulable como entrada TWAP, resultando en aproximadamente $99K en pérdidas. Para reducir riesgos similares, el protocolo debería eliminar cualquier ruta de liquidación que se vuelva predecible después de que expire la ventana de blockhash, y reemplazar getTwapPrice() con una fuente de precios resistente a la manipulación de reservas a corto plazo.

7. Incidente Resolv

Breve Resumen

El 22 de marzo de 2026, Resolv, un protocolo de stablecoin en Ethereum, experimentó un compromiso de clave de infraestructura que habilitó la ejecución no autorizada de lógica privilegiada de finalización de intercambios. En el incidente, el atacante abusó de la función privilegiada para acuñar más de 80M de USR sin colateral. El impacto se extendió más allá del evento de acuñación directo, ya que la resultante desvinculación de USR desencadenó un contagio más amplio en los protocolos de préstamos donde los activos de Resolv se usaban como colateral.

Antecedentes

Resolv es un protocolo de stablecoin en el que la emisión de USR depende de la liquidación de intercambios respaldados por colateral. Su canal de finalización de intercambios, completeSwap() -> mint() -> transfer(), afecta directamente el suministro circulante de USR y, por lo tanto, depende tanto de la integridad de la autorización como de la integridad del colateral. En condiciones normales, completeSwap() en el contrato Resolv (0xa27a...5861) solo puede ser llamado por una clave de infraestructura privilegiada (denominada SERVICE_ROLE en el código) después de que se haya verificado el depósito de colateral correspondiente.

Análisis de Vulnerabilidad

El incidente fue el compromiso de una clave privilegiada que invocó la lógica de liquidación de confianza y alcanzó la ruta de acuñación de USR sin un flujo de colateral equivalente. Una vez que el atacante obtuvo el control de la autoridad de firma privilegiada, la ruta completeSwap() no proporcionó ninguna aplicación de precondición de acuñación en cadena; la verificación del colateral dependía completamente de la autorización fuera de la cadena. Esto convirtió directamente un compromiso del plano de control en un fallo de integridad del suministro.

Análisis del Ataque

• Paso 1: Antes del exploit, el atacante envió una solicitud de intercambio en la transacción 0x590b5c...de732c89, preparando el estado necesario para la posterior finalización maliciosa del intercambio.

• Paso 2: Usando la clave privilegiada comprometida, el atacante invocó completeSwap() para acuñar más de 80,000,000 USR en tres transacciones: 0xfe37f2...dc33743, 0x41b6b9...db1f18f, y 0x7f9143...53a931d.

Conclusión

Este incidente subraya que la seguridad de las stablecoins depende de precondiciones de acuñación estrictas en cadena, no solo de roles de operador de confianza. En particular, el impacto de este incidente se extendió mucho más allá de los $80M en acuñación no autorizada de USR. Debido a que los activos de Resolv se usaban ampliamente como colateral en múltiples protocolos de préstamos, la desvinculación desencadenó un contagio más amplio. Como informó Chaos Labs, los curadores en cadena que utilizaban asignación automatizada en busca de rendimiento carecían de controles de riesgo en tiempo real y continuaron dirigiendo capital fresco hacia mercados ya deteriorados. Lo que comenzó como un exploit localizado escaló rápidamente a un evento de contagio entre protocolos, dejando a los protocolos de préstamos con millones en deuda incobrable.

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 artículos 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

• 🔗 Aplicación de Seguridad Phalcon: Reservar una demo

• 🔗 Cumplimiento Phalcon