Еженедельный обзор инцидентов безопасности Web3 | 16–22 марта 2026 г.

За прошедшую неделю (2026/03/16 - 2026/03/22) компания BlockSec обнаружила и проанализировала семь инцидентов, связанных с атаками, общий предполагаемый ущерб составил ~$82,7 млн. В таблице ниже приведена сводка этих инцидентов, а подробный анализ каждого случая представлен в следующих подразделах.

*Инцидент Venus не был освещён в отчёте прошлой недели и включён сюда для полноты картины.

1. Инцидент Venus

Краткое резюме

15 марта 2026 года рынок THE (Thena) протокола Venus на BNB Chain подвергся атаке через пожертвование в сочетании с манипуляцией рынком, что привело к появлению плохого долга на сумму около ~$2,15 млн. Лимит предложения рынка THE применялся только к пути минтинга, тогда как прямые пожертвования токенов на рынок всё равно увеличивали cash и завышали exchangeRate. Затем злоумышленник воспользовался этой завышенной стоимостью залога для заимствования ликвидных активов и приобретения большего количества THE, одновременно разгоняя рыночную цену токена THE, что в итоге оставило протокол с плохим долгом после принудительной ликвидации позиции.

Общие сведения

Venus — это протокол кредитования, форкнутый с Compound V2. На рынке THE пользователи вносят THE и получают токены vTHE. exchangeRate определяет, какую долю базовых активов рынка представляет каждый vTHE, и его основная формула выглядит следующим образом:

exchangeRate = (cash + borrows - reserves) / totalSupply

Здесь cash — баланс базового токена на рынке, borrows — общий непогашенный долг, reserves — резервы протокола, totalSupply — общий объём предложения vTHE. На рынке THE также установлен лимит предложения, призванный ограничить общий залоговый риск.

Анализ уязвимости

В этом инциденте использовались два взаимодополняющих вектора атаки против контракта рынка vTHE (0x86e0...739f).

Атака через пожертвование

Протокол получает значение cash непосредственно из необработанного баланса токенов контракта рынка, что делает его изначально уязвимым для атак через пожертвование. Любой прямой перевод THE в контракт рынка vTHE увеличивает cash и, следовательно, exchangeRate. Злоумышленник использовал это для завышения exchangeRate примерно в 3,81 раза, усилив залоговую стоимость своей существующей позиции vTHE.

Манипуляция рынком

Токен THE обладал низкой ликвидностью в сети, что делало его спотовую цену уязвимой к манипуляции при относительно небольшом давлении покупок. Оракул протокола настроен на отклонение цен, которые слишком сильно отклоняются от эталонного значения: он корректно отклонял экстремальные цены в течение примерно 37 минут во время атаки. Однако устойчивое давление покупателей в конечном итоге подтолкнуло цену токена THE примерно до $0,51, что примерно вдвое превышало цену до атаки, и оракул в итоге принял её.

Эти два вектора усиливали друг друга. Завышенный exchangeRate в результате атаки через пожертвование увеличил залоговую стоимость каждой единицы vTHE, тогда как манипулятивная цена токена THE ещё больше раздула заёмную мощность. Вместе это позволило злоумышленнику накопить ~$14,9 млн в займах против позиции, превышающей лимит предложения в 3,67 раза.

Анализ атаки

Следующий анализ основан на примере транзакции атаки 0xce6e3e...1f5fb0e.

• Шаг 1: Кошелёк, связанный со злоумышленником, получил 7 447 ETH через 77 транзакций, связанных с TornadoCash, примерно за девять месяцев. Этот ETH был внесён в Aave, и было заимствовано ~$9,92 млн в стейблкоинах для создания позиции vTHE объёмом около 12,2 млн THE, что составляет примерно 84% от лимита предложения в 14,5 млн THE.

• Шаг 2: В ходе первой транзакции атаки шесть адресов перевели около 36 млн THE напрямую в контракт рынка vTHE. Контракт атаки также заимствовал 1,58 млн USDC, вновь предоставил их, затем заимствовал около 4,6 млн THE и перевёл их напрямую в vTHE. Это подняло exchangeRate примерно в 3,81 раза.

• Шаг 3: В последующих транзакциях злоумышленник заимствовал ликвидные активы, включая CAKE, BNB, BTCB и USDC. Злоумышленник продолжал покупать THE на заимствованные активы и жертвовать всё больше THE в vTHE, создавая петлю, которая увеличивала как заёмную мощность позиции, так и рыночную цену токена THE.

• Шаг 4: Цена токена THE выросла примерно с $0,2, при этом источник цены Binance ненадолго приблизился к $4. Оракул протокола отклонял экстремальные цены в течение примерно 37 минут, прежде чем в конечном счёте принял цену около $0,51.

• Шаг 5: К 20:42 UTC+8 позиция злоумышленника достигла около 53,2 млн THE, что примерно в 3,67 раза превышает лимит предложения, с общим объёмом заимствований около ~$14,9 млн.

• Шаг 6: Затем позиция подверглась масштабной ликвидации. Около 42 млн THE в качестве залога было ликвидировано в ходе 8 048 транзакций ликвидации от 254 адресов ликвидаторов. По мере продолжения продаж токен THE упал примерно до $0,22. Выручка от ликвидации не смогла покрыть весь долг, оставив Venus с ~$2,15 млн чистого плохого долга.

Заключение

Этот инцидент не выявил новой уязвимости. Он продемонстрировал, как хорошо известный вектор атаки, методично реализованный, способен сокрушить весь стек управления рисками протокола, когда каждый уровень предполагает, что другие выдержат. Предупреждающие сигналы были видны в сети на протяжении месяцев, однако разрыв между обнаружением и устранением так и не был ликвидирован. Устранение этого разрыва с помощью параметров риска, учитывающих ликвидность, автоматических автоматических выключателей и мониторинга на уровне позиций — главный урок, который этот инцидент преподаёт другим протоколам кредитования.

Подробный анализ см. в нашей публикации [1].

Ссылки

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. Инцидент dTRINITY

Краткое резюме

17 марта 2026 года протокол кредитования dTRINITY, форк Aave V3 на Ethereum, был взломан через рынок кредитования dLEND, что привело к убыткам в размере ~$257,3K. Первопричиной стала уязвимость пустого рынка, присущая форкам Aave V3. Когда резерв содержит почти нулевую ликвидность, многократное накопление премий за флеш-кредиты приводит liquidityIndex к экстремальному значению. После искажения учёта резервов злоумышленник воспользовался потерей точности в путях депозита и вывода средств для завышения залога, заимствовал dUSD и вернул внесённый cbBTC с чистой прибылью.

Общие сведения

dTRINITY включает систему стейблкоина dUSD и dLEND — рынок кредитования, форкнутый с Aave V3. В базовом контракте L2Pool (0xfda3...e19e84) у каждого актива есть собственный резерв, а учёт резервов основан на масштабированных балансах и уровне резерва liquidityIndex. Текущий базовый баланс пользователя определяется путём умножения масштабированного баланса на нормализованный доход резерва.

Премии за флеш-кредиты добавляются в учёт резервов через cumulateToLiquidityIndex(), где:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

Когда totalLiquidity становится крайне малым, каждое накопление премии может поднимать liquidityIndex с аномально высокой скоростью.

Анализ уязвимости

Ключевым условием для атаки был почти пустой резерв на рынке dLEND-cbBTC (0x504d...3acc). После того как резерв был сжат до единственной масштабированной доли, премии за флеш-кредиты больше не распределялись по значимой базе предложения. Повторные флеш-кредиты поэтому вызывали чрезвычайно быстрый рост liquidityIndex.

После раздувания liquidityIndex преобразование базового актива в масштабированный перешло в режим экстремального округления. В этом состоянии небольшой депозит мог создать одну дополнительную долю, тогда как вывод на значительно большую сумму всё равно сжигал только одну долю. Эта асимметрия позволила злоумышленнику завысить залог aCbBTC и занять реальный dUSD из другого резерва, поскольку проверки состояния здоровья выполнялись на уровне пула, а повреждённый резерв cbBTC напрямую влиял на заёмную мощность кросс-активных позиций.

Анализ атаки

Эксплойт состоял из двух транзакций: 0x8d33d6...40ae7139 и 0xbec4c8...4fc33260.

Транзакция 1: манипуляция liquidityIndex

• Шаг 1: Занять cbBTC в Morpho Blue.

• Шаг 2: Внести cbBTC в dLEND-cbBTC для создания 100 масштабированных долей.

• Шаг 3: Вывести 99 единиц долей так, чтобы осталась только 1 доля, сжав резерв dLEND-cbBTC почти до нулевого состояния масштабированного предложения.

• Шаг 4: Перевести 80 000 000 единиц cbBTC (т.е. 0,8 cbBTC) напрямую на aToken dLEND-cbBTC.

• Шаг 5: Выполнить 150 вызовов Pool.flashLoan() для накопления премии в учёте резервов, подняв liquidityIndex до 6 226 621 999 999 999 999 999 999 979 728 276.

• Шаг 6: Выполнить повторные циклы депозита и вывода для извлечения остаточных денежных средств резерва.

• Шаг 7: Погасить флеш-кредит.

Транзакция 2: получение прибыли

• Шаг 1: Снова занять cbBTC в Morpho Blue.

• Шаг 2: Внести ~7,72 cbBTC в уже манипулированный резерв для создания завышенной залоговой позиции aCbBTC.

• Шаг 3: Используя завышенный залог, занять 257 328 dUSD на рынке dLEND-dUSD.

• Шаг 4: Продолжить извлечение cbBTC через повторные циклы депозита/вывода.

• Шаг 5: Погасить флеш-кредит Morpho и перевести заимствованный dUSD на EOA злоумышленника.

Заключение

Этот инцидент является примером атаки на пустой рынок, которая хорошо задокументирована применительно к форкам Aave V3. Данная схема встречалась в нескольких протоколах, и способ её нейтрализации хорошо известен. Введение минимального порога предложения при инициализации резерва предотвращает переход резерва в состояние, при котором рост индекса становится неуправляемым. Поэтому протоколы, форкающие Aave V3, должны рассматривать начальное наполнение резервов как критически важную операцию и обеспечивать блокировку значимой ликвидности на этапе развёртывания, а не рассчитывать на органический приток депозитов для стабилизации индекса.

3. Инцидент Fun.xyz

Краткое резюме

17 марта 2026 года протокол платёжной инфраструктуры Fun.xyz на Polygon был взломан на ~$85,7K. Первопричиной стало то, что устаревший CheckoutPool предоставлял критическую функцию bridge() без контроля доступа и без привязки данных вызова bridge к предполагаемому получателю. Эта уязвимость позволила злоумышленнику перенаправить выполнение в доверенный путь расчётов и перевести средства на подконтрольный ему смарт-аккаунт.

Общие сведения

CheckoutPool — основной расчётный контракт в платёжной инфраструктуре Fun.xyz. В обычном процессе пользователь создаёт оформление заказа через deposit(), а доверенный оператор продвигает его по путям расчётов, таким как bridge() и execute(). Для операций моста bridge() выполняет внешний вызов на основе предоставленных вызывающей стороной bridgeParams.target и bridgeParams.callData.

Анализ уязвимости

Первопричина заключается в том, что устаревший CheckoutPool (0x1304...2ec01a) предоставлял чувствительный путь маршрутизации расчётов через функцию bridge() без надлежащего контроля доступа, одновременно не проверяя внешне предоставленные данные вызова bridge на соответствие предполагаемому получателю. В частности:

• Устаревшая реализация не применяла onlyOperator к bridge(), позволяя любому внешнему вызывающему обращаться к функции после создания оформления заказа через deposit().

• bridge() передавала предоставленные вызывающей стороной bridgeParams в _bridgeToRecipient(), который выполнял внешний вызов без проверки получателя по записи оформления заказа.

Дополнительное операционное условие сделало эксплойт практически применимым: на момент атаки устаревший CheckoutPool по-прежнему обладал привилегиями оператора в CheckoutPaymaster. Это позволило специально созданному вызову bridge() достичь CheckoutPaymaster.activateAndCall(), который затем вызвал новый путь CheckoutPool.execute(), переведя средства на адрес под контролем злоумышленника.

Анализ атаки

Следующий анализ основан на транзакции атаки 0x957bcf...1f4f5a.

• Шаг 1: Создать смарт-аккаунт ERC-4337 0xb648 и указать его как отправителя и плательщика в внешней UserOperation.

• Шаг 2: Вызвать deposit() как в устаревшем, так и в новом CheckoutPool, создав запись оформления заказа в новом CheckoutPool с суммой расчётов 85 730 USDC.

• Шаг 3: Вызвать bridge() в устаревшем CheckoutPool с вредоносными bridgeParams: установить bridgeParams.target на CheckoutPaymaster и закодировать bridgeParams.callData как вызов activateAndCall(), содержащий внешнюю UserOperation в качестве внутренней полезной нагрузки.

• Шаг 4: Достичь execute() в новом CheckoutPool (0x1929...0215), который переводит 85 730 USDC на адрес 0xb648, указанный как ops[0].sender во внешней UserOperation.

• Шаг 5: Перейти в EntryPoint.handleOps(): поскольку 0xb648 выступает как отправителем, так и плательщиком, как проверка аккаунта, так и проверка плательщика остаются под контролем злоумышленника, что позволяет ему получить прибыль в размере 85 730 USDC.

Заключение

Этот инцидент был вызван отсутствием в устаревшем CheckoutPool как контроля доступа, так и привязки данных вызова к получателю в пути bridge(), что привело к убыткам в размере ~$85,7K. Для предотвращения подобных инцидентов протоколы должны обеспечивать строгий контроль доступа ко всем чувствительным путям маршрутизации и расчётов, гарантировать соответствие внешне предоставляемых полезных нагрузок получателям, определённым протоколом, а также удалять устаревшие контракты из доверенных привилегированных отношений после развёртывания исправленных замен.

4. Инцидент Keom

Краткое резюме

18 марта 2026 года протокол кредитования Keom, форк Compound V2 на Polygon zkEVM, был взломан примерно на $35K. Первопричиной стала ошибочная логика учёта в redeemFresh(), вызываемом redeemUnderlying(). Функция ограничивала уменьшение долей до фактического баланса пользователя, но не пересчитывала соответствующую сумму вывода базового актива. Это несоответствие позволило злоумышленнику погасить значительно больше активов, чем должны были позволять его доли.

Общие сведения

Keom — протокол кредитования, форкнутый с Compound V2. Пользователи вносят ETH на рынок и получают kETH. При погашении протокол конвертирует доли kETH обратно в ETH по текущему обменному курсу. В протоколе существуют две точки входа для погашения: redeem() для погашения по количеству долей и redeemUnderlying() для погашения по желаемой сумме базового актива.

Анализ уязвимости

Уязвимость находится в redeemFresh() рынка kETH (0x4c6e...0403), вызываемом redeemUnderlying(). Контролируемый пользователем параметр redeemAmountIn сначала присваивается redeemAmount, а затем используется для вычисления redeemTokens по текущему обменному курсу. Если redeemTokens превышает баланс погашающего, функция ограничивает его значением accountTokens[redeemer]. Однако после этого ограничения redeemAmount не пересчитывается и остаётся равным исходному redeemAmountIn. Это позволяет погашающему вывести полный redeemAmount базовых активов, сжигая лишь часть соответствующих долей.

Как показано в фрагменте кода ниже, redeemFresh() также выполняет проверку состояния здоровья через redeemAllowed(). В дизайне Compound V2 redeemAllowed() проверяет markets[cToken].accountMembership[redeemer] и вызывает проверку ликвидности только тогда, когда аккаунт вошёл на этот рынок cToken; в противном случае проверка полностью пропускается. Поскольку redeemAmountIn контролируется злоумышленником и может быть установлен произвольно большим, проверка ликвидности завершилась бы неудачей, если бы kETH по-прежнему учитывался как залог. Это означает, что одна лишь уязвимость учёта не поддаётся прямой эксплуатации без предварительного обхода проверки состояния здоровья.

Анализ атаки

Следующий анализ основан на транзакции атаки 0x4ccde7...03d9dfd8.

• Шаг 1: Вызвать mint() всего с 0,001 ETH, получив минимальный баланс kETH.

• Шаг 2: Вызвать exitMarket() для очистки членства аккаунта на рынке kETH, чтобы redeemAllowed() полностью обошла проверку ликвидности (как описано в разделе «Анализ уязвимости» выше).

• Шаг 3: Вызвать redeemUnderlying() для вывода всего баланса ETH рынка (~38,6 ETH), воспользовавшись ошибочным учётом для опустошения рынка от ETH.

Заключение

Этот инцидент был вызван уязвимостью учёта, не пересчитывающей redeemAmount после ограничения redeemTokens до фактического баланса пользователя, что привело к убыткам примерно в $35K. Логика погашения должна пересчитывать все зависимые значения после любого ограничения или корректировки для сохранения инварианта доля-к-базовому-активу. Форки Compound V2 должны тщательно проверить этот путь, поскольку аналогичные уязвимости могут существовать в других производных.

5. Инцидент ShiMama

Краткое резюме

18 марта 2026 года дефляционный токен-протокол ShiMama на BNB Chain был взломан примерно на $35K. Первопричиной стало отсутствие контроля доступа к функции executePairBurn(), которое позволило любому пользователю инициировать вывод и сжигание резервов пула, что открыло возможность для манипуляции ценой.

Общие сведения

Протокол ShiMama включает встроенный механизм дефляции, предназначенный для изъятия токенов из пула AMM и их сжигания. Этот механизм реализован в ShiMama Protocol и ShiMama Token. Функция executePairBurn() в ShiMama Protocol вычисляет сумму изъятия на основе предоставленного вызывающей стороной параметра referenceIn:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

Затем она вызывает forcePullFromPair() токена ShiMama, после чего следует pair.sync() и сжигание изъятых токенов.

Анализ уязвимости

Первопричиной является отсутствие контроля доступа к функции executePairBurn() в контракте ShiMamaProtocol (0x5049...0b49a). Функция доступна извне без каких-либо ограничений, поэтому любой пользователь может инициировать привилегированное перемещение резервов и синхронизацию пула. referenceIn также контролируется вызывающей стороной и не привязан к какой-либо реальной сумме продажи. В ShiMamaToken.forcePullFromPair() протокол может напрямую перемещать балансы из пула Pancake без каких-либо ограничений, обеспечивая произвольное изъятие резервов с немедленной синхронизацией и, следовательно, манипуляцию спотовой ценой.

Анализ атаки

Следующий анализ основан на транзакции атаки 0x13959b...3c20e001.

• Шаг 1: Занять WBNB через флеш-кредит Moolah.

• Шаг 2: Перевести 30,78e18 ShiMama, заранее полученные в более ранней транзакции, в контракт атаки. Поскольку прямые покупки ShiMama из пула Pancake были отключены, злоумышленник получил ShiMama, предоставив и выведя ликвидность в ShiMama Protocol перед атакой.

• Шаг 3: Вызвать executePairBurn() для изъятия 1 311 349 143,96 токенов ShiMama из пула Pancake и их сжигания, что фактически искусственно завысило цену ShiMama.

• Шаг 4: Злоумышленник обменял 30,78e18 ShiMama на 52,98e18 WBNB в PancakeSwap по завышенной цене.

• Шаг 5: Погасить флеш-кредит, оставив 52,98 WBNB в качестве чистой прибыли.

Заключение

Этот инцидент был вызван отсутствием контроля доступа к executePairBurn(), что открыло несанкционированный путь для изменения резервов пула. Любая функция, изменяющая резервы, экономически чувствительна и должна быть строго разрешена. Контролируемые вызывающей стороной входные данные должны быть привязаны к значениям, производным от протокола, для предотвращения усиления извлечения резервов.

6. Инцидент BlindBox

Краткое резюме

19 марта 2026 года игровой протокол ставок BlindBox на BNB Chain был взломан примерно на $99K. Первопричиной стала слабая случайность, позволившая злоумышленнику предсказать исход и достичь 100% выигрыша. Кроме того, getTwapPrice() опиралась на манипулируемое спотовое ценообразование, а не на настоящее средневзвешенное по времени значение, что позволило злоумышленнику заранее завысить цену в пуле и делать ставки, превышающие предполагаемые лимиты протокола.

Общие сведения

BlindBox — игровой протокол, позволяющий пользователям делать ставки, переводя токены ATM на мёртвый адрес. Протокол определяет исход на основе чётности последующего blockhash. В случае выигрыша BlindBox выплачивает 1,95x от исходной суммы ATM из банкролла на мёртвом адресе. Для ограничения размера каждой ставки протокол использует getTwapPrice().

Анализ уязвимости

Контракт BlindBox (0x1F83...734c59) содержит две уязвимости:

1. Слабая случайность: когда время расчёта превышает 256 блоков, blockhash(bet.blockNum + 2) возвращает ноль. Затем протокол переходит к случайности, производной от block.prevrandao, betId и block.timestamp. Поскольку эти входные данные могут быть смоделированы вне сети до отправки транзакции, злоумышленник мог вызывать settle() только тогда, когда вычисленный результат был благоприятным, добиваясь детерминированного выигрыша.

2. Манипулируемый лимит цены: для ограничения размера ставки протокол использует getTwapPrice(). Однако эта функция не реализует настоящую средневзвешенную по времени цену; вместо этого она считывает спотовую цену в пуле ATM/USDT. Это позволяет злоумышленникам обходить лимит, манипулируя ценой пула перед размещением ставки.

Анализ атаки

Следующие шаги иллюстрируют схему атаки. Шаги 2 и 3 образовывали парную последовательность (например, betId=5 284), и злоумышленник повторял эту пару несколько раз для накопления прибыли.

• Шаг 1: Манипулировать пулом ATM/USDT, завысив спотовую цену ATM, чтобы getTwapPrice() допускал больший размер ставки на следующем шаге.

• Шаг 2: Сделать крупную ставку, переведя завышенное допустимое количество ATM на мёртвый адрес (например, 0x4be049...3af12c).

• Шаг 3: Подождать более 256 блоков, чтобы blockhash вернул ноль и активировался резервный путь. Затем злоумышленник моделировал исходы вне сети и вызывал settle() только в том блоке, где вычисленный результат был благоприятным (например, 0x68eedc...718ce8).

Заключение

Этот инцидент был вызван предсказуемой случайностью в сочетании с манипулируемой спотовой ценой в качестве входных данных TWAP, что привело к убыткам примерно в $99K. Для снижения аналогичных рисков протокол должен устранить любой путь расчёта, который становится предсказуемым после истечения окна blockhash, и заменить getTwapPrice() источником ценообразования, устойчивым к краткосрочным манипуляциям с резервами.

7. Инцидент Resolv

Краткое резюме

22 марта 2026 года протокол стейблкоинов Resolv на Ethereum подвергся компрометации инфраструктурного ключа, что обеспечило несанкционированное исполнение привилегированной логики финализации свопов. В ходе инцидента злоумышленник воспользовался привилегированной функцией для создания более 80 млн не обеспеченных залогом USR. Воздействие вышло далеко за рамки непосредственного события минтинга: последовавшая депривязка USR вызвала более широкое заражение в кредитных протоколах, где активы Resolv использовались в качестве залога.

Общие сведения

Resolv — протокол стейблкоинов, в котором выпуск USR зависит от расчёта свопов с обеспечением залогом. Конвейер завершения свопов completeSwap() -> mint() -> transfer() напрямую влияет на объём обращающегося USR и поэтому зависит как от целостности авторизации, так и от целостности залога. В обычном режиме completeSwap() в контракте Resolv (0xa27a...5861) может вызываться только привилегированным инфраструктурным ключом (именуемым в коде SERVICE_ROLE) после проверки соответствующего депозита залога.

Анализ уязвимости

Инцидент был связан с компрометацией привилегированного ключа, который вызвал доверенную логику расчётов и достиг пути минтинга USR без эквивалентного входящего залога. После того как злоумышленник получил контроль над привилегированным полномочием подписи, путь completeSwap() не предусматривал никакого принудительного применения предварительных условий минтинга в сети: проверка залога полностью зависела от внецепочечной авторизации. Это превратило компрометацию уровня управления непосредственно в нарушение целостности предложения.

Анализ атаки

• Шаг 1: До эксплойта злоумышленник отправил запрос на своп в транзакции 0x590b5c...de732c89, подготовив необходимое состояние для последующего вредоносного завершения свопа.

• Шаг 2: Используя скомпрометированный привилегированный ключ, злоумышленник вызвал completeSwap() для создания более 80 000 000 USR в ходе трёх транзакций: 0xfe37f2...dc33743, 0x41b6b9...db1f18f и 0x7f9143...53a931d.

Заключение

Этот инцидент подчёркивает, что безопасность стейблкоина зависит от жёстких предварительных условий минтинга в сети, а не только от доверенных ролей операторов. Примечательно, что последствия этого инцидента вышли далеко за рамки несанкционированного создания $80 млн USR. Поскольку активы Resolv широко использовались в качестве залога в нескольких кредитных протоколах, депривязка повлекла более широкое заражение. Как сообщили Chaos Labs, операторы в сети, использующие автоматизированное распределение капитала для получения доходности, не имели контролей рисков в реальном времени и продолжали направлять свежий капитал на уже повреждённые рынки. То, что началось как локализованный эксплойт, быстро переросло в межпротокольное событие заражения, оставив кредитные протоколы с миллионами в плохих долгах.

О BlockSec

BlockSec — поставщик комплексной безопасности блокчейна и решений для криптовалютного комплаенса. Мы создаём продукты и услуги, помогающие клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в реальном времени, анализировать инциденты, отслеживать незаконные средства и выполнять требования ПОД/ФТ на протяжении всего жизненного цикла протоколов и платформ.

BlockSec опубликовала несколько работ по безопасности блокчейна на престижных конференциях, сообщила о нескольких атаках нулевого дня на DeFi-приложения, заблокировала несколько взломов, спасая более 20 миллионов долларов, и обеспечила безопасность криптовалют на миллиарды долларов.

• Официальный сайт: https://blocksec.com/

• Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam

• 🔗 Услуга аудита BlockSec : Отправить заявку

• 🔗 Phalcon Security APP: Заказать демонстрацию

• 🔗 Phalcon Compliance