Cosmos Labs предупреди, че критична уязвимост при обработката на баланси в споделения Cosmos EVM модул е била експлоатирана за източване на средства от шест блокчейн мрежи в периода между 20 и 25 август 2026 г.

Уязвимостта, обозначена като GHSA-7g4w-cg88-2cq2, е оценена като „критична“ от Cosmos Labs и бе публикувана без CVE идентификатор, класификация на слабостта или CVSS оценка.

Засегнатите версии са < 0.6.2 и >= 0.7.0 < 0.7.2, а корекцията за сигурност бе внедрена във версии v0.6.2 и v0.7.2 на 19 август. На операторите на мрежи се препоръчва да обновят до някоя от тези версии или по-нова – промяна, която нарушава текущото състояние на мрежата (state-breaking) и изисква координирано обновяване.

На операторите, които не могат да обновят системата незабавно, се препоръчва да спрат блокчейна, вместо да опитват координирано обновяване чрез управлението на мрежата (governance upgrade).

В анализ на инцидента, публикуван на 28 август, Cosmos Labs съобщи, че уязвимостта е била докладвана чрез програмата им за разкриване на грешки срещу заплащане (bug bounty) на 25 април, като по това време е било оценено, че тя не застрашава средства в реално работещите мрежи.

„Не успяхме да възпроизведем уязвимостта в мрежи с 18 десетични знака и погрешно заключихме, че тя засяга само мрежи, различни от тези с 18 десетични знака“, заявява екипът на Cosmos Labs в своя анализ.

До 13 август екипът потвърждава, че всички Cosmos EVM вериги са засегнати, независимо от десетичната им конфигурация. След това корекцията е насочена през същия публичен процес за тиха интеграция на обновления (silent patch), който компанията запазва за проблеми, неотразяващи се на загуба на средства в производствени мрежи.

„Към този момент, за уязвимост, за която е известно, че застрашава средства на потребители в реални производствени мрежи, екипът обикновено би използвал сигурни канали за частно разпространение на корекция за сигурност до засегнатите мрежи. Тъй като корекцията вече беше публично достъпна в основния клон без известни случаи на злоупотреба, екипът заключи, че е безопасно да продължи с процеса на тихо обновяване“, обясняват от Cosmos Labs.

Собствената публикувана политика на компанията за тихи корекции обаче предвижда друг курс на действие за уязвимости от този клас.

„Когато даден проблем представлява непосредствен риск или заплаха за цялата мрежа, Cosmos Labs ще предприеме спешни мерки за смекчаване на последиците, частно разпространение на корекции или координирани обновявания преди каквото и да е публично оповестяване“, се посочва в политиката за разкриване на уязвимости на компанията, последно синхронизирана на 27 юли.

Слабостта се намира в кода, който съгласува състоянието на Ethereum Virtual Machine (EVM) с модула x/bank на Cosmos SDK. Базата данни за състоянието на EVM (StateDB) проследява само баланса на акаунта, наличен за харчене, докато вестинг акаунтите (vesting accounts) в състоянието на SDK съдържат както баланс за харчене, така и заключен баланс, като и x/staking, и предварителната компилация (precompile) за залагане позволяват заключената част да бъде делегирана.

Когато вестинг акаунт делегира сума, надвишаваща баланса му за харчене, обратният запис след делегирането изважда пълната делегирана сума от по-малката стойност на баланса за харчене. Изваждането се извършва без проверка и балансът се превърта (overflow) до приблизително 2^256.

След това съгласуването създава монети (mints) при положителна разлика и ги изгаря (burns) при отрицателна. Атакуващият може да прехвърли ограничена сума от превъртения акаунт или да изпрати на акаунта на жертва сума, равна на 2^256 минус нейния баланс, така че съгласуването да изгори реалните авоари на жертвата.

Мрежите, работещи с версия 0.6.x, създават и изгарят монети директно в базовия SDK регистър, така че масираното създаване на монети причинява препълване на предлагането (supply overflow), което спира веригата. Мрежите, използващи версия 0.7.x, задават балансите директно в x/bank и приемат промени, които преминават успешно през преобразуване от uint256 в int256.

И двете операции се изпълняват в рамките на една трансакция с крайна промяна на предлагането, равна на нула, от договор, внедрен на предварително изчислен адрес, който първо е бил превърнат във вестинг акаунт. Успешното извършване на атаката изисква блокчейнът да позволява безпрепятствено създаване на вестинг акаунти без специални разрешения.

На операторите на Cosmos EVM се препоръчва да предприемат следните стъпки:

  • Обновяване до v0.6.2, v0.7.2 или по-нова версия чрез координирано обновяване на мрежата, тъй като промяната нарушава съвместимостта на състоянието.
  • Спиране на работата вместо гласуване. Мрежите, които не могат да обновят веднага, трябва да спрат производството на блокове, вместо да провеждат координирано гласуване за обновяване. В указанията се посочва, че няма техническо решение само чрез конфигурация и че деактивирането на предварителната компилация за залагане премахва основния път за задействане на атаката, но не замества корекцията за сигурност.
  • Премахване на предпоставката за атаката. Отхвърляне на заявките MsgCreateVestingAccount, MsgCreatePermanentLockedAccount и MsgCreatePeriodicVestingAccount в ante handler-а. Вестинг акаунтите, дефинирани при стартирането на мрежата (genesis), не са засегнати.
  • Проверка на реалния път на кода в тестово копие (fork). Частичното прилагане на промени (cherry-pick), което коригира само експортирания помощен инструмент, може да остави дублирано неекспортирано копие в мрежата, въпреки че всички тестове преминават успешно.
  • Прилагане на двете корекции, които липсват в препоръките. Снимката на заключения баланс (locked-balance snapshot) и защитата на системния акаунт на модула (module-account guard) са отделни промени. Защитата на системния акаунт отхвърля безусловно системните акаунти на модулите, което прекъсва EVM повикванията, извършвани от такъв акаунт.
  • Регистриране на контакт за сигурност с Cosmos Labs. По време на инцидента компанията е открила единадесет внедрявания на Cosmos EVM, които никога не са били регистрирани в нейните канали за сигурност.

Документът описва една промяна в основния код – защитата срещу отрицателен баланс SubBalance underflow guard, обединена в главния клон на 15 май като pull request #1176 и пренесена обратно на 13 август. Две допълнителни корекции на баланса се намират в същото хранилище, но не са упоменати никъде в него.