O atacante visou o contrato ResupplyPair, que usa a taxa manipulada, apenas algumas horas após sua implantação. A causa raiz foi um bug de manipulação da taxa de câmbio desencadeado por meio de um ataque clássico de cofre ERC4626 de "primeira doação", resultando em um cenário de divisão por um valor grande que colapsou o exchangeRate para zero. Essa taxa manipulada foi usada para calcular o LTV do mutuário na verificação _isSolvent(). Como ltv = 0 quando exchangeRate = 0, o atacante contornou a verificação de solvência e pegou emprestado 10 milhões de reUSD usando apenas 1 wei de garantia.

O exploit se referia a um contrato inteligente para um recurso de alavancagem não lançado, implantado para fins de teste. Ele visou um contrato periférico usando fillQuote para chamar silo.borrow(), manipulando parâmetros para atingir uma carteira de teste da equipe central da Silo.

A ponte Hacken foi explorada. Uma chave privada associada a uma conta com direitos de cunhagem foi exposta, permitindo que os atacantes cunhassem enormes quantidades de tokens HAI e depois os vendessem rapidamente em exchanges descentralizadas. A chave privada estava associada a funções de cunhagem nas redes Ethereum e BNB Chain. Os atacantes conseguiram cunhar cerca de 900 milhões de tokens HAI.

A Nobitex, a maior exchange de criptomoedas do Irã, foi alvo de um significativo ataque cibernético reivindicado pelo grupo de hackers pró-Israel Gonjeshke Darande, também conhecido como Predatory Sparrow. O grupo alegou que a Nobitex apoiava as atividades militares do Irã e ajudava os usuários a contornar as sanções internacionais, enquadrando o ato como uma mensagem simbólica relacionada à escalada das tensões entre Israel e o Irã. O ataque envolveu o roubo de criptomoedas das carteiras quentes da Nobitex em várias blockchains compatíveis com Ethereum Virtual Machine (EVM) e Tron. O grupo de hackers parece ter queimado os ativos de criptomoeda, destruindo-os efetivamente em vez de pegá-los para seus próprios lucros.

O atacante explorou uma vulnerabilidade crítica de estouro negativo de inteiro (integer underflow) na função BankrollNetworkStack.sell() para manipular a contabilidade de dividendos e drenar fundos de usuários que haviam interagido anteriormente ou aprovado o contrato.

A vulnerabilidade resultou da falha em sobrescrever ou restringir a função base mint() exposta publicamente, herdada do padrão ERC4626Upgradeable da OpenZeppelin, o que permitiu que invasores cunhassem 9701 mpETH sem fornecer qualquer ETH.

O exploit originou-se de uma vulnerabilidade na lógica de verificação do recurso de auto-listagem. O atacante explorou uma falha crítica na lógica de verificação da função create2 referenciando uma transação falha, permitindo que um token malicioso contornasse as verificações e transferisse fundos de pools de liquidez.

O atacante realizou um ataque à cadeia de suprimentos para exfiltrar chaves privadas. As chaves vazadas foram então usadas para desbloquear fundos de contratos inteligentes de ponte. O ataque à cadeia de suprimentos visou o código do validador, o código malicioso foi injetado na imagem Docker no momento da construção.

Um contrato de migração Mendi-para-Malda foi explorado. O contrato permitia que o endereço do Controlador Mendi fosse passado dinamicamente, em vez de ser codificado. O atacante usou um recurso que foi projetado exclusivamente para permitir que os usuários do protocolo Mendi migrassem diretamente para Malda. O atacante implantou um contrato de Controlador Mendi falso, permitindo-lhe criar uma posição fraudulenta em Malda e sacar fundos contra ela.

A questão central por trás do exploit decorre de duas falhas críticas no protocolo Cork. Primeiro, o contrato de configuração do protocolo (CorkConfig) permitia que os usuários criassem mercados com ativos de resgate (RA) arbitrários, permitindo que o invasor designasse DS como o RA. Segundo, a função beforeSwap do contrato CorkHook não possuía controle de acesso e validação de entrada adequados, permitindo que qualquer pessoa a invocasse com dados de gancho personalizados para operações CorkCall. Alavancando essas fraquezas, o invasor criou um mercado malicioso usando DS como RA e usou tokens DS válidos de um mercado legítimo para depositar neste mercado falso. Em troca, eles receberam tokens DS e CT. Devido à ausência de restrições nos tipos de RA e à validação insuficiente do chamador e dos dados de entrada, o invasor foi capaz de manipular a liquidez e realizar resgates não autorizados, esgotando o mercado original. Essa manipulação permitiu que eles adquirissem uma grande quantidade de derivativos, que eles finalmente resgataram por 3,761 wstETH. A causa fundamental do exploit reside na falha do protocolo em validar estritamente os dados fornecidos pelo usuário e em impor restrições adequadas à criação de mercado.

O atacante explorou uma vulnerabilidade situacional no caminho de depósito do cofre usUSDS++, um cofre beta construído sobre o Protocolo Sky. A vulnerabilidade centrava-se no processo de "desenvolvimento" (unwrap), onde USD0++ é convertido para USD0 durante os depósitos. Ao manipular a rota de depósito do cofre, especificamente a conversão limitada e com limite de USD0++ para USD0, o atacante executou uma estratégia de arbitragem e obteve um lucro de aproximadamente US$ 42.800. O cofre passou por 4 auditorias de segurança nos últimos meses. A exploração não se deveu a uma lógica defeituosa. Em vez disso, aproveitou um caso de borda comportamental no sistema.

A falta de validação dos feeds de preço do Chainlink Oracle permitiu que o invasor usasse uma assinatura de preço antiga, mas ainda criptograficamente válida, para abrir uma posição. O invasor usou um preço ETH significativamente desatualizado de cerca de $1.816, enquanto o preço real de mercado estava mais próximo de $2.520. A diferença nos preços dos ativos foi extraída como lucro.

Um bug no método de verificação de estouro de inteiro permitiu que um invasor cunhasse SUI não garantidos.

Um contrato inteligente com bugs e depreciado ainda era usado como oráculo para o preço do token antes do ataque. O invasor usou a doação para explorar a vulnerabilidade no código e inflacionou artificialmente o preço do dGLP. O invasor então usou o dGLP supervalorizado como garantia para empréstimos.

A sequência de ataque dependeu de amplos privilégios administrativos obtidos. Uma função de administrador foi concedida ao endereço de um atacante pela Carteira de Implantação do Protocolo Zunami. Mais tarde, o atacante executou o exploit chamando diretamente a função withdrawStuckToken() na estratégia da Zunami, uma função projetada para saques de emergência. Essa única chamada permitiu que o atacante transferisse 296.456 tokens LP, representando a garantia para zunUSD e zunETH, diretamente para o seu endereço.

O contrato inteligente não auditado continha um erro lógico simples que permitiu ao atacante drenar toda a liquidez. A causa raiz foi o excesso do multiplicador 1e18 na função de avaliação de depósito.

O incidente foi atribuído a um desenvolvedor contratado sem o conhecimento da equipe, que se revelou um trabalhador de TI disfarçado da RPDC. Este indivíduo/equipe acessou ilegalmente as chaves administrativas do projeto e executou uma série de transações não autorizadas. O invasor havia implantado uma versão modificada dos contratos AToken e VariableDebtToken. Nesta versão, o modificador de controle de acesso onlyPool foi alterado para permitir que não apenas o contrato Pool, mas também qualquer endereço com a função de administrador do Pool, executasse funções que eram originalmente restritas. O invasor usou a carteira do implantador comprometida para iniciar o esvaziamento de todos os pools.

Explorando um código de protocolo falho, o atacante criou um pool de liquidez distante do preço atual e gerou taxas substanciais por meio de "wash swaps". Essas taxas foram então usadas para inflar a avaliação da garantia, aproveitando a matemática falha do contrato inteligente. O atacante subsequentemente tomou empréstimos contra essa garantia supervalorizada. No entanto, o reinvestimento posterior reduziu o valor da garantia, resultando em uma dívida subcolateralizada. Essa dívida foi então reestruturada sem liquidação, permitindo que o atacante retivesse os fundos ilícitos.

A Loopscale foi alvo de um ataque que explorou a lógica de precificação do protocolo para tokens emitidos pela RateX. Ao falsificar os programas de mercado RateX PT, o invasor conseguiu obter uma série de empréstimos subcolateralizados. O caminho do código explorado foi implantado como parte de uma nova integração com a RateX e ainda não havia passado por uma auditoria formal de terceiros.

Durante uma atualização interna do oráculo tETH, foi introduzida uma inconsistência na precisão decimal entre os componentes do oráculo. Essa inconsistência causou saídas de preço incorretas para tETH. Um liquidante anônimo executou liquidações durante o período em que o preço incorreto do tETH estava ativo.

A carteira do implantador Oxya Origin parece ter sido comprometida, resultando na transferência da propriedade do token $OXYZ para um endereço suspeito (0x2a00d9941ab583072bcf01ec2e644679e4579272). O invasor cunhou 9 bilhões de $OXYZ, trocou $45 mil e transferiu os fundos via Stargate.

Uma vulnerabilidade na função overPaper do contrato inteligente BTCMapp permitiu que um invasor extraísse 1.311 ETH, o que equivale a $2.228.700.

O atacante manipulou o preço do token $NUMA, enquanto simultaneamente abria grandes posições curtas e longas, removendo o colateral depositado ao liquidar-se e saindo pelo cofre.

O desenvolvedor malicioso havia injetado código no contrato inteligente de staking, permitindo-lhes executar um dreno de emergência do pool de liquidez, resultando no roubo de tokens no valor de cerca de 490 ETH.

A vulnerabilidade teve origem no contrato TrustedForwarder, que herdou o MinimalForwarderUpgradeable da OpenZeppelin, mas não sobrescreveu o método execute. Como resultado, o método permaneceu sem permissão e exposto a uso indevido. O atacante aproveitou essa falha chamando diretamente a função execute original do MinimalForwarderUpgradeable. Em uma única transação, o atacante abriu uma posição a um preço artificialmente baixo e depois a fechou a um preço mais alto, gerando um lucro ilegítimo por meio desse exploit.

O atacante usou uma conta de administrador comprometida para cunhar os tokens restantes não reclamados dos distribuidores Merkle de tokens ZK usados para o airdrop ZKsync de 17 de junho de 2024. O hacker conseguiu assumir o controle de 111.881.122 tokens ZK.

As chaves privadas foram comprometidas. O invasor então usou essas chaves para atualizar uma função no contrato para uma maliciosa, permitindo-lhe sacar fundos.