Durante la semana pasada (25 de enero - 1 de febrero de 2026), BlockSec detectó y analizó seis incidentes de ataque, con pérdidas totales estimadas de ~$18.05M. 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/01/25 | Incidente SwapNet | Validación de entrada inadecuada | ~$13.41M |
| 2026/01/25 | Incidente Aperture Finance | Validación de entrada inadecuada | ~$3.67M |
| 2026/01/27 | Incidente PGNLZ | Fallo en el diseño del token | ~$100K |
| 2026/01/28 | Incidente XPlayer | Fallo en el diseño del token | ~$717K |
| 2026/01/28 | Incidente Holdstation | Compromiso de clave | ~$100K |
| 2026/01/30 | Incidente Revert Finance | Fallo en la lógica de negocio | ~$50K |
1. Incidente SwapNet
Resumen Breve
El 25 de enero de 2026, el protocolo SwapNet en Base, BSC y Arbitrum fue explotado, resultando en aproximadamente $13.41 millones en pérdidas. El incidente se originó por una validación insuficiente de las entradas suministradas por el usuario, lo que permitió a un atacante crear llamadas que invocaban transferFrom() con parámetros controlados por el atacante. Al abusar de las aprobaciones de tokens existentes, el atacante ejecutó transferencias de la forma token.transferFrom(víctima, atacante, cantidad), lo que le permitió drenar los activos aprobados de las víctimas.
Antecedentes
El protocolo SwapNet es un agregador DEX diseñado para encontrar rutas de intercambio óptimas agregando liquidez de múltiples fuentes en cadena, incluyendo AMMs y creadores de mercado privados. El protocolo también permite a los usuarios especificar routers o pools personalizados al ejecutar intercambios, ofreciendo flexibilidad adicional.
Análisis de Vulnerabilidad
Este incidente se origina por una validación insuficiente de las entradas suministradas por el usuario, lo que permite a un atacante desencadenar llamadas transferFrom() con parámetros arbitrarios. Como resultado, los activos que habían sido previamente aprobados a los contratos víctima (p. ej., 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) pudieron ser transferidos al atacante.
Basándose en el bytecode descompilado, la función 0x87395540() parece carecer de validación adecuada en las entradas críticas. Al reemplazar la dirección esperada del router o pool con una dirección de token (p. ej., USDC), el contrato trata incorrectamente el token como un objetivo de ejecución válido. Esto lleva a que se ejecute una llamada de bajo nivel con calldata controlado por el atacante.
En consecuencia, el contrato víctima realiza llamadas de la forma: approvedAsset.transferFrom(víctima, atacante, cantidad), permitiendo al atacante sifón todos los activos aprobados.
Análisis del Ataque
Se observaron múltiples ataques contra SwapNet. Aquí usamos la transacción de Base 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 como ejemplo. El atacante simplemente invocó la función 0x87395540() del contrato víctima con entradas maliciosas. Esta invocación consta de dos pasos principales.
- Una variable interna clave (p. ej.,
v51) fue establecida enUSDC, eludiendo la lógica de enrutamiento prevista.
- Se ejecutó una llamada de bajo nivel usando calldata controlado por el atacante, resultando en que
USDC.transferFrom()fue invocado y todo elUSDCaprobado fue drenado.
Conclusión
El incidente es causado por una validación insuficiente de las entradas suministradas por el usuario, y agregar verificaciones adecuadas de los parámetros de entrada a la función ayudaría a mitigar este problema.
2. Incidente Aperture Finance
Resumen Breve
El 25 de enero de 2026, el protocolo Aperture en Ethereum, Base y Arbitrum fue explotado, resultando en aproximadamente $3.67 millones en pérdidas. La causa raíz fue una validación insuficiente de las entradas suministradas por el usuario, lo que permitió a un atacante desencadenar llamadas transferFrom() con parámetros arbitrarios a través de la función interna 0x1d33(). Como resultado, el atacante pudo realizar llamadas como approvedToken.transferFrom(víctima, atacante, cantidad), permitiéndole sifón todos los activos aprobados.
Antecedentes
Aperture Finance es un protocolo DeFi que gestiona posiciones de liquidez concentrada, como LPs de Uniswap V3, en nombre de los usuarios. Sus contratos de código cerrado (p. ej., 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) permiten a los usuarios acuñar y gestionar posiciones de Uniswap V3 usando tokens nativos.
Flujo de Trabajo Previsto para Acuñar Posiciones de Uniswap V3
Al acuñar posiciones de Uniswap V3 a través de la función 0x67b34120(), el contrato sigue un flujo de trabajo previsto de tres pasos:
-
Envolver tokens nativos
-
Intercambiar tokens envueltos a través de la función interna
0x1d33() -
Acuñar posiciones de UniswapV3
El problema surge en el Paso 2: La función interna 0x1d33() realiza un intercambio personalizado a través de una llamada de bajo nivel, donde los parámetros críticos (p. ej., el objetivo de la llamada y el calldata) parecen estar controlados por el usuario y ser insuficientemente validados, habilitando llamadas externas no deseadas. Más detalles se proporcionan en las siguientes secciones.
Análisis de Vulnerabilidad
El incidente es causado por una validación de entrada insuficiente en las llamadas de bajo nivel. Cuando se invoca la función 0x67b34120(), la función interna 0x1d33() ejecuta una llamada de bajo nivel usando calldata suministrado por el usuario, sin aplicar restricciones estrictas sobre el objetivo de la llamada o el selector de función.
Como se muestra en la figura a continuación, el calldata utilizado para desencadenar la llamada de bajo nivel se basa puramente en las entradas del atacante.
Esto permite a los atacantes construir calldata malicioso que resulta en: approvedToken.transferFrom(víctima, atacante, cantidad) ejecutado en el contexto del contrato víctima. Como resultado, no solo los tokens ERC20 sino también los NFTs de posición de Uniswap V3 aprobados pueden ser extraídos.
Análisis del Ataque
Se observaron múltiples ataques contra Aperture Finance. En esta sección, usamos la transacción de Ethereum 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a como ejemplo representativo.
-
El atacante creó un contrato de ataque
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
El contrato de ataque invocó la función
0x67b34120()con entradas maliciosas y 100 wei ETHs (es decir, msg.value == 100).
- a. Los ETHs nativos fueron envueltos en WETHs a través de la función
WETH.deposit().
- b. La función interna
0x1d33()fue invocada para realizar una llamada de bajo nivel. En este paso, se invoca una llamada deWBTC.transferFrom(víctima, atacante, cantidad)en el contexto del contrato víctima, permitiendo al atacante extraer los tokens aprobados. Vale la pena señalar que se pasó una verificación de saldo al final de la función0x1d33(). Específicamente, la función0x1d33()comparó los cambios de saldo con un valor de salida del intercambio (es decir,varg2.word2) especificado también por el atacante. Como resultado, se ejecutaron exitosamente sin recibir nada.
- c. Por último, la función
NonfungiblePositionManager.mint()fue invocada para acuñar una posición para el atacante usando 100 wei WETH.
Hallazgos Interesantes
Al comparar transacciones de acuñación normales y anormales, observamos que ambas transacciones aprobaron tokens al mismo gastador (p. ej., OKX DEX: TokenApprove) pero especificaron diferentes direcciones de router (es decir, DexRouter y WBTC). Esto sugiere que el contrato puede aplicar validación sobre el gastador de la aprobación mientras falla en validar el objetivo de ejecución real, dejando una brecha crítica explotable mediante llamadas arbitrarias.
Transacción normal: enlace tx1
Transacción anormal: enlace tx2
Conclusión
El incidente es causado por una validación insuficiente de las entradas suministradas por el usuario. Agregar validaciones de entrada adecuadas ayudaría a mitigar este problema.
3. Incidente PGNLZ
Resumen Breve
El 27 de enero de 2026, el pool USDT–PGNLZ de PancakeSwap V2 en BNB Smart Chain fue explotado, causando aproximadamente $100K en pérdidas. La causa raíz fue un mecanismo de quema defectuoso en el token PGNLZ que permitió al atacante quemar PGNLZ directamente del saldo del pool. Esto redujo artificialmente las reservas de PGNLZ del pool, creando un desequilibrio agudo de reservas y distorsionando el precio en cadena. El atacante luego aprovechó el precio manipulado para ejecutar intercambios que drenaron USDT del pool.
Antecedentes
El token PGNLZ introduce un mecanismo de quema dirigido a un pool de PancakeSwap V2. El mecanismo de quema puede activarse bajo ciertas condiciones. Específicamente, para cada compra en el pool, el token verifica si el saldo de USDT del pool ha alcanzado un umbral predefinido. Una vez alcanzado el umbral, quema una cierta cantidad de PGNLZ del pool y establece tradingEnabled = true, permitiendo a los usuarios regulares interactuar con el pool a partir de entonces. Cuando el modo de negociación está habilitado y un usuario vende PGNLZ en el pool, el token primero quema una cantidad de PGNLZ en poder del pool basándose en la cantidad de venta de PGNLZ del usuario anterior.
Análisis de Vulnerabilidad
El problema central fue el mecanismo de quema defectuoso introducido por el token PGNLZ, que es vulnerable a un ataque de manipulación de precios. Específicamente, a un atacante se le permite eludir la limitación del modo de negociación para manipular las reservas del pool (es decir, comprando PGNLZ) estableciendo el destinatario como la dirección isExcludedFromFee (es decir, 0xdEaD). Luego, el atacante aprovecha el mecanismo de quema (es decir, a través de la función _executeBurnFromLP()) para quemar directamente PGNLZ del pool, manipulando aún más las reservas del pool. Como resultado, el atacante puede obtener ganancias realizando un intercambio inverso (es decir, vendiendo PGNLZ) en el pool manipulado.
Análisis del Ataque
El siguiente análisis se basa en la transacción: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121
-
El atacante tomó prestados
1,059e18 BTCBmediante un préstamo flash en Moolah y tomó prestados30,000,000e18 USDTsuministrando1,059e18 BTCBen Venus. -
El atacante intercambió
23,337,952e18 USDTpor978,266e18 PGNLZen el pool de PancakeSwap V2 cuando el modo de negociación estaba deshabilitado. El atacante hizo posible el intercambio estableciendo el destinatario en0xdEaD, lo que eludió las validaciones correspondientes. -
El atacante intercambió
17e18 PGNLZque poseía previamente porUSDTen el pool de PancakeSwap V2. Durante este intercambio, se activó la función_executeBurnFromLP(), quemando4,240e18 PGNLZdel pool (es decir, basándose en la cantidad de venta dePGNLZanterior). Este proceso de quema dejó la reserva del pool con solo0.00000001e18 PGNLZ, manipulando aún más la reserva dePGNLZdel pool. Con la reserva dePGNLZagotada, el atacante pudo drenar23,438,853e18 USDTdel pool con solo17e18 PGNLZ. -
El atacante reembolsó la posición en Venus y obtuvo una ganancia de
100,901e18 USDT.
Conclusión
La causa raíz de este incidente proviene del mecanismo de quema defectuoso de PGNLZ, que permitió a los atacantes drenar USDT del pool realizando un ataque de manipulación de precios. Como resultado, el incidente incurrió en pérdidas totales de aproximadamente $100K. Para mitigar tales 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 XPlayer
Resumen Breve
El 28 de enero de 2026, el pool XPL/USDT de PancakeSwap V2 en BNB Smart Chain fue explotado, resultando en aproximadamente $717K en pérdidas. El incidente fue causado por un mecanismo de quema defectuoso en el token XPL que permitió a un atacante quemar XPL directamente del saldo del pool. Al reducir artificialmente las reservas de XPL del pool, el atacante creó un grave desequilibrio de reservas y distorsionó el precio de intercambio, luego explotó el precio manipulado para drenar USDT del pool.
Antecedentes
El token XPL introduce un mecanismo de quema, que quema tokens XPL del pool correspondiente y luego llama a la función sync() para actualizar las reservas del pool. Específicamente, en el contrato NodeDistributePlus, la función DynamicBurnPool() puede ser llamada para realizar una tarea de quema diaria dentro de una ventana de ejecución. La cantidad de quema no debe exceder el límite diario de quema restante.
Análisis de Vulnerabilidad
La causa raíz de este incidente proviene del mecanismo de quema defectuoso del contrato XPL. En particular, la función DynamicBurnPool() en el contrato XPL permite a ciertas direcciones privilegiadas quemar XPL directamente del par de liquidez.
Una de estas direcciones privilegiadas es el contrato NodeDistributePlus (es decir, nodeShareAddress), que implementa un cronograma de quema diaria. Después de que una cuenta privilegiada establece el objetivo de quema diaria, cualquier llamante puede llamar a NodeDistributePlus.DynamicBurnPool() dentro de una ventana de 2 días hasta que se alcance el límite de quema diaria.
Como resultado, este diseño permite a cualquiera quemar XPL del pool correspondiente y forzar una actualización de reservas. Un atacante puede aprovechar este diseño para manipular las reservas del pool y ejecutar un intercambio inverso para extraer USDT del pool.
Análisis del Ataque
El siguiente análisis se basa en la transacción: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49
- El atacante tomó prestados aproximadamente
239,523,169e18 USDTmediante préstamos flash.
- El atacante intercambió
100e18 USDTpor69e18 XPL. Este paso sincronizó las reservas del pool con los saldos actuales.
- El atacante intercambió
217,118,801e18USDTpor aproximadamente691,022e18XPL. Este paso fue cuidadosamente dimensionado para configurar el estado del pool para la posterior manipulación de reservas.
- El atacante invocó la función
DynamicBurnPool()para quemar3,078e18 XPLdel pool. Este proceso de quema manipuló aún más la reserva deXPLdel pool a un valor extremadamente pequeño (p. ej., 1 wei).
- El atacante intercambió
69e18 XPLpor218,083,490e18 USDTcon las reservas manipuladas.
- El atacante reembolsó el préstamo flash y obtuvo una ganancia de
718,844e18 USDT.
Conclusión
Este incidente es causado por un mecanismo de quema defectuoso, que permite a cualquiera quemar XPL directamente del pool para manipular sus reservas. Como resultado, este diseño defectuoso permite a los atacantes realizar un ataque de manipulación de precios para drenar activos valiosos del pool. Para mitigar problemas similares, los proyectos deben evitar la quema arbitraria de activos del pool.
5. Incidente Holdstation
Resumen Breve
El 28 de enero de 2026, Holdstation informó un compromiso que involucró la toma de control de una billetera controlada por el proyecto, con pérdidas totales estimadas de ~$100K. El atacante drenó múltiples activos por valor de ~$66K, incluyendo WLD, USD1, BNB y BERA, en World Chain, BSC, Berachain y zkSync, luego consolidó los fondos en Ethereum en aproximadamente 22.41 ETH antes de transferirlos a Bitcoin en aproximadamente 0.755 BTC. El incidente fue rastreado hasta el compromiso del dispositivo de un miembro del equipo, supuestamente a través de un IDE malicioso o extensión de navegador, lo que permitió la toma de control de la billetera.
Análisis de Vulnerabilidad
La brecha se originó a partir de una extensión de codificación o de navegador maliciosa instalada por un desarrollador principal, lo que representa un error humano a nivel operativo. Específicamente, el desarrollador instaló un IDE/extensión de navegador malicioso y no confiable, lo que resultó en el compromiso de la cuenta y pérdidas financieras.
Análisis del Ataque
Las direcciones relacionadas y las transacciones de transferencia se enumeran a continuación:
Direcciones del Atacante
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c
Direcciones de la Víctima
- (World Chain)
0xa92e09e0a52b7EdEaD75d3125e21bDFB9752C69e - (World Chain)
0xD768da05e0E6771Ea81b441026CE9355421eF7c9 - (World Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (World Chain)
0x9BD647B2C8Fed689ADd2e7AA8b428d3eD12f75cb - (BSC)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (BSC)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0x628cEf732301aDF6d62bB2bcDFeBB291750C4D9a - (zkSync)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (zkSync)
0x8C826F795466E39acbfF1BB4eEeB759609377ba1 - (zkSync)
0x4Cf7baB01b8D3572b3dC08642ebbE2AD1aCF3B99 - (zkSync)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (zkSync)
0x2D2D047c50d7828Aedb6A151bA1717766606Bf33
Transacciones de Transferencia
-
World Chain → Ethereum
- Cantidad:
114,308 WLD → 15.317 ETH - Remitente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatario:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Cantidad:
-
BSC → Ethereum
- Cantidad:
10.09 BNB → 2.992 ETH - Remitente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatario:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Cantidad:
-
BSC → Ethereum
- Cantidad:
6,101.6 USD1 → 2.027 ETH - Remitente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatario:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Cantidad:
-
Berachain → Ethereum
- Cantidad:
7,185 BERA → 1.45 ETH - Remitente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatario:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - TXs:
- Cantidad:
-
Ethereum → Ethereum
- Cantidad:
22.41 ETH → 22.41 ETH - Remitente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatario:
0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 - TXs:
- Cantidad:
-
Ethereum → Bitcoin
- Cantidad:
22.41 ETH → 0.755 BTC - Remitente:
0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2 - Destinatario:
bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c - TXs:
- Cantidad:
Conclusión
La causa raíz de este incidente proviene de un compromiso de clave. Las claves de administrador, particularmente aquellas asociadas con roles clave (p. ej., propietario) en contratos principales, deben ser gestionadas cuidadosamente. Se recomienda usar billeteras multifirma para evitar puntos únicos de fallo y mejorar la robustez sistémica.
6. Incidente Revert Finance
Resumen Breve
El 30 de enero de 2026, Revert Finance en Base fue explotado, resultando en aproximadamente $50K en pérdidas. La causa raíz fue un fallo en la lógica de negocio en el contrato GaugeManager que permitió a un atacante retirar colateral sin reembolsar la deuda correspondiente. Al abusar de executeV3UtilsWithOptionalCompound(), el atacante eludió el flujo de reembolso de deuda previsto y extrajo fondos.
Antecedentes
Revert Finance es una plataforma de herramientas integral diseñada para proveedores de liquidez (LPs) de Creadores de Mercado Automatizados (AMM). Ofrece principalmente características de análisis, gestión, automatización y préstamo para ayudar a los LPs a mejorar la eficiencia del capital y el control de riesgos.
En el protocolo, los usuarios pueden depositar sus posiciones de Uniswap v3 como colateral para pedir prestados activos de los pools de préstamo de Revert Finance. Además, el protocolo permite a los usuarios apostar sus posiciones, que se usan como colateral, para ganar recompensas adicionales a través de la función stakePosition().
Análisis de Vulnerabilidad
La causa raíz del incidente fue la falta de una verificación de solvencia al desapostar posiciones que se usan como colateral. Específicamente, la función executeV3UtilsWithOptionalCompound() permite a los usuarios desapostar una posición indicando una instrucción correspondiente (es decir, whatToDo= 1). Sin embargo, esta función carece de una verificación de solvencia al desapostar posiciones colateralizadas. Como resultado, un atacante puede canjear una posición colateralizada sin reembolsar las deudas pendientes.
Análisis del Ataque
El siguiente análisis se basa en la transacción: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab
-
El atacante tomó prestados
10e8 cbBTCy10,000,000e6 USDCmediante un préstamo flash para acuñar una posición (es decir, NFT). -
El atacante pignoró el NFT como colateral y tomó prestados
49,000e6 USDC. -
El atacante apostó el NFT colateralizado a través de la función
stakePosition(). -
El atacante desapostó instantáneamente el NFT colateralizado usando la función
executeV3UtilsWithOptionalCompound(). Específicamente, la posición colateralizada fue quemada y los activos subyacentes correspondientes fueron recogidos por el atacante. Debido a la ausencia de verificaciones de solvencia en el proceso de desapostar, la posición colateralizada fue quemada sin liquidar sus deudas correspondientes.
- El atacante reembolsó el préstamo flash y obtuvo una ganancia de
49,000e6 USDC.
Conclusión
La causa raíz del incidente es la falta de una verificación de solvencia al desapostar posiciones colateralizadas. Este incidente subraya la importancia de las verificaciones de solvencia en protocolos similares a los de préstamo. Implementar medidas de solvencia robustas para cada uso de la posición es esencial para garantizar la estabilidad y confiabilidad.
Referencias
[1] SwapNet & Aperture https://blocksec.com/blog/17m-closed-source-smart-contract-exploit-arbitrary-call-swapnet-aperture
[2] PGNLZ: https://x.com/Phalcon_xyz/status/2016154398817505595
[3] XPlayer: X Player Official https://x.com/XPlayer_Media/status/2016700861578403910
[4] XPlayer: X Blocksec Phalcon https://x.com/Phalcon_xyz/status/2016521384609067103
[5] Holdstation: https://x.com/Phalcon_xyz/status/2016823122373296583
[6] Revert Finance: https://paragraph.com/@revertfinance/post%E2%80%91mortem-aerodrome-lend-vault-incident-on-base?referrer=0x8cadb20A4811f363Dadb863A190708bEd26245F8
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. 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 prestigiosas, 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
-
🔗 Aplicación de Seguridad Phalcon: Reservar una demostración
