2025 fue otro año intenso para la seguridad en cripto. Una serie de incidentes de alto impacto sacudieron el ecosistema y dejaron daños reales a su paso, afectando a usuarios, equipos y comunidades en todo el espacio. Aunque los resultados fueron a menudo dolorosos, cada evento refuerza también una verdad conocida: la seguridad debe tratarse como una prioridad de primer nivel.
Para ayudar a la comunidad a aprender de lo ocurrido, BlockSec seleccionó diez incidentes que más destacaron este año. Estos casos fueron elegidos no solo por la magnitud de las pérdidas, sino también por las técnicas distintas involucradas, los giros inesperados en su ejecución y las superficies de ataque nuevas o poco exploradas que revelaron.
En esta publicación, destacamos los diez principales incidentes de seguridad de 2025 y compartimos por qué cada uno merece atención. También publicaremos un seguimiento dedicado para cada caso, detallando la causa raíz y la ruta completa del ataque.
Incidente Cetus: El Mayor Hackeo DeFi de 2025
Resumen
El 22 de mayo de 2025, Cetus Protocol, el mayor DEX de liquidez concentrada en Sui, fue explotado por un estimado de ~$223M al drenarse la liquidez de múltiples pools. La causa raíz fue una función auxiliar de prevención de desbordamiento defectuosa (checked_shlw()) en la aritmética de punto fijo u256: un umbral incorrecto permitió que un desplazamiento a la izquierda << 64 no seguro procediera, truncando silenciosamente los bits más significativos. Al elegir cuidadosamente el tamaño de la liquidez y rangos de tick ajustados, el atacante hizo que Cetus calculara el depósito de token requerido como ~1 unidad mientras acreditaba una posición LP con una liquidez enorme, para luego retirar esa posición inflada y extraer las reservas reales.
Razón de Selección
Una única comparación incorrecta en una función auxiliar de punto fijo fue suficiente para drenar $223M. El atacante no manipuló oráculos ni explotó la gobernanza: el ataque completo se basó en casos límite puramente aritméticos (desplazamiento + truncamiento) para crear liquidez casi gratuita y retirar reservas reales de forma determinista. Para cualquier protocolo construido sobre aritmética de liquidez concentrada, este caso es una advertencia directa de que los errores silenciosos de límites en operaciones de punto fijo de bajo nivel pueden escalar hasta una catástrofe a nivel de protocolo.
Conozca la causa raíz y los pasos del ataque en detalle.
Bybit: El Mayor Hackeo de 2025
Resumen
El 21 de febrero de 2025, Bybit perdió aproximadamente $1.5 mil millones tras un atacante comprometer la máquina de un desarrollador de Safe{Wallet} mediante ingeniería social. Con ese acceso, el atacante inyectó JavaScript malicioso en el bucket AWS S3 de Safe{Wallet}. El código inyectado apuntó específicamente a las transacciones de Safe{Wallet} de Bybit, manipulando el contenido de las transacciones durante el proceso de firma. La transacción manipulada actualizó el contrato Safe{Wallet} de Bybit a una implementación maliciosa, permitiendo al atacante drenar todos los activos mantenidos por el contrato.
Razón de Selección
La mayor brecha de seguridad en la historia de las criptomonedas no comenzó con un error en un contrato inteligente. Comenzó con la máquina de un desarrollador comprometida y un archivo JavaScript manipulado en un bucket S3. La ruta del ataque transcurrió completamente a través de infraestructura Web2: ingeniería social, almacenamiento en la nube e inyección de código en el front-end. Para una industria enfocada en la seguridad on-chain, Bybit es un recordatorio directo de que la seguridad operacional e infraestructural es igualmente esencial. Un multisig es tan seguro como la interfaz de firma en la que confían sus propietarios.
Conozca la causa raíz y los pasos del ataque en detalle.
Balancer V2
Resumen
El 3 de noviembre de 2025, los Composable Stable Pools de Balancer V2 y varios proyectos derivados en múltiples cadenas fueron explotados en un ataque coordinado, resultando en pérdidas totales que superan los $125 millones. La causa raíz fue la pérdida de precisión en el cálculo del invariante, que distorsionó el precio del BPT (Balancer Pool Token). El atacante explotó esta distorsión en dos etapas: primero manipulando el precio del BPT mediante un intercambio por lotes diseñado, y luego extrayendo ganancias al retirar activos en una transacción separada.
Razón de Selección
A diferencia de los ataques típicos de manipulación de oráculos, este exploit se originó dentro del propio cálculo del invariante: una menor pérdida de precisión en aritmética de punto fijo fue suficiente para distorsionar el precio del BPT y permitir una extracción rentable en una sola transacción. El ataque se propagó a través de múltiples cadenas y afectó tanto a Balancer como a sus bifurcaciones, ilustrando cómo las bases de código compartidas amplían el riesgo sistémico en el DeFi componible. El debate comunitario sobre la causa raíz simplificó a menudo la mecánica. El análisis completo traza cómo la pérdida de precisión en el solucionador del invariante se traduce en brechas de precios explotables.
Conozca la causa raíz y los pasos del ataque en detalle.
GMX
Resumen
El 9 de julio de 2025, GMX V1 en Arbitrum fue explotado por aproximadamente $42 millones. El atacante desencadenó una vulnerabilidad de reentrada para manipular el precio del GLP a mitad de transacción, y luego utilizó el precio distorsionado para adquirir activos que superaban con creces el valor depositado. Mediante una explotación repetida, el atacante fue drenando gradualmente los activos subyacentes de los pools de liquidez de GMX V1.
Razón de Selección
La reentrada es una de las vulnerabilidades más antiguas conocidas en contratos inteligentes, y sin embargo derribó un protocolo probado en batalla con un modelo ACL establecido. El modificador nonReentrant en el contrato OrderBook evitó la reentrada dentro del mismo contrato, pero no hizo nada para detener las llamadas entre contratos al Vault durante el fallback. GMX V1 llevaba años en funcionamiento, un historial que puede crear una falsa sensación de seguridad. Este caso demuestra que la madurez de un protocolo no sustituye al análisis de reentrada a nivel de sistema, y que los guardas de un único contrato son insuficientes cuando múltiples contratos comparten estado mutable.
Conozca la causa raíz y los pasos del ataque en detalle.
Yearn Finance
Resumen
El 30 de noviembre de 2025, el yETH Weighted Stable Pool de Yearn Finance fue explotado por más de $9 millones. La causa raíz principal fue la aritmética no segura en el solucionador del invariante _calc_supply(), cuyas fallas de redondeo hacia abajo y desbordamiento negativo dieron cuenta de forma independiente de ~$8.1M (el 90% de las pérdidas). Una vulnerabilidad secundaria, una ruta de arranque no desactivada en add_liquidity(), permitió $0.9M adicionales después de que el exploit principal ya había drenado el pool.
El atacante ejecutó una estrategia de múltiples fases: primero, añadió y retiró liquidez repetidamente para crear un desequilibrio extremo en los balances virtuales del pool; a continuación, explotó las fallas aritméticas para colapsar el término producto y reducir el suministro total a cero; finalmente, reentró en la ruta de inicialización de arranque para acuñar ~2.35e56 yETH mediante desbordamiento negativo y los intercambió por activos reales en el pool yETH-WETH de Curve.
Razón de Selección
La pérdida financiera fue moderada para los estándares de 2025, pero la complejidad técnica del exploit es excepcional. El ataque encadena casos límite numéricos (colapso de la división, inversión de signo en el solucionador del invariante) con reentrada de máquina de estados (reactivación de la inicialización del pool tras el despliegue), requiriendo una manipulación precisa y multifásica del estado on-chain. Reconstruir completamente el exploit exige comprender tanto la aritmética de bajo nivel como las transiciones de estado más amplias. La combinación de sutileza, rigor y profundidad educativa de este caso lo convierte en uno de los incidentes analíticamente más enriquecedores del año.
Conozca la causa raíz y los pasos del ataque en detalle.
Cork Protocol
Resumen
El 28 de mayo de 2025, Cork Protocol en Ethereum fue explotado, resultando en aproximadamente $12 millones en pérdidas. La causa raíz fue una combinación de manipulación del precio HIYA en el tiempo de vencimiento y la ausencia de control de acceso en un callback de hook de Uniswap v4. Debido a que HIYA (Historical Implied Yield Average, una métrica de prima de riesgo utilizada para fijar el precio de nuevas emisiones de mercado) aumenta exponencialmente a medida que el tiempo hasta el vencimiento se aproxima a cero, los intercambios en etapas tardías inflaron HIYA y causaron que los mercados recién inicializados subvaloraran gravemente los Cover Tokens. Al mismo tiempo, CorkHook.beforeSwap carecía de autenticación de msg.sender, permitiendo llamadas arbitrarias con parámetros diseñados. Al explotar ambas fallas, el atacante extrajo grandes cantidades de CT y DS y los convirtió de vuelta en wstETH, drenando las reservas del protocolo.
Razón de Selección
Ni la curva de precios en el tiempo de vencimiento ni el callback de hook no autenticado eran individualmente catastróficos. Su interacción sí lo fue. La prima exponencial de HIYA cerca del vencimiento creó un amplificador económico, y la ausencia de verificación de msg.sender en CorkHook.beforeSwap le dio al atacante una forma de activarlo con parámetros arbitrarios. Este caso ilustra una clase de vulnerabilidades que las auditorías de un solo módulo probablemente pasarán por alto: desajustes de suposiciones entre módulos donde el diseño económico y el control de acceso interactúan para producir una ruta explotable.
Conozca la causa raíz y los pasos del ataque en detalle.
Trust Wallet
Resumen
El 25 de diciembre de 2025, Trust Wallet sufrió un ataque a la cadena de suministro que comprometió más de 2,000 carteras de usuarios, resultando en pérdidas de $8.5 millones. El atacante obtuvo la clave API de la Chrome Web Store de Trust Wallet y la utilizó para publicar una extensión con puerta trasera (v2.68) a través de canales oficiales. La extensión maliciosa exfiltró las frases semilla de los usuarios a un servidor controlado por el atacante. El atacante luego drenó los fondos de las carteras comprometidas.
Razón de Selección
El atacante nunca tocó un contrato inteligente. Al comprometer una única clave API, publicó una extensión maliciosa a través del canal de distribución oficial de Trust Wallet, eludiendo tanto la revisión manual como el proceso de lanzamiento estándar. Los usuarios no tenían motivo para desconfiar de la actualización. Este es el único ataque a la cadena de suministro de una cartera en el Top 10, y expone una categoría de riesgo que las auditorías on-chain no pueden cubrir: la seguridad del canal de distribución de software entre el desarrollador y el usuario final.
Conozca la causa raíz y los pasos del ataque en detalle.
Bunni
Resumen
El 2 de septiembre de 2025, Bunni V2 fue explotado por $8.4 millones en el pool USDC/USDT en Ethereum y el pool weETH/ETH en Unichain. El protocolo declaró posteriormente la quiebra el 23 de octubre de 2025. La causa raíz fue un error de redondeo en la actualización de los balances inactivos del pool durante la eliminación de liquidez, lo que provocó que el contrato subestimara su propia liquidez total.
El atacante ejecutó un ataque en tres etapas: primero, manipulando el precio del pool para agotar el saldo disponible de USDC y amplificar el error de redondeo; a continuación, ejecutando una serie de pequeños retiros que acumularon la subestimación de liquidez; finalmente, realizando intercambios direccionales para arbitrar la brecha entre la liquidez registrada por el protocolo y sus reservas reales.
Razón de Selección
Bunni V2 había sido sometido a múltiples auditorías de código, y sin embargo un error de redondeo menor en la contabilidad de balances inactivos pasó desapercibido. El error por sí solo era insignificante por transacción, pero el atacante lo amplificó mediante retiros pequeños y repetidos tras sesgar deliberadamente el estado del pool, convirtiendo una pérdida de precisión fraccionaria en un drenaje de $8.4M. El caso demuestra cómo los errores de redondeo que parecen seguros de forma aislada pueden volverse explotables cuando un atacante controla la secuencia y las condiciones bajo las cuales se acumulan.
Conozca la causa raíz y los pasos del ataque en detalle.
1inch
Resumen
El 5 de marzo de 2025, un resolver de terceros integrado con 1inch Fusion V1 fue explotado por más de $5M debido a una reconstrucción no segura de calldata en _settleOrder(). Un interactionLength controlado por el atacante corrompió el ensamblaje en memoria del sufijo dinámico utilizado para propagar la identidad del resolver y el contexto de ejecución, permitiendo la inyección de datos de liquidación falsificados. Dado que los contratos de resolver confiaban implícitamente en el calldata enviado por el contrato de Settlement basándose únicamente en msg.sender, el contexto falsificado superó todas las verificaciones de control de acceso y condujo a la extracción no autorizada de activos.
Razón de Selección
Este exploit difumina la frontera entre vulnerabilidades de contratos inteligentes y la explotación binaria tradicional. En lugar de abusar de suposiciones económicas o lógica de negocio de alto nivel, el ataque se basa en aritmética de punteros, campos de longitud no verificados y suposiciones sobre el diseño de memoria ABI, patrones más comúnmente vistos en exploits de software nativo como desbordamientos de búfer y desbordamientos negativos de enteros. Muestra cómo la manipulación de calldata y memoria de bajo nivel puede reintroducir primitivas de explotación clásicas en sistemas on-chain, especialmente cuando se combina con cadenas de confianza implícita entre contratos.
Conozca la causa raíz y los pasos del ataque en detalle.
Panoptic
Resumen
El 25 de agosto de 2025, con la asistencia de Cantina y Seal911, Panoptic llevó a cabo una operación de rescate whitehat asegurando aproximadamente $400K en fondos en riesgo. La causa raíz fue una falla en la construcción del s_positionsHash por parte del contrato: el uso de XOR para agregar resultados de hash Keccak256. Aunque una única función hash sigue siendo resistente a colisiones, la linealidad matemática de XOR hace que la huella digital general (la suma XOR de hashes) sea insegura, permitiendo que conjuntos de posiciones distintos produzcan hashes idénticos.
Razón de Selección
La mayoría de los incidentes en esta lista se remontan a errores aritméticos o a controles de acceso faltantes. La vulnerabilidad de Panoptic es diferente: es una falla de diseño criptográfico a nivel de estructura de datos. El protocolo se basaba en XOR para componer las huellas digitales de las posiciones, asumiendo que el resultado heredaría la resistencia a colisiones de los hashes Keccak256 subyacentes. No es así. La linealidad de XOR significa que un atacante puede construir conjuntos de posiciones distintos que produzcan valores s_positionsHash idénticos, eludiendo los invariantes contables. El exitoso rescate whitehat evitó las pérdidas, pero la falla subyacente es un útil recordatorio de que la composición de hashes requiere el mismo cuidado que la propia función hash.
Conozca la causa raíz y los pasos del ataque en detalle.
