Критическая уязвимость общего модуля Cosmos EVM позволяла искажать балансы и создавать значение, близкое к 2²⁵⁶. С 20 по 25 августа 2026 года ею воспользовались в шести блокчейнах; первым известным объектом атаки стала MANTRA. Затронутые активы примерно на 2,87 млн долларов продали через децентрализованные биржи, ещё на 2,85 млн долларов, по оценке Cosmos Labs, через централизованные. Общая сумма достигает 5,72 млн долларов, но независимого аудита расчётов не проводилось. Оценка продаж на DEX получена от пострадавших сетей по ценам на 19 августа, а данные по CEX выведены из общедоступных торговых объёмов.
Ошибка зарегистрирована как GHSA-7g4w-cg88-2cq2 и получила от Cosmos Labs уровень Critical. При этом в уведомлении нет идентификатора CVE, формальной категории слабости и оценки CVSS. Уязвимы версии ниже v0.6.2, а также ветка от v0.7.0 до v0.7.2, не включая последнюю: < 0.6.2 и >= 0.7.0 < 0.7.2. Исправления вошли в v0.6.2 и v0.7.2, выпущенные 19 августа 2026 года, и во все последующие релизы с этими изменениями. Патч ломает совместимость состояния, поэтому обычного обновления узла мало: требуется согласованный переход всей сети. Если провести его сразу нельзя, инструкция предписывает остановить цепочку и выпуск блоков. Формула предельно жёсткая: «Остановить, а не голосовать». Управленческое голосование или governance-upgrade не считаются способом снять немедленную угрозу.
Сообщение поступило в bug bounty Cosmos Labs 25 апреля. Первая оценка оказалась неверной: средства действующих сетей сочли защищёнными, а ошибку связали лишь с конфигурациями, где используется не 18 десятичных знаков. В разборе инцидента команда признала: «Мы не смогли воспроизвести уязвимость в сетях с 18 десятичными знаками и ошибочно заключили, что она затрагивает только сети с иным количеством десятичных знаков». Лишь 13 августа Cosmos Labs установила, что уязвимы все цепочки Cosmos EVM независимо от настройки decimals. К тому времени с первого сообщения прошло больше трёх месяцев.
Причина находилась на стыке EVM StateDB и модуля Cosmos SDK x/bank. StateDB видит только доступный для расходования баланс, тогда как vesting-аккаунт Cosmos SDK хранит доступную и заблокированную части. Делегировать заблокированные средства разрешают и x/staking, и staking precompile. Аккаунт мог делегировать сумму больше доступного остатка, поскольку в делегации участвовали locked-средства. После вызова precompile код вычитал всю делегированную сумму из меньшего spendable-баланса без проверки underflow. Число зацикливалось в пространстве uint256 и превращалось в величину около 2²⁵⁶. Механизм сверки затем чеканил монеты при положительной разнице и сжигал их при отрицательной.
Из этой арифметики следовали два сценария. В первом атакующий выводил конечную сумму из аккаунта, чей баланс после переполнения приблизился к 2²⁵⁶. Во втором жертве отправляли 2²⁵⁶ минус её настоящий баланс, после чего сверка уничтожала реальные средства жертвы. Обе части выполнялись в одной транзакции с нулевым итоговым изменением предложения. Для атаки применялся контракт по заранее вычисленному адресу; этот адрес предварительно превращали в vesting-аккаунт. Поэтому обязательным условием служило свободное создание таких аккаунтов. Оператор может перекрыть путь, запретив в ante handler сообщения MsgCreateVestingAccount, MsgCreatePermanentLockedAccount и MsgCreatePeriodicVestingAccount. На vesting-аккаунты, внесённые в genesis, такой фильтр не действует. Отключение staking precompile убирает основной триггер, но не заменяет установку патча; одной настройки, полностью устраняющей дефект, нет.
В ветках Cosmos EVM последствия различались. В 0.6.x чеканка и сжигание проходили в базовом реестре Cosmos SDK, поэтому огромная эмиссия вызывала переполнение общего предложения и могла остановить цепочку. В 0.7.x баланс записывался прямо в x/bank]; система принимала изменения, пережившие преобразование uint256 в int256. Исправление состояло не в одной строке. Pull request 1176, объединённый 15 мая и перенесённый в стабильные ветки 13 августа, добавлял защиту от underflow в SubBalance. Pull request 1187, объединённый 20 мая, сохранял снимок locked-баланса, чтобы после работы precompile корректно восстановить банковский остаток.
Третье связанное изменение содержится в коммите 3524ebc с малоговорящим названием «Merge commit from fork». Оно запрещает устанавливать баланс module account, но делает это безусловно, из-за чего ломаются EVM-вызовы от имени такого аккаунта. В уведомлении Cosmos Labs прямо описан только 1176; 1187 и 3524ebc там не названы, хотя операторам нужно применять snapshot locked-баланса и защиту module account отдельно от underflow guard. В примечаниях к v0.6.2 и v0.7.2 говорилось о важных исправлениях безопасности и необходимости срочно обновиться, но сами security-backport и связанные pull request в changelog не попали. 29 августа The Hacker News подтвердило отсутствие этих ссылок в обоих описаниях релизов.
Для форков простого cherry-pick недостаточно. В кодовой базе может остаться дубликат неэкспортируемой helper-функции, через который реально идут транзакции, тогда как upstream-патч меняет лишь экспортируемый helper. Тесты при этом способны пройти без ошибок. Такой случай обнаружил участник ZetaChain morde08: 21 августа он опубликовал перенос всех трёх исправлений и предупредил, что ранее выбранный патч не затронул живой путь исполнения из-за дублирующих unexported helpers. Проверять приходится не наличие коммита, а фактический call path конкретного форка.
Warden Protocol выбрал дополнительную меру: полностью запретил свободное создание vesting-аккаунтов. Изменение участника jlehtimaki появилось 23 августа, через два дня после порта ZetaChain. В сообщении к коммиту решение объяснялось так: «Vesting-аккаунты — единственный источник заблокированных балансов в Warden, и ничто не зависит от возможности пользователей создавать их, поэтому удаление этого пути закрывает необходимое условие атаки, вместо того чтобы полагаться на правильность восстановления баланса». Это снимает конкретную предпосылку эксплуатации, хотя не отменяет обновление уязвимого кода.
Порядок раскрытия дал атакующим удобное окно. Исправленные версии вышли 19 августа. Уже 20 августа в 07:16 UTC публичный pull request в форке Cosmos EVM проекта Push Chain подробно описал дефект, условия и весь путь эксплуатации. Между релизом и публикацией прошло восемь часов пятнадцать минут. В 19:06 UTC, спустя ещё одиннадцать часов пятьдесят минут, началась первая известная атака на MANTRA. Первое закрытое уведомление Cosmos Labs по защищённой электронной почте ушло лишь 21 августа в 03:36 UTC, примерно через два часа после сообщения MANTRA о взломе. 28 августа Cosmos Labs опубликовала post-mortem.
Cosmos Labs продолжила процедуру silent patch даже после подтверждения 13 августа, что под угрозой каждая сеть Cosmos EVM. Объяснение было таким: «На этом этапе для уязвимости, которая, как известно, угрожает пользовательским средствам в рабочих сетях, команда обычно использовала бы защищённые каналы, чтобы в частном порядке передать патч затронутым сетям. Поскольку патч уже находился в открытом доступе в основной ветке и известных случаев эксплуатации не было, команда решила, что продолжать процедуру тихого исправления безопасно». Компания также сообщила: «За последние 13 месяцев Cosmos Labs без публичного раскрытия выпустила исправления для 37 уязвимостей, и разработчики нижестоящих проектов ни разу не описали публично точные пути эксплуатации».
Эта логика расходилась с опубликованной политикой bug bounty и silent patch, последняя синхронизация которой датирована 27 июля: «Когда проблема создаёт немедленный риск или риск для всей сети, Cosmos Labs начнёт экстренное снижение угрозы, частное распространение исправления либо согласованное обновление до любого публичного раскрытия». Здесь универсальная уязвимость была подтверждена 13 августа, релизы опубликованы 19 августа, подробности появились в Push Chain 20 августа, а защищённая рассылка началась после атаки. Ситуацию осложнило отсутствие полного реестра: в экосистеме Cosmos насчитывается более 115 известных публичных блокчейнов, но Cosmos Labs не знает всех сетей, использующих её ПО. Во время инцидента обнаружились одиннадцать развёртываний Cosmos EVM, прежде не зарегистрированных в каналах безопасности. Похожая проблема уже вынуждала поставщиков нижестоящих сборок исправлять включённые в них уязвимости файловой системы в июле. Операторам теперь рекомендовано зарегистрировать в Cosmos Labs защищённый контакт.
The Hacker News запросило у Cosmos Labs объяснение, почему после 13 августа патч не распространили приватно среди всех известных операторов. Ответа на этот конкретный вопрос по состоянию на 29 августа в публикации не было. В практическом плане у операторов остаётся короткий набор действий: перейти минимум на v0.6.2 либо v0.7.2, согласовать state-breaking upgrade, проверить именно живой путь кода форка, отдельно учесть 1187 и 3524ebc, перекрыть создание vesting-аккаунтов там, где оно не требуется, и остановить выпуск блоков, если немедленное обновление невозможно.[/assistant]
Ошибка зарегистрирована как GHSA-7g4w-cg88-2cq2 и получила от Cosmos Labs уровень Critical. При этом в уведомлении нет идентификатора CVE, формальной категории слабости и оценки CVSS. Уязвимы версии ниже v0.6.2, а также ветка от v0.7.0 до v0.7.2, не включая последнюю: < 0.6.2 и >= 0.7.0 < 0.7.2. Исправления вошли в v0.6.2 и v0.7.2, выпущенные 19 августа 2026 года, и во все последующие релизы с этими изменениями. Патч ломает совместимость состояния, поэтому обычного обновления узла мало: требуется согласованный переход всей сети. Если провести его сразу нельзя, инструкция предписывает остановить цепочку и выпуск блоков. Формула предельно жёсткая: «Остановить, а не голосовать». Управленческое голосование или governance-upgrade не считаются способом снять немедленную угрозу.
Сообщение поступило в bug bounty Cosmos Labs 25 апреля. Первая оценка оказалась неверной: средства действующих сетей сочли защищёнными, а ошибку связали лишь с конфигурациями, где используется не 18 десятичных знаков. В разборе инцидента команда признала: «Мы не смогли воспроизвести уязвимость в сетях с 18 десятичными знаками и ошибочно заключили, что она затрагивает только сети с иным количеством десятичных знаков». Лишь 13 августа Cosmos Labs установила, что уязвимы все цепочки Cosmos EVM независимо от настройки decimals. К тому времени с первого сообщения прошло больше трёх месяцев.
Причина находилась на стыке EVM StateDB и модуля Cosmos SDK x/bank. StateDB видит только доступный для расходования баланс, тогда как vesting-аккаунт Cosmos SDK хранит доступную и заблокированную части. Делегировать заблокированные средства разрешают и x/staking, и staking precompile. Аккаунт мог делегировать сумму больше доступного остатка, поскольку в делегации участвовали locked-средства. После вызова precompile код вычитал всю делегированную сумму из меньшего spendable-баланса без проверки underflow. Число зацикливалось в пространстве uint256 и превращалось в величину около 2²⁵⁶. Механизм сверки затем чеканил монеты при положительной разнице и сжигал их при отрицательной.
Из этой арифметики следовали два сценария. В первом атакующий выводил конечную сумму из аккаунта, чей баланс после переполнения приблизился к 2²⁵⁶. Во втором жертве отправляли 2²⁵⁶ минус её настоящий баланс, после чего сверка уничтожала реальные средства жертвы. Обе части выполнялись в одной транзакции с нулевым итоговым изменением предложения. Для атаки применялся контракт по заранее вычисленному адресу; этот адрес предварительно превращали в vesting-аккаунт. Поэтому обязательным условием служило свободное создание таких аккаунтов. Оператор может перекрыть путь, запретив в ante handler сообщения MsgCreateVestingAccount, MsgCreatePermanentLockedAccount и MsgCreatePeriodicVestingAccount. На vesting-аккаунты, внесённые в genesis, такой фильтр не действует. Отключение staking precompile убирает основной триггер, но не заменяет установку патча; одной настройки, полностью устраняющей дефект, нет.
В ветках Cosmos EVM последствия различались. В 0.6.x чеканка и сжигание проходили в базовом реестре Cosmos SDK, поэтому огромная эмиссия вызывала переполнение общего предложения и могла остановить цепочку. В 0.7.x баланс записывался прямо в x/bank]; система принимала изменения, пережившие преобразование uint256 в int256. Исправление состояло не в одной строке. Pull request 1176, объединённый 15 мая и перенесённый в стабильные ветки 13 августа, добавлял защиту от underflow в SubBalance. Pull request 1187, объединённый 20 мая, сохранял снимок locked-баланса, чтобы после работы precompile корректно восстановить банковский остаток.
Третье связанное изменение содержится в коммите 3524ebc с малоговорящим названием «Merge commit from fork». Оно запрещает устанавливать баланс module account, но делает это безусловно, из-за чего ломаются EVM-вызовы от имени такого аккаунта. В уведомлении Cosmos Labs прямо описан только 1176; 1187 и 3524ebc там не названы, хотя операторам нужно применять snapshot locked-баланса и защиту module account отдельно от underflow guard. В примечаниях к v0.6.2 и v0.7.2 говорилось о важных исправлениях безопасности и необходимости срочно обновиться, но сами security-backport и связанные pull request в changelog не попали. 29 августа The Hacker News подтвердило отсутствие этих ссылок в обоих описаниях релизов.
Для форков простого cherry-pick недостаточно. В кодовой базе может остаться дубликат неэкспортируемой helper-функции, через который реально идут транзакции, тогда как upstream-патч меняет лишь экспортируемый helper. Тесты при этом способны пройти без ошибок. Такой случай обнаружил участник ZetaChain morde08: 21 августа он опубликовал перенос всех трёх исправлений и предупредил, что ранее выбранный патч не затронул живой путь исполнения из-за дублирующих unexported helpers. Проверять приходится не наличие коммита, а фактический call path конкретного форка.
Warden Protocol выбрал дополнительную меру: полностью запретил свободное создание vesting-аккаунтов. Изменение участника jlehtimaki появилось 23 августа, через два дня после порта ZetaChain. В сообщении к коммиту решение объяснялось так: «Vesting-аккаунты — единственный источник заблокированных балансов в Warden, и ничто не зависит от возможности пользователей создавать их, поэтому удаление этого пути закрывает необходимое условие атаки, вместо того чтобы полагаться на правильность восстановления баланса». Это снимает конкретную предпосылку эксплуатации, хотя не отменяет обновление уязвимого кода.
Порядок раскрытия дал атакующим удобное окно. Исправленные версии вышли 19 августа. Уже 20 августа в 07:16 UTC публичный pull request в форке Cosmos EVM проекта Push Chain подробно описал дефект, условия и весь путь эксплуатации. Между релизом и публикацией прошло восемь часов пятнадцать минут. В 19:06 UTC, спустя ещё одиннадцать часов пятьдесят минут, началась первая известная атака на MANTRA. Первое закрытое уведомление Cosmos Labs по защищённой электронной почте ушло лишь 21 августа в 03:36 UTC, примерно через два часа после сообщения MANTRA о взломе. 28 августа Cosmos Labs опубликовала post-mortem.
Cosmos Labs продолжила процедуру silent patch даже после подтверждения 13 августа, что под угрозой каждая сеть Cosmos EVM. Объяснение было таким: «На этом этапе для уязвимости, которая, как известно, угрожает пользовательским средствам в рабочих сетях, команда обычно использовала бы защищённые каналы, чтобы в частном порядке передать патч затронутым сетям. Поскольку патч уже находился в открытом доступе в основной ветке и известных случаев эксплуатации не было, команда решила, что продолжать процедуру тихого исправления безопасно». Компания также сообщила: «За последние 13 месяцев Cosmos Labs без публичного раскрытия выпустила исправления для 37 уязвимостей, и разработчики нижестоящих проектов ни разу не описали публично точные пути эксплуатации».
Эта логика расходилась с опубликованной политикой bug bounty и silent patch, последняя синхронизация которой датирована 27 июля: «Когда проблема создаёт немедленный риск или риск для всей сети, Cosmos Labs начнёт экстренное снижение угрозы, частное распространение исправления либо согласованное обновление до любого публичного раскрытия». Здесь универсальная уязвимость была подтверждена 13 августа, релизы опубликованы 19 августа, подробности появились в Push Chain 20 августа, а защищённая рассылка началась после атаки. Ситуацию осложнило отсутствие полного реестра: в экосистеме Cosmos насчитывается более 115 известных публичных блокчейнов, но Cosmos Labs не знает всех сетей, использующих её ПО. Во время инцидента обнаружились одиннадцать развёртываний Cosmos EVM, прежде не зарегистрированных в каналах безопасности. Похожая проблема уже вынуждала поставщиков нижестоящих сборок исправлять включённые в них уязвимости файловой системы в июле. Операторам теперь рекомендовано зарегистрировать в Cosmos Labs защищённый контакт.
The Hacker News запросило у Cosmos Labs объяснение, почему после 13 августа патч не распространили приватно среди всех известных операторов. Ответа на этот конкретный вопрос по состоянию на 29 августа в публикации не было. В практическом плане у операторов остаётся короткий набор действий: перейти минимум на v0.6.2 либо v0.7.2, согласовать state-breaking upgrade, проверить именно живой путь кода форка, отдельно учесть 1187 и 3524ebc, перекрыть создание vesting-аккаунтов там, где оно не требуется, и остановить выпуск блоков, если немедленное обновление невозможно.[/assistant]