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.

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.

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.

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.

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.

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.

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.

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.