Глибокий аналіз: Атака на маніпуляцію NAV у кредиті з використанням швидкої позики після відв'язування USR від Morpho-скриньки

22 березня 2026 року протокол Resolv зазнав витоку приватного ключа, і зловмисник безпосередньо створив 80 мільйонів беззаставних USR, що спричинило стрімке падіння ціни USR з $1 до $0.025.

Наслідки цієї катастрофи не обмежуються лише власниками USR — більш розумні особи здійснили складну маніпуляцію NAV у сховищі на платформі Morpho.

У цій статті поетапно розберемо логіку цього нападу.

Один. Спершу зрозуміти двошарову архітектуру Morpho

Перед тим, як говорити про атаку, потрібно зрозуміти архітектурний дизайн Morpho, інакше подальше читання буде незрозумілим.

Світ Morpho поділений на дві частини:

Низовий рівень:

Morpho Blue (також званий Morpho Core). Це максимально спрощений, незмінний протокол кредитування. Його філософія — “без дозволу” — будь-хто може створювати кредитні ринки, будь-хто може вносити, позичати, ліквідувати.

Кожен ринок визначається унікальними п’ятьма параметрами: кредитним активом, заставним активом, рівнем ліквідації (LLTV), адресою оракула, моделлю відсоткової ставки.

Між ринками повністю ізольовані: проблеми одного не впливають на інші.

Верхній рівень:

MetaMorpho Vault (сховище). Це ERC-4626 стандартне сховище, яке функціонує як “фондовий продукт”.

Користувачі вносять USDC у сховище, а адміністратор сховища (Curator) відповідає за розподіл цих коштів у різні ринки Morpho Blue для кредитування з метою отримання відсотків.

Користувачі володіють частками сховища (shares), вартість яких зростає з накопиченням відсотків.

Основна формула — чиста вартість на акцію (NAV / Price Per Share): чиста вартість на акцію = totalAssets / totalSupply

totalAssets — це сукупна сума активів сховища у всіх ринках (включно з позиченими коштами, оскільки це “заборгованість”). totalSupply — загальна кількість випущених часток сховища. При накопиченні відсотків totalAssets зростає, але totalSupply залишається незмінним, тому NAV на акцію зростає — і це основа вашого заробітку.

Два. supply(onBehalf) — будь-хто може вносити кошти від імені сховища

Це перший ключовий момент атаки.

У Morpho Blue функція supply() має параметр onBehalf. Це задумано для зручності — наприклад, автоматизовані стратегічні контракти можуть вносити кошти за користувача.

Але ця функція є повністю без дозволу: будь-хто може вказати будь-який адресу як onBehalf, включно з адресою сховища.

Офіційна документація Morpho чітко попереджає: “Warning: Anyone can supply on behalf of the vault so the call to updateWithdrawQueue that expects a market to be empty can be griefed by a front-run.”

Коли ви вносите 10 000 USDC від імені сховища, позиція сховища у цьому ринку збільшується на 10 000, і totalAssets зростає на 10 000. Але загальна кількість часток (totalSupply) не змінюється — оскільки ніхто не додав нові кошти через deposit().

Результат: NAV на акцію підвищується.

Звичайно, це схоже на “пожертву” сховищу — ви власним коштом збільшуєте прибутки всіх акціонерів, і тільки дурень так робить. Але за певних умов цю можливість можна використати.

Три. Supply Cap = 0 ≠ безпечність

Після того, як USR “зірвався” з прив’язки, деякі адміністратори сховищ терміново встановили для ринку USR/USDC обмеження Supply Cap у 0, тобто заборонили додаткові внески у цей ринок. Здається, проблема вирішена?

Проблема у тому, що: Supply Cap — це обмеження на рівні сховища, а не Morpho Blue.

Адміністратор сховища може контролювати лише внутрішню функцію _supplyMorpho().

Але supply(onBehalf=vault) напряму взаємодіє з контрактом Morpho Blue Core, обходячи всі логіки сховища: чергу supply, обмеження cap, перевірки прав розподілювача — все ігнорується.

Порівняння: адміністратор закрив передні двері (Cap=0), але зловмисник через задні двері Morpho Core безпосередньо закидає туди гроші.

Чотири. Вбудований оракул — маска для боржника

Це другий важливий момент.

Оракул ринку USR/USDC встановлений у фіксоване співвідношення 1:1. Тобто незалежно від того, наскільки знизилася ціна USR на зовнішньому ринку, у світі Morpho 1 USR завжди дорівнює 1 USDC.

Чому адміністратор сховища використовує фіксований оракул? Тому що USR — “стабільна монета”, і в нормі її ціна коливається дуже мало. Фіксований оракул допомагає уникнути “фальшивих ліквідацій” через короткочасні коливання.

Але коли USR справді зірвався з прив’язки, фіксований оракул стає катастрофою — позичальник може використовувати дешевий USR як заставу і отримати значну суму USDC, а протокол про це навіть не здогадується.

Механізм обробки боргів у Morpho тут повністю виходить з ладу — реальне відображення у V1.0 і рівномірний розподіл у V1.1 базуються на здатності протоколу розпізнавати борги.

Якщо оракул зафіксований, він нічого не покаже.

П’ять. Повний сценарій атаки — п’ять кроків у цілій операції

Зараз усі умови зібрані. Нижче — атомарна послідовність дій у одному транзакційному циклі:

Шість. Чому обов’язково потрібен flash loan?

Це найчастіше ігнорується питання. Прибуток атаки — це “штучне збільшення totalAssets і пропорційне зростання часток”. Якщо зловмисник не використовує flash loan, він володіє 0% часток — навіть якщо підняти totalAssets до небес, прибуток отримають інші, а він сам нічого не заробить.

Сім. Хто в цьому програє?

Збільшення на 12 300 USDC, яке отримав зловмисник, — це не “запасні” гроші з повітря. Ці кошти походять із реальної ліквідності інших здорових ринків сховища.

При виведенні коштів сховище витягує USDC у порядку черги withdrawal з різних ринків. USDC у ринку USR вже позичили, і повернути їх неможливо. Тому кошти для викупу беруться з інших ринків — наприклад, wETH/USDC, cbBTC/USDC та інших.

Вісім. Наслідки накладання трьох вразливостей

Цей напад — не один вразливий момент, а сукупність трьох проблем у дизайні:

Заключення

Мінімалістична філософія Morpho — без дозволу, незмінність, мінімальне управління — у більшості випадків є перевагою. Але ця ситуація показує, що такий підхід має свою ціну: відповідальність за безпеку перекладається на користувачів і адміністраторів.

Якщо протокол не виконує перевірку оракулів, відповідальність за їхню надійність лежить на адміністраторі. Якщо протокол не обмежує supply(onBehalf), сховище має додаткові заходи захисту.

Для вкладників важливо не лише обрати правильного Curator, а й розуміти, що безпека залежить від того, хто і як керує цим інструментом. Протокол — це інструмент, і його безпека залежить від користувача.