Durante la semana pasada (2026/02/23 - 2026/03/01), BlockSec detectó y analizó siete incidentes de ataques, con pérdidas totales estimadas de ~$13M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se proporcionan en las subsecciones siguientes.
| Fecha | Incidente | Tipo | Pérdida estimada |
|---|---|---|---|
| 2026/02/22 | Incidente LAXO | Fallo en el diseño del token | ~$137K |
| 2026/02/22 | Incidente YieldBloxDAO | Configuración incorrecta del oráculo | ~$10M |
| 2026/02/23 | Incidente STO | Fallo en el diseño del token | ~$16.1K |
| 2026/02/25 | Incidente HedgePay | Lógica de negocio defectuosa | ~$15.7K |
| 2026/02/26 | Incidente Ploutos | Configuración incorrecta del oráculo | ~$390K |
| 2026/02/26 | Incidente FOOMCASH | Lógica de negocio defectuosa | ~$2.26M |
| 2026/02/27 | Incidente desconocido | Validación de entrada incorrecta | ~$180K |
1. Incidente LAXO
Breve resumen
El 22 de febrero de 2026, el token ERC20 LAXO en BNB Smart Chain fue explotado, lo que provocó aproximadamente $137,320 en pérdidas del par LAXO-USDT. La causa raíz fue un mecanismo de quema defectuoso que se activaba cuando LAXO era transferido directamente al par de PancakeSwap. Dado que el router estaba en la lista blanca y no activa la lógica de quema en transfer(), el atacante lo eludió: envió LAXO al par y luego llamó al swap() de bajo nivel del par, que quemó tokens del par e invocó sync(), inflando el precio. El atacante luego intercambió de vuelta a USDT para obtener ganancias.
Antecedentes
El token LAXO implementa un mecanismo de quema. Cuando el destinatario de una transferencia es la dirección del par PancakeSwap USDT–LAXO, el token lo trata como una venta: quema una cantidad correspondiente de tokens del par y luego llama a sync() para actualizar las reservas del par.
Además, el token LAXO implementa una lista blanca (_isExcludedFromFee) para eximir a ciertas direcciones (p. ej., routers de intercambio) del mecanismo de quema y de las comisiones.
Análisis de la vulnerabilidad
La causa raíz del incidente fue un mecanismo de quema defectuoso en el token LAXO. Específicamente, transferir LAXO directamente al par activa la quema, eliminando LAXO del par e inflando su precio. Como resultado, un atacante puede aprovechar esto para obtener ganancias mediante ataques de manipulación de precios.
Análisis del ataque
El análisis del ataque se basa en la transacción 0xd58f3ef6...d98ac7d3.
-
El atacante obtuvo mediante préstamo flash 350,000e18
USDTde PancakeSwap V3. -
El atacante intercambió
USDTporLAXOa través del router de PancakeSwap. Para eludir las restricciones de trading (buyEnabled = false) y la lógica de comisiones, el atacante creó un par V2 BNB–LAXO y enrutó las operaciones a través de él.
-
El atacante transfirió todo el
LAXOen su poder directamente al par USDT–LAXO. Esto redujo la reserva deLAXOen el pool mientras que la reserva deUSDTpermaneció casi sin cambios, aumentando dramáticamente el precio deLAXOen el par USDT–LAXO. -
El atacante intercambió
burnAmountdeLAXOpor ~487,500e18USDTbasándose en el precio manipulado. -
El atacante reembolsó el préstamo flash y retuvo el
USDTrestante como ganancia.
Conclusión
La causa raíz de este incidente proviene del mecanismo de quema defectuoso de LAXO, que permite a los atacantes drenar USDT del pool mediante ataques de manipulación de precios. Como resultado, el incidente ocasionó pérdidas totales de aproximadamente $137.3K. Para mitigar estos problemas, el proyecto debe realizar pruebas exhaustivas de su mecanismo de quema para evitar posibles ataques de manipulación de precios.
2. Incidente YieldBloxDAO
Breve resumen
El 22 de febrero de 2026, un pool de préstamos operado por YieldBlox DAO en Blend V2 de Stellar fue explotado, resultando en pérdidas superiores a $10 millones [1]. El incidente fue causado por una configuración incorrecta por parte del operador del pool (YieldBlox DAO) y no por una vulnerabilidad en los contratos inteligentes.
Específicamente, el atacante manipuló el mercado USTRY/USDC en SDEX. La ruta del oráculo Reflector configurada por el pool aceptó el precio manipulado, lo que sobrevaloró USTRY como garantía y permitió al atacante drenar los activos del pool, incluidos USDC y XLM.
Antecedentes
En la blockchain de Stellar, Blend V2 es un protocolo de liquidez que permite a los usuarios crear pools de préstamos aislados. Estos pools facilitan el préstamo y el endeudamiento entre usuarios para un conjunto de activos admitidos. Específicamente, el pool víctima en este incidente permite a los usuarios pedir prestado XLM y USDC usando USTRY como garantía. Además, el creador del pool especifica el oráculo Reflector [2] como proveedor de oráculos al momento de la creación. El precio de USTRY proporcionado por el oráculo Reflector se actualiza cada cinco minutos en función del mercado USTRY/USDC en el DEX de Stellar (es decir, SDEX) [3].
Análisis de la vulnerabilidad
La causa raíz fue la manipulación de precios en el mercado USTRY/USDC de escasa liquidez del SDEX, lo que provocó una actualización vulnerable del precio de USTRY en el oráculo Reflector. Específicamente, debido a la liquidez extremadamente reducida en el mercado USTRY/USDC, el atacante pudo consumir órdenes normales y colocar órdenes anormales para inflar el precio de USTRY 100 veces. Este precio inflado de USTRY fue luego propagado al oráculo Reflector, lo que permitió al atacante pedir prestados todos los activos (es decir, XLM y USDC) del pool víctima colateralizando USTRY sobrevalorado.
Análisis del ataque
- (Tx 1, 2) El atacante manipuló el precio de USTRY en el SDEX, llevándolo de $1.06 a aproximadamente $107. Como el mercado USTRY/USDC en el SDEX era extremadamente poco líquido, el atacante consumió todas las órdenes normales y luego colocó órdenes anormales, empujando bruscamente el precio de mercado al alza.
- (Tx 3) El oráculo Reflector obtuvo el precio manipulado del SDEX y actualizó su feed de precios en consecuencia.
- (Tx 4, 5) El atacante tomó prestado 1,000,196e7 USDC colateralizando 12,881e7 USTRY.
- (Tx 6, 7) El atacante tomó prestado 6,124,927,810e7 XLM colateralizando 14,987,610e7 USTRY.
- (Txs 8, 9, 10) Por último, el atacante puenteó los activos drenados a múltiples cadenas, incluyendo Base, BSC y Ethereum.
Las tablas a continuación resumen las transacciones clave del exploit y las direcciones relacionadas involucradas.
Conclusión
Aunque el incidente de YieldBloxDAO resultó en pérdidas significativas, el problema subyacente no es complejo: la valoración de la garantía depende de un precio vulnerable a la manipulación. Este incidente sirve como recordatorio de que la dependencia de precios para los protocolos de préstamo debe seleccionarse y monitorearse cuidadosamente.
Referencias
[2] https://reflector.network/
[3] Mercado USTRY/USDC en el SDEX
3. Incidente STO
Breve resumen
El 23 de febrero de 2026, un pool STO-WBNB en PancakeSwap en BNB Smart Chain fue drenado, resultando en aproximadamente $16.1K en pérdidas. La causa raíz fue un mecanismo de quema defectuoso en el token STO. Específicamente, cuando los usuarios vendían tokens STO en el pool, se activaba el mecanismo de quema, quemando tokens STO del pool e inflando el precio del token. Como resultado, el atacante explotó esta vulnerabilidad para drenar tokens WBNB del pool.
Antecedentes
El token STO introduce un mecanismo de quema dirigido al pool V2 de PancakeSwap. Este mecanismo se activa únicamente cuando la función de venta del token STO está habilitada (es decir, sellEnabled == true) y pendingBurnFromSell > 0. Cuando un usuario vende tokens STO, el mecanismo quema tokens STO del pool. Específicamente, el 94% de los tokens STO vendidos en la transacción anterior se queman durante el proceso de quema.
Análisis de la vulnerabilidad
La causa raíz del incidente es el mecanismo de quema defectuoso en el token STO. Específicamente, cuando un usuario vende tokens STO, el mecanismo de quema elimina una cierta cantidad de tokens STO del pool e invoca también la función sync() del contrato del par para actualizar las reservas. Este mecanismo de quema infla el precio del token STO en el pool. Como resultado, los atacantes pueden beneficiarse de este mecanismo llevando a cabo un ataque de manipulación de precios.
Análisis del ataque
El siguiente análisis se basa en la transacción 0x8ba17bea...5a54020c.
-
El atacante tomó prestado
360,894e18 WBNBmediante préstamo flash. -
El atacante invocó la función
initializeLiquidity()para habilitar la funcionalidad de compra y venta del tokenSTO.
-
El atacante intercambió
360,894e18 WBNBpor7,848,832e18 STO. -
El atacante invocó la función
transfer(), activando el mecanismo de quema para manipular las reservas del par (es decir, aumentó el precio del tokenSTO), al mismo tiempo que estableció la cantidad de tokensSTOa quemar en la siguiente transacción en173,391e18.
-
El atacante invocó la función
swap()para intercambiarSTOporWBNB. Este paso le permitió al atacante obtener ganancias basándose en el precio manipulado. -
El atacante repitió los pasos 4 y 5 para drenar el
WBNBdel pool. -
El atacante reembolsó el préstamo flash y obtuvo una ganancia de
26e18 WBNB.
Conclusión
La causa raíz de este incidente proviene del mecanismo de quema defectuoso de STO, que permite a los atacantes drenar WBNB del pool. Para mitigar estos problemas, el proyecto debe implementar controles de acceso adecuados dentro del sistema y realizar pruebas exhaustivas de su mecanismo de quema para evitar posibles ataques de manipulación de precios.
4. Incidente HedgePay
Breve resumen
El 25 de febrero de 2026, el protocolo HedgePay en BNB Smart Chain fue explotado, resultando en aproximadamente $15.7K en pérdidas. La causa raíz fue una lógica de negocio defectuosa en el contrato de staking del protocolo HedgePay. Específicamente, la función forceExit() del contrato de staking vulnerable (es decir, 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) permitía a los usuarios retirar sus activos apostados sin actualizar sus saldos apostados. Como resultado, el atacante pudo invocar repetidamente la función forceExit() para drenar los tokens HPAY del contrato.
Antecedentes
El protocolo HedgePay es un protocolo de staking que permite a los usuarios ganar recompensas apostando tokens HPAY. La función forceExit() permite a los usuarios retirar sus activos apostados.
Análisis de la vulnerabilidad
La causa raíz del incidente es una lógica de negocio defectuosa en la función forceExit(). Específicamente, cuando los usuarios apuestan tokens HPAY a través de la función stake(), su cantidad apostada (es decir, _balances[msg.sender]) se actualiza en consecuencia. Sin embargo, cuando los usuarios retiran sus tokens HPAY apostados a través de la función forceExit(), el contrato no actualiza _balances[msg.sender]. Como resultado, el atacante puede drenar los tokens HPAY en el contrato de staking invocando repetidamente la función forceExit().
Análisis del ataque
El siguiente análisis se basa en la transacción 0x5f2ea6cb...46ed137f.
-
El atacante tomó prestado
1,247,859e18 HPAYmediante préstamo flash. En la función de callback del préstamo flash:a. El atacante apostó
1,197,944e18 HPAYa través de la funciónstake().b. El atacante invocó repetidamente la función
forceExit()para drenar los tokens HPAY del contrato.
- El atacante reembolsó el préstamo flash e intercambió
57,389,615e18 HPAYpor26e18 WBNB(es decir, obtuvo una ganancia de26e18 WBNB).
Conclusión
La causa raíz de este incidente fue que la función forceExit() no actualizó el _balances[msg.sender] del usuario, lo que permitió al atacante drenar los tokens HPAY en el contrato de staking. Para prevenir este tipo de problemas, el proyecto debe realizar pruebas orientadas al estado adecuadas para garantizar que los invariantes de estado se mantengan correctamente en cada función.
5. Incidente Ploutos
Breve resumen
El 26 de febrero de 2026, un pool del protocolo Ploutos en Ethereum sufrió pérdidas de aproximadamente $390,000 debido a una configuración incorrecta del oráculo. Específicamente, el oráculo fue configurado incorrectamente para usar un feed de precios BTC/USD de Chainlink para USDC. Como resultado, el atacante explotó esta configuración incorrecta para tomar prestado 187 ETH colateralizando solo 8 USDC.
Análisis de la vulnerabilidad
Ploutos es un fork de Aave v3.0.2 desplegado en múltiples redes. El incidente fue causado por una configuración incorrecta del oráculo en el pool de préstamos (0xD060...F945D2).
En el bloque 24538896, el oráculo de precios para USDC fue configurado incorrectamente para referenciar un feed de Chainlink BTC/USD en lugar de un feed USDC/USD. En el bloque siguiente (24538897), el atacante detectó la configuración incorrecta y ejecutó el exploit. Como resultado, el atacante tomó prestado aproximadamente 187.3 ETH como ganancia colateralizando aproximadamente 8.88 USDC.
Análisis del ataque
-
El atacante monitoreó las operaciones de configuración del oráculo del protocolo Ploutos, que incorrectamente estableció la fuente del oráculo de
USDCal Feed de Precios BTC/USDC de Chainlink en la Tx 0xcfedf6...bd193ab6. -
El atacante envió instantáneamente una transacción (0xa17dc37e...705f8474), que le permitió tomar prestado ~187.3
ETHcolateralizando solo ~8.8USDCdebido a la configuración incorrecta del oráculo. -
El atacante pagó ~5.6
ETHen sobornos al constructor y obtuvo una ganancia neta de ~181.7ETH.
Conclusión
La causa raíz del incidente fue una configuración incorrecta del oráculo, resultando en pérdidas de aproximadamente $390,000. Esto sirve como recordatorio de que las operaciones sensibles como la configuración del oráculo deben estar protegidas por billeteras multifirma o timelock para evitar posibles pérdidas.
Referencias
[1] https://x.com/Phalcon_xyz/status/2026943448734114011
6. Incidente FOOMCASH
Breve resumen
El 26 de febrero de 2026, el protocolo FOOMCASH fue explotado debido a una verificación de prueba Groth16 vulnerable [1], resultando en pérdidas totales superiores a $2.26M.
Antecedentes
El protocolo FOOMCASH es un protocolo de lotería en Base y Ethereum que utiliza pruebas Groth16 para las verificaciones de retiro. En el contrato FoomLottery, la función collect() verifica la prueba proporcionada (es decir, _pA, _pB y _pC) invocando la función WithdrawG16Verifier.verifyProof(). Específicamente, la verificación se realiza en base a la configuración de confianza (es decir, gamma y delta) en el contrato WithdrawG16Verifier. Una vez que la prueba es verificada como válida, la función collect() procede a transferir activos (es decir, tokens FOOM) basándose en los datos de entrada del usuario (p. ej., _recipient y _rewardbits).
Análisis de la vulnerabilidad
La causa raíz del incidente fue una configuración Groth16 vulnerable. Específicamente, en el contrato WithdrawG16Verifier, las variables gamma () y delta () compartían el mismo valor (es decir, ), lo que permitía al atacante falsificar pruebas válidas con entradas arbitrarias. Como resultado, el atacante eludió la verificación de la prueba Groth16 en el contrato WithdrawG16Verifier y drenó todos los activos en el contrato FoomLottery con entradas maliciosas.
Análisis del ataque
El análisis del ataque se basa en la transacción 0xce204482...4e275e48.
El atacante creó un contrato malicioso para construir una prueba válida y entradas maliciosas. En la lógica fallback del contrato malicioso:
-
Construyó una prueba válida.
-
Invocó la función
collect()del contratoFoomLotterycon una prueba válida y entradas maliciosas (p. ej.,_recipienty_rewardbits).
a. En la invocación de la función collect(), la verificación de la prueba (es decir, WithdrawG16Verifier.verifyProof()) fue eludida y los activos (es decir, tokens FOOM) fueron transferidos al atacante.
- Repitió los pasos 1-2 durante 30 veces y drenó un total de
19,695,576,757,802e18tokensFOOM.
Conclusión
La causa raíz del incidente fue una configuración de verificación Groth16 vulnerable, resultando en pérdidas de aproximadamente $2.26M. Esto subraya que las configuraciones criptográficas complejas deben ser revisadas y auditadas exhaustivamente antes de su despliegue.
Referencias
[1] https://x.com/Phalcon_xyz/status/2026941738141778394
7. Incidente desconocido
Breve resumen
El 27 de febrero de 2026, un contrato desconocido en BNB Smart Chain fue explotado [1], resultando en pérdidas de aproximadamente $180K. La causa raíz de este incidente fue una validación de entrada incorrecta. Específicamente, la función _verifySignatures() del contrato víctima no realizó una comprobación de lista vacía, lo que permitió al atacante eludir la verificación de firmas sin proporcionar firmas ni firmantes. Como resultado, el atacante aprovechó esta vulnerabilidad para drenar todos los tokens USDT en el contrato víctima.
Análisis de la vulnerabilidad
La causa raíz de este incidente es una validación incorrecta en el flujo de verificación de firmas. Específicamente, la función _verifySignatures() solo verifica que allSigners.length == signatures.length y no requiere que ninguno de los dos arrays sea no vacío. Como resultado, cuando ambos arrays están vacíos, el atacante puede eludir la verificación de firmas y retirar activos.
Análisis del ataque
El siguiente análisis se basa en esta transacción 0x91f45260...41cfd784.
- El atacante invocó la función
0x2d0cb456()de sus contratos maliciosos. En la invocación,
a. El contrato malicioso invocó la función poolWithdraw() con entradas vacías allSigners y signatures, eludiendo la lógica de verificación de firmas prevista.
b. Tras eludir la lógica de verificación de firmas, el contrato víctima transfirió USDT al atacante.
Conclusión
La causa raíz de este incidente fue una validación de entrada incorrecta, lo que ocasionó pérdidas de aproximadamente $180K. El incidente subraya la importancia de las verificaciones básicas de límites, como las comprobaciones de no vacío para las entradas.
Referencias
[1] https://x.com/Phalcon_xyz/status/2027328894710505581
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento en criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluidos 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 de todo el ciclo de vida de los protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, reportado varios ataques de día cero en aplicaciones DeFi, bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
