A violação foi uma falha de infraestrutura. Os invasores obtiveram acesso às credenciais do GitHub de um prestador de serviços, infiltrando-se eventualmente no AWS Key Management Service da Resolv para confiscar a chave privada SERVICE_ROLE. Com essa chave, o invasor burlou os limites de cunhagem (minting) para emitir tokens contra colaterais mínimos, extraindo aproximadamente US$ 24,5 milhões em ETH e causando um depeg violento do USR. Esse evento desencadeou um contágio secundário em todo o ecossistema DeFi, resultando em dívidas incobráveis para protocolos como Morpho e Fluid.

Uma configuração técnica incorreta no CAPO da Aave desencadeou liquidações em contas saudáveis. O incidente foi causado por uma incompatibilidade de parâmetros entre o snapshotRatio e o snapshotTimestamp do protocolo, fazendo com que o Wrapped Staked Ether (wstETH) fosse subvalorizado em aproximadamente 2,85%. Bots automatizados processaram 10.938 wstETH em liquidações, gerando cerca de 512 ETH em lucro para os liquidadores. A Chaos Labs e a Aave DAO comprometeram-se com o reembolso total dos usuários afetados. Futuras medidas de prevenção focam na implementação de simulações de transações obrigatórias e verificações de sanidade on-chain para garantir que os parâmetros de risco permaneçam alinhados com a realidade do mercado.

O exploit foi causado por um erro lógico em um contrato inteligente que permitiu a cunhagem dupla de moedas. O invasor implantou dois contratos especializados para automatizar a sequência de 22 loops. A transação do ataque envolveu 76 transferências separadas de tokens ERC-20. As etapas finais da transação concentraram-se na conversão dos tokens BRO inflados em ativos líquidos.

O atacante explorou uma falha de design na função swap() que permitia chamadas arbitrárias do executor, resultando no roubo de usuários que haviam concedido aprovações ilimitadas.

As supostas chaves de assinatura do validador que vazaram e um empréstimo relâmpago permitiram ao invasor obter poder de voto exclusivo. Tendo controle sobre os validadores, o invasor usou fundos da ponte no mesmo bloco para comprar BONE, delegá-lo para poder de validador, assinar pontos de verificação fraudulentos e, em seguida, pagar o "empréstimo" com os ativos roubados.

O invasor usou uma chave privada comprometida de uma conta de administrador de proxy para atualizar um contrato inteligente para uma versão maliciosa. Em seguida, o invasor usou a versão maliciosa do contrato inteligente para drenar o saldo do próprio contrato, bem como as carteiras dos usuários que haviam aprovado esse contrato inteligente.

O acesso não autorizado à API da Kiln, um parceiro de staking da SwissBorg, levou ao roubo de US$ 41,5 milhões do programa de staking SOL Earn. Os atacantes manipularam as autoridades das contas de staking sem a necessidade de confirmações de multi-assinatura. Isso permitiu que eles transferissem a autoridade silenciosamente, mantendo a função de "Withdrawer", o que os ajudou a evadir as ferramentas de monitoramento padrão que se concentram em eventos de retirada. A violação foi uma exploração da API off-chain que deu aos atacantes controle sobre os ativos on-chain.

Um desenvolvedor da Nemo introduziu uma nova funcionalidade, não auditada, no código após a auditoria de segurança inicial, mas antes que o relatório revisado final estivesse completo. Consequentemente, uma versão do contrato contendo este código não auditado foi implantada na rede principal (mainnet). A causa raiz da governança foi a dependência do protocolo em um endereço de assinatura única para atualizações, que falhou em impedir a implantação de código que não havia passado por uma revisão de segurança completa. Além disso, o desenvolvedor implantou uma versão do código diferente daquela confirmada pela empresa de auditoria. Um invasor explorou essas funções não auditadas para manipular o estado interno e drenar com sucesso uma quantidade substancial de ativos do pool de liquidez.

Os atacantes usaram um cliente malicioso do Zoom para obter privilégios na máquina da vítima. Eles exploraram esse acesso para enganar a vítima a enviar uma transação que aprovou o atacante como um delegado Venus válido de sua conta, permitindo que o atacante pegasse e resgatasse empréstimos em nome da vítima.

Atacantes obtiveram acesso a uma carteira multisig com 32 milhões de tokens AIO. Os fundos foram movidos e trocados por US$ 2 milhões.

O invasor explorou uma vulnerabilidade no contrato conector, que converte automaticamente tokens com rendimento (como aUSDC) em USDC durante os saques. Usando essa falha, o hacker executou um saque em nome de outro usuário e desviou $427.000 em USDC da Aave.

O invasor explorou a falta de validação adequada para criar tokens FAVOR não seguros. Ele usou um contrato inteligente forjado como provedor de liquidez (LP) e, em seguida, executou uma troca em massa para obter um bônus significativo que poderia ser convertido em dinheiro real. O auditor, zokyo, havia relatado anteriormente vulnerabilidades diretamente relacionadas a este ataque. No entanto, devido a uma análise aprofundada insuficiente, a gravidade dessas descobertas foi rebaixada para um nível baixo.

A exchange de criptomoedas turca BTCTurk foi explorada por US$ 48 milhões. O ataque envolveu o vazamento de chaves privadas, permitindo que os invasores drenassem fundos de carteiras quentes em sete blockchains diferentes. A exchange suspendeu os serviços de cripto.

Odin.fun, uma plataforma de lançamento e negociação de memecoins baseada em Bitcoin, sofreu um exploit. O ataque explorou uma falha na ferramenta de formador de mercado automatizada da plataforma, introduzida na última atualização. Os atacantes realizaram um esquema de manipulação de liquidez adicionando tokens como SATOSHI para aumentar os preços e, em seguida, retirando sua liquidez para sacar em Bitcoin.

Um invasor usou o papel BRIDGE para emitir tokens sem a garantia adequada. Esses tokens foram então usados como garantia para empréstimos em outros tokens. Os fundos emprestados (garantidos pelos tokens sem colateral) foram retirados e lavados na rede Ethereum.

O controle de acesso na função updateMerkleRoot() foi configurado incorretamente. Em vez de verificar se o endereço chamador É o proprietário, o código verificava se NÃO É o proprietário. Esse erro de codificação do contrato inteligente permitiu que um invasor formasse uma raiz Merkle falsa e atualizasse o contrato inteligente com ela. A raiz fabricada permitiu que o invasor retirasse tokens do contrato inteligente.

Um invasor comprometeu o dispositivo de um desenvolvedor usando um ataque de phishing. O acesso ao ambiente de desenvolvimento foi obtido. O invasor iniciou a retirada de fundos de 9 contas de usuário.

O incidente envolveu acesso não autorizado a uma carteira operacional usada para provisionamento de liquidez em uma exchange parceira.

Um ataque à cadeia de suprimentos que comprometeu a rede de produção, permitindo que os atacantes modificassem a lógica operacional dos servidores de controle de conta e risco.

O protocolo tinha um sistema de disjuntor que foi acionado quando o contrato malicioso foi implantado. No entanto, um mecanismo embutido, projetado para evitar que o protocolo fosse pausado indefinidamente, foi usado pelo invasor contra o próprio protocolo. Quando a equipe executou simulações com o contrato inteligente malicioso e não encontrou possíveis caminhos de exploração, eles despausaram o protocolo. As ações subsequentes do invasor não foram interrompidas devido ao limitador previamente descrito na re-pausa do protocolo. O invasor usou flash loans e calldata maliciosos para drenar as contas das vítimas. A causa raiz do hack foi a falta de validação de calldata.

Uma backdoor crítica foi descoberta em milhares de contratos que usam ERC1967Proxy. Um hacker conseguiu "front-run" a inicialização e instalar um proxy hacker no meio, permanecendo indetectado devido a um bug nos exploradores de blocos. O hacker cunhou 110.000 tokens K e iniciou o ataque para drenar tanto o Morpho Vault quanto o pool Uniswap v4.

O exploit se originou do contrato inteligente malicioso criado pelo atacante, que foi usado para criar e sequestrar a execução durante o cumprimento do pedido. A causa raiz inclui a suposição implícita em executeDecreaseOrder() de que o parâmetro _account é uma Conta de Propriedade Externa (EOA), quando na verdade pode ser um contrato inteligente malicioso. Essa vulnerabilidade levou a um ataque sofisticado de várias etapas, onde o atacante conseguiu inflar artificialmente o AUM do protocolo e resgatar GLP por mais ativos do que o devido.

Um atacante conseguiu explorar o recurso de rebalanceamento do contrato Texture Vaults para acionar uma transferência. O atacante forneceu sua própria conta de token, que o Vault preencheu erroneamente com tokens LP durante o rebalanceamento. O atacante então resgatou esses tokens LP por liquidez real.

Um pool de baixa liquidez foi usado por um usuário como oráculo ao configurar um pod. O invasor conseguiu manipular este pool usando um empréstimo instantâneo (flash loan), e então um empréstimo subcolateralizado foi tomado.

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.

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 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.

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.