El atacante aprovechó un fallo de diseño en la función swap() que permitía llamadas arbitrarias al ejecutor, lo que resultó en el robo a usuarios que habían otorgado aprobaciones ilimitadas.

Las supuestas claves de firma del validador filtradas y un préstamo flash le permitieron al atacante obtener un poder de voto exclusivo. Teniendo el control sobre los validadores, el atacante usó los fondos del puente en el mismo bloque para comprar BONE, delegarlo para poder de validador, firmar puntos de control fraudulentos y luego pagar el «préstamo» con los activos robados.

El atacante utilizó una clave privada comprometida de una cuenta de administrador de proxy para actualizar un contrato inteligente a una versión maliciosa. Luego, el atacante utilizó la versión maliciosa del contrato inteligente para vaciar el saldo del propio contrato, así como las carteras de los usuarios que habían aprobado dicho contrato inteligente.

El acceso no autorizado a la API de Kiln, un socio de staking de SwissBorg, resultó en el robo de $41.5 millones del programa de staking SOL Earn. Los atacantes manipularon las autoridades de las cuentas de staking sin necesidad de confirmaciones de multifirma. Esto les permitió transferir la autoridad de manera silenciosa mientras conservaban el rol de "Withdrawer", lo que les ayudó a evadir las herramientas de monitoreo estándar que se centran en los eventos de retiro. La brecha fue una explotación de la API fuera de la cadena que les dio a los atacantes control sobre los activos en la cadena.

Un desarrollador de Nemo introdujo una nueva función no auditada en el código después de la auditoría de seguridad inicial, pero antes de que se completara el informe final revisado. En consecuencia, se desplegó en la red principal (mainnet) una versión del contrato que contenía este código no auditado. La causa raíz de la gobernanza fue la dependencia del protocolo en una dirección de firma única para las actualizaciones, lo que no impidió el despliegue de código que no había pasado por una revisión de seguridad exhaustiva. Además, el desarrollador desplegó una versión del código diferente a la confirmada por la empresa de auditoría. Un atacante explotó estas funciones no auditadas para manipular el estado interno y drenar con éxito una cantidad sustancial de activos del fondo de liquidez.

Los atacantes utilizaron un cliente de Zoom malicioso para obtener privilegios en la máquina de la víctima. Explotaron este acceso para engañar a la víctima y hacer que enviara una transacción que aprobaba al atacante como un delegado de Venus válido de su cuenta, lo que le permitió al atacante pedir y canjear préstamos en nombre de la víctima.

Los atacantes obtuvieron acceso a una billetera multifirma con 32 millones de tokens AIO. Los fondos se movieron y se cambiaron por $2 millones.

El atacante explotó una vulnerabilidad en el contrato conector, que convierte automáticamente los tokens que generan rendimiento (como aUSDC) en USDC durante los retiros. Usando este fallo, el hacker ejecutó un retiro en nombre de otro usuario y desvió 427.000 USDC de Aave.

El atacante aprovechó la falta de una validación adecuada para acuñar tokens FAVOR no asegurados. Utilizó un contrato inteligente falso como proveedor de liquidez (LP) y luego ejecutó un intercambio masivo para obtener una bonificación significativa que podía convertirse en dinero real. El auditor, zokyo, había informado previamente sobre vulnerabilidades directamente relacionadas con este hack. Sin embargo, debido a un análisis en profundidad insuficiente, la gravedad de estos hallazgos se redujo a un nivel bajo.

La casa de cambio de criptomonedas turca BTCTurk fue explotada por 48 millones de dólares. El ataque implicó la filtración de claves privadas, lo que permitió a los atacantes drenar fondos de las carteras calientes en siete blockchains diferentes. La plataforma suspendió los servicios de criptomonedas.

Odin.fun, una plataforma de lanzamiento y comercio de memecoins basada en Bitcoin, sufrió un exploit. El ataque explotó una falla en la herramienta de creación de mercado automatizada de la plataforma, introducida en la última actualización. Los atacantes llevaron a cabo un esquema de manipulación de liquidez agregando tokens como SATOSHI para hacer subir los precios y luego retirando su liquidez para cobrar en Bitcoin.

Un atacante utilizó el rol BRIDGE para emitir tokens sin la garantía adecuada. Estos tokens se usaron luego como garantía para préstamos en otros tokens. Los fondos prestados (respaldados por los tokens sin garantía) fueron retirados y lavados en la red de Ethereum.

El control de acceso en la función updateMerkleRoot() se configuró incorrectamente. En lugar de verificar que la dirección que realiza la llamada ES el propietario, el código verificaba que NO ES el propietario. Este error de codificación del contrato inteligente permitió a un atacante formar una raíz de Merkle falsa y actualizar el contrato inteligente con ella. La raíz fabricada permitió al atacante retirar tokens del contrato inteligente.

Un atacante comprometió el dispositivo de un desarrollador mediante un ataque de phishing. Se obtuvo acceso al entorno de desarrollo. El atacante inició el retiro de fondos de 9 cuentas de usuario.

El incidente involucró el acceso no autorizado a una billetera operativa utilizada para la provisión de liquidez en un intercambio asociado.

Un ataque a la cadena de suministro que comprometió la red de producción, permitiendo a los atacantes modificar la lógica operativa de los servidores de control de cuentas y riesgos.

El protocolo tenía un sistema de disyuntor que se activó cuando se implementó el contrato malicioso. Sin embargo, un mecanismo incorporado diseñado para evitar que el protocolo se pausara indefinidamente fue utilizado por el atacante contra el protocolo. Cuando el equipo ejecutó simulaciones con el contrato inteligente malicioso y no encontró posibles rutas de explotación, reanudaron el protocolo. Las acciones posteriores del atacante no fueron detenidas debido al limitador previamente descrito para volver a pausar el protocolo. El atacante utilizó préstamos flash y datos de llamada maliciosos (calldata) para drenar las cuentas de las víctimas. La causa raíz del hackeo fue la falta de validación de los datos de llamada.

Se descubrió una puerta trasera crítica en miles de contratos que utilizan ERC1967Proxy. Un hacker pudo adelantarse a la inicialización e instalar un proxy malicioso intermedio y permanecer sin ser detectado debido a un error en los exploradores de bloques. El hacker acuñó 110.000 tokens K y comenzó el ataque para drenar tanto la bóveda de Morpho como el pool de Uniswap v4.

El exploit se originó a partir del contrato inteligente malicioso creado por el atacante, que se utilizó para crear y secuestrar la ejecución durante el cumplimiento de la orden. La causa raíz incluye la suposición implícita en executeDecreaseOrder() de que el parámetro _account es una Cuenta de Propiedad Externa (EOA), cuando en realidad puede ser un contrato inteligente malicioso. Esta vulnerabilidad llevó a un ataque sofisticado de múltiples pasos donde el atacante pudo inflar artificialmente el AUM del protocolo y canjear GLP por más activos de los merecidos.

Un atacante logró explotar la función de reequilibrio del contrato Texture Vaults para desencadenar una transferencia. El atacante proporcionó su propia cuenta de token, que la Bóveda llenó erróneamente con tokens LP durante el reequilibrio. Luego, el atacante canjeó estos tokens LP por liquidez real.

Un usuario utilizó un pool de baja liquidez como oráculo al configurar un pod. El atacante pudo manipular este pool utilizando un préstamo flash, y luego se tomó un préstamo con garantía insuficiente.

El atacante se dirigió al contrato ResupplyPair, que utiliza la tasa manipulada, solo unas horas después de su despliegue. La causa principal fue un error de manipulación del tipo de cambio provocado por un ataque clásico de bóveda ERC4626 de "primera donación", lo que resultó en un escenario de división por un valor grande que colapsó el tipo de cambio a cero. Esta tasa manipulada se utilizó para calcular el LTV del prestatario en la verificación _isSolvent(). Dado que ltv = 0 cuando exchangeRate = 0, el atacante eludió la verificación de solvencia y tomó prestados 10 millones de reUSD usando solo 1 wei de garantía.

El exploit se relacionaba con un contrato inteligente para una función de apalancamiento no lanzada, desplegada con fines de prueba. Apuntó a un contrato periférico usando fillQuote para llamar a silo.borrow(), manipulando parámetros para atacar una billetera de prueba del equipo central de Silo.

El puente Hacken fue explotado. Una clave privada asociada a una cuenta con derechos de acuñación fue expuesta, permitiendo a los atacantes acuñar enormes cantidades de tokens HAI y luego venderlos rápidamente en intercambios descentralizados. La clave privada estaba asociada a roles de acuñación en las redes Ethereum y BNB Chain. Los atacantes lograron acuñar alrededor de 900 millones de tokens HAI.

El atacante explotó una vulnerabilidad crítica de desbordamiento negativo de enteros (integer underflow) en la función BankrollNetworkStack.sell() para manipular la contabilidad de dividendos y drenar fondos de usuarios que previamente habían interactuado o aprobado el contrato.

Nobitex, la mayor plataforma de intercambio de criptomonedas de Irán, fue el objetivo de un ciberataque significativo reivindicado por el grupo de hackers pro-israelí Gonjeshke Darande, también conocido como Predatory Sparrow. El grupo alegó que Nobitex apoyaba las actividades militares de Irán y ayudaba a los usuarios a eludir las sanciones internacionales, enmarcando el acto como un mensaje simbólico relacionado con la escalada de tensiones entre Israel e Irán. El hackeo implicó el robo de criptomonedas de las billeteras calientes de Nobitex a través de múltiples blockchains compatibles con Ethereum Virtual Machine (EVM) y Tron. El grupo de hackers parece haber quemado los criptoactivos, destruyéndolos efectivamente en lugar de tomarlos para sus propios beneficios.

La vulnerabilidad se originó por la falta de anulación o restricción de la función base mint() expuesta públicamente, heredada del estándar ERC4626Upgradeable de OpenZeppelin, lo que permitió a los atacantes acuñar 9701 mpETH sin proporcionar ningún ETH.

El exploit se originó a partir de una vulnerabilidad en la lógica de verificación de la función de auto-listado. El atacante explotó una falla crítica en la lógica de verificación de la función create2 haciendo referencia a una transacción fallida, lo que permitió que un token malicioso eludiera los controles y transfiriera fondos de los fondos de liquidez.

El atacante llevó a cabo un ataque a la cadena de suministro para exfiltrar claves privadas. Las claves filtradas se utilizaron luego para desbloquear fondos de los contratos inteligentes del puente. El ataque a la cadena de suministro se dirigió al código del validador; el código malicioso se inyectó en la imagen de Docker en el momento de la compilación.

Se explotó un contrato de migración de Mendi-to-Malda. El contrato permitía que la dirección del Contralor de Mendi se pasara dinámicamente, en lugar de estar codificada. El atacante utilizó una característica que fue diseñada únicamente para permitir a los usuarios del protocolo Mendi migrar directamente a Malda. El atacante implementó un contrato de Contralor Mendi falso, lo que le permitió crear una posición fraudulenta en Malda y retirar fondos contra ella.

El problema principal detrás del exploit se debe a dos fallas críticas en el protocolo Cork. Primero, el contrato de configuración del protocolo (CorkConfig) permitía a los usuarios crear mercados con activos de redención (RA) arbitrarios, lo que permitió al atacante designar DS como el RA. Segundo, la función beforeSwap del contrato CorkHook carecía de un control de acceso y una validación de entrada adecuados, lo que permitía a cualquiera invocarla con datos de hook personalizados para operaciones CorkCall. Al aprovechar estas debilidades, el atacante creó un mercado malicioso utilizando DS como RA y usó tokens DS válidos de un mercado legítimo para depositarlos en este mercado falso. A cambio, recibieron tanto tokens DS como CT. Debido a la ausencia de restricciones sobre los tipos de RA y la validación insuficiente del llamador y los datos de entrada, el atacante pudo manipular la liquidez y realizar redenciones no autorizadas, agotando el mercado original. Esta manipulación les permitió adquirir una gran cantidad de derivados, que finalmente canjearon por 3,761 wstETH. La causa fundamental del exploit radica en la incapacidad del protocolo para validar estrictamente los datos proporcionados por el usuario y para aplicar restricciones adecuadas en la creación de mercados.

El atacante explotó una vulnerabilidad situacional en la ruta de depósito de la bóveda usUSDS++, una bóveda beta construida sobre el Protocolo Sky. La vulnerabilidad se centró en el proceso de "desenvolvimiento" (unwrap), donde USD0++ se convierte a USD0 durante los depósitos. Al manipular la ruta de depósito de la bóveda, específicamente la conversión limitada y con tope de USD0++ a USD0, el atacante ejecutó una estrategia de arbitraje y obtuvo una ganancia de aproximadamente $42,800. La bóveda ha sido sometida a 4 auditorías de seguridad en los últimos meses. El exploit no se debió a una lógica defectuosa. En cambio, aprovechó un caso límite de comportamiento en el sistema.

La falta de validación de las fuentes de precios de Chainlink Oracle permitió al atacante utilizar una firma de precio antigua, pero aún criptográficamente válida, para abrir una posición. El atacante utilizó un precio de ETH significativamente desactualizado de alrededor de $1,816, mientras que el precio real del mercado era cercano a $2,520. La diferencia en los precios de los activos se extrajo como ganancia.

Un error en el método de verificación de desbordamiento de enteros permitió a un atacante acuñar SUI no garantizados.

Un contrato inteligente con errores y obsoleto todavía se utilizaba como oráculo para el precio del token antes del ataque. El atacante utilizó la donación para explotar la vulnerabilidad en el código e infló artificialmente el precio de dGLP. Luego, el atacante usó el dGLP sobrevalorado como garantía para pedir prestado.

La secuencia de ataque se basó en la obtención de amplios privilegios administrativos. El monedero Zunami Protocol Deployer Wallet otorgó una función de administrador a la dirección de un atacante. Posteriormente, el atacante ejecutó el exploit llamando directamente a la función withdrawStuckToken() en la estrategia de Zunami, una función diseñada para retiros de emergencia. Esta única llamada permitió al atacante transferir 296.456 tokens LP, que representan la garantía para zunUSD y zunETH, directamente a su dirección.

El contrato inteligente no auditado contenía un simple error lógico que permitió al atacante drenar toda la liquidez. La causa raíz fue el exceso del multiplicador 1e18 en la función de evaluación de depósitos.

El incidente se atribuyó a un desarrollador contratado sin saberlo por el equipo, quien resultó ser un trabajador de TI encubierto de la RPDC. Este individuo/equipo accedió ilegalmente a las claves administrativas del proyecto y ejecutó una serie de transacciones no autorizadas. El atacante había desplegado una versión modificada de los contratos AToken y VariableDebtToken. En esta versión, el modificador de control de acceso onlyPool se modificó para permitir que no solo el contrato Pool, sino también cualquier dirección con el rol de administrador de Pool, ejecutara funciones que originalmente estaban restringidas. El atacante utilizó la billetera de despliegue comprometida para iniciar el vaciado de todas las piscinas.

Durante una actualización interna del oráculo tETH, se introdujo una inconsistencia en la precisión decimal entre los componentes del oráculo. Esta inconsistencia causó salidas de precio incorrectas para tETH. Un liquidador anónimo ejecutó liquidaciones durante el período en que el precio incorrecto de tETH estuvo activo.

Loopscale fue el objetivo de un ataque que explotó la lógica de precios del protocolo para los tokens emitidos por RateX. Al falsificar los programas de mercado de RateX PT, el atacante pudo obtener una serie de préstamos subcolateralizados. La ruta de código explotada se implementó como parte de una nueva integración con RateX y aún no había sido sometida a una auditoría formal por parte de terceros.

Aprovechando un código de protocolo defectuoso, el atacante creó un pool de liquidez alejado del precio actual y generó comisiones sustanciales mediante swaps de lavado. Estas comisiones se utilizaron luego para inflar la valoración de la garantía, aprovechando las matemáticas defectuosas del contrato inteligente. Posteriormente, el atacante pidió préstamos contra esta garantía sobrevalorada. Sin embargo, una reinversión posterior redujo el valor de la garantía, lo que resultó en una deuda sub-colateralizada. Esta deuda se reestructuró sin liquidación, lo que permitió al atacante retener los fondos ilícitos.

La billetera de despliegue de Oxya Origin parece haber sido comprometida, lo que resultó en la transferencia de la propiedad del token $OXYZ a una dirección sospechosa (0x2a00d9941ab583072bcf01ec2e644679e4579272). El atacante acuñó 9 mil millones de $OXYZ, intercambió $45K y transfirió los fondos a través de Stargate.

Una vulnerabilidad en la función overPaper del contrato inteligente BTCMapp permitió a un atacante extraer 1.311 ETH, lo que equivale a 2.228.700 $.

El atacante manipuló el precio del token $NUMA, mientras abría simultáneamente grandes posiciones cortas y largas, retirando el colateral depositado auto-liquidándose y saliendo a través de la bóveda.

El desarrollador malicioso había inyectado código en el contrato inteligente de staking, lo que les permitió ejecutar un drenaje de emergencia del fondo de liquidez, resultando en el robo de tokens por un valor aproximado de 490 ETH.

La vulnerabilidad se originó en el contrato TrustedForwarder, que heredaba de MinimalForwarderUpgradeable de OpenZeppelin pero no sobrescribía el método execute. Como resultado, el método permaneció sin permisos y expuesto a un uso indebido. El atacante se aprovechó de este descuido llamando directamente a la función execute original de MinimalForwarderUpgradeable. En una única transacción, el atacante abrió una posición a un precio artificialmente bajo y luego la cerró a un precio más alto, generando una ganancia ilegítima a través de este exploit.

El atacante utilizó una cuenta de administrador comprometida para acuñar los tokens restantes no reclamados de los distribuidores Merkle de tokens ZK utilizados para el airdrop de ZKsync del 17 de junio de 2024. El hacker tomó con éxito el control de 111.881.122 tokens ZK.

Las claves privadas fueron comprometidas. El atacante luego usó estas claves para actualizar una función en el contrato a una maliciosa, lo que le permitió retirar fondos.