В кошельке Vultisig без сид-фразы нашли опасную ошибку: как мог раскрыться приватный ключ

21 октября 2026 года компания ChainSecurity опубликовала исследование критической ошибки в реализации пороговых подписей MPC-кошелька Vultisig. При определённом сценарии злоумышленник, уже контролирующий одного участника подписи, мог постепенно получить секретные данные другого участника и восстановить полный приватный ключ. Разработчики внесли изменения в код, но независимого заключения ChainSecurity о безопасности исправлений пока нет. В опубликованном исследовании также нет подтверждений массовой кражи средств пользователей через эту ошибку.

История выглядит парадоксально. Vultisig позиционируется как криптокошелёк без привычной сид-фразы: для отправки Bitcoin и Ethereum используются несколько долей секрета, а полный ключ не должен собираться в одном устройстве в ходе обычной подписи. Однако математически стойкая схема не спасает автоматически, если приложение неверно обрабатывает критические сигналы криптографической библиотеки. Разберём, где возник риск, кому следует обратить внимание на обновления и почему простое пересоздание долей не всегда решает проблему безопасности.

Что обнаружила ChainSecurity 21 октября 2026 года

В оригинальном исследовании ChainSecurity под названием Please Try Again: Stealing Keys from MPC Wallets via Selective Abort Attacks описан класс ошибок, при котором недобросовестный участник совместного подписания может извлекать информацию о секрете другого. Авторы изучали реализации MPC, создающие подписи ECDSA. Такой тип подписи используется, в частности, при работе с Bitcoin и Ethereum.

Исследователи сообщили, что выявили проблемы в нескольких реализациях MPC-кошельков, а подробный публичный разбор посвятили Vultisig. Команда проекта получила уведомление и изменила затронутый код. Это пример ответственного раскрытия: сначала разработчикам дают возможность отреагировать, затем рассказывают об ошибке публично.

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

Что такое MPC-кошелёк и почему ему не нужна обычная сид-фраза

MPC расшифровывается как multi-party computation - многосторонние вычисления. В обычном личном криптокошельке исходная секретная информация часто восстанавливается из двенадцати или двадцати четырёх слов. В Vultisig применяется другая модель: участники хранят доли криптографического секрета и выполняют совместный протокол, результатом которого становится одна действительная подпись для блокчейна.

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

Разница между секретом, публичным ключом и адресом подробно раскрыта в материале BarbadosNews «Приватный и публичный ключ криптокошелька». Важнейшее здесь: монеты не лежат в телефоне, а распределение долей меняет способ доказать право на распоряжение ими.

Словосочетание «без сид-фразы» тоже нельзя понимать буквально как «вообще нет секретных данных». У MPC-кошелька есть резервные файлы долей (vault shares), которые нужно защищать не менее ответственно, чем резервные слова обычного кошелька. К тому же Vultisig поддерживает импорт существующих кошельков из сид-фразы. Сравнить подходы можно с руководством о хранении сид-фразы, но переносить методы восстановления один к одному нельзя. Если вы только знакомитесь с самостоятельным хранением, сначала изучите как создать криптокошелёк и не начинайте с больших сумм.

Как уязвимость могла обойти защиту нескольких устройств

Идея MPC - недобросовестному участнику должно быть недостаточно его собственной доли, даже если он участвует в протоколе подписи. В описанном ChainSecurity сценарии это ожидание нарушалось. Атакующий уже должен был контролировать одного из подписантов; публикация не доказывает, что любой посторонний сайт мог узнать ключ, просто открыв страницу или увидев публичный адрес.

В исследованной реализации для ускорения дальнейших подписей применялось вспомогательное секретное значение протокола, которое авторы называют seed. Его не следует путать с пользовательской сид-фразой из 12-24 слов. В нормальном режиме такое значение скрыто. Но некоторые специально сформированные сообщения в протоколе способны вызывать критическую ошибку, факт появления которой зависит от скрытой информации. Если после такого сигнала продолжать новые попытки с теми же чувствительными данными, наблюдения могут постепенно раскрывать секрет.

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

ChainSecurity описывает цепочку последствий: утечка вспомогательного секрета другого участника могла позволить восстановить его долю, затем полный ключ, а после этого - создавать подписи уже без согласия второго устройства. Для пользователя это принципиальное отличие от обычного фишинга: в рассматриваемом сценарии проблема возникала в обработке внутреннего протокола подписания.

При этом обнаружение возможности атаки не означает, что она автоматически выполнилась на каждом кошельке или что само наличие двух телефонов уже было бесполезным. Риск зависел от конкретного кода, состояния участников и возможности повторять небезопасные сеансы.

Почему ошибка оказалась на стыке библиотеки и приложения

Самая ценная часть исследования - не сложная криптография, а разница между сигналом безопасности и реакцией пользовательского приложения. Библиотека MPC возвращала критическое указание по смыслу «прекратить протокол и заблокировать участника» (abort protocol and ban party). Предполагалось, что программа не станет просто повторять процесс, а остановит опасное взаимодействие до выполнения защитных действий.

Однако на уровне приложения Vultisig критическая ошибка могла преобразовываться в обычное сообщение для пользователя. Новая попытка подписи оставалась возможной, то есть предположение, на котором строилась безопасность библиотеки, переставало выполняться. Библиотека сама по себе не способна гарантировать правильное поведение вызывающей программы: она сообщает о событии, а конечный продукт решает, как на него реагировать.

Здесь важно понимать границу ответственности. Аудит математической реализации не обязательно охватывает весь путь от внутреннего сообщения до экранной кнопки «Попробовать ещё раз». Открытый исходный код и прошлые аудиты - полезные доказательства работы над безопасностью, но не гарантия отсутствия ошибок при интеграции. В разделе безопасности Vultisig опубликованы сведения об аудитах отдельных криптографических компонентов, однако независимое заключение о конкретном исправлении у ChainSecurity отсутствует.

Почему «попробовать ещё раз» не всегда безобидно

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

Что изменили разработчики и что по-прежнему неизвестно

В публичной статье ChainSecurity говорится, что после уведомления Vultisig внесла изменения в затронутый код. Дополнительное подтверждение направления исправления видно в истории выпусков Android-приложения и истории iOS-приложения: среди изменений встречается требование прекращать подпись после сигнала DKLS о вредоносном участнике, а не автоматически повторять её.

Однако эти записи не позволяют без дополнительной проверки назвать одну универсальную «безопасную версию» для всех устройств, типов хранилищ и способов установки. Версии Android, iOS, настольной программы и расширения различаются. Нельзя также утверждать, что конкретная запись changelog покрывает все выявленные в исследовании сценарии.

Сформулируем статус точно: разработчики заявили об исправлениях, публичные изменения в коде согласуются с описанным принципом защиты, но ChainSecurity не перепроверяла исправления и не проводила полный аудит остальных частей протокола. Это не основание считать кошелёк заведомо скомпрометированным, но и не повод представлять исследование как сертификат безопасности.

Какие владельцы Vultisig должны проверить приложение

Прежде всего - те, кто действительно пользуется Vultisig для хранения и подписания транзакций. Если у вас обычный Bitcoin-кошелёк другого производителя, исследование само по себе не означает уязвимость вашего приложения. Если вы используете другой MPC-продукт, нельзя переносить на него все выводы: требуются отдельные исследования и сведения о реализации.

Внутри Vultisig важно различать несколько конфигураций. По официальной документации, Fast Vault использует устройство владельца и серверный подписант VultiServer; Secure Vault предполагает несколько устройств, которыми управляет сам пользователь. Оба режима используют пороговую модель, но их операционные риски не идентичны.

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

Что делать владельцу кошелька сейчас: семь проверок

Ниже - осторожный алгоритм для обычного пользователя. Он не требует раскрывать ключи, запускать сомнительные диагностические программы или совершать срочный перевод по указанию незнакомца.

1. Установите, действительно ли вы используете Vultisig. Проверьте название приложения и платформу установки, не ориентируясь только на похожий значок. При необходимости начните с официального сайта Vultisig и переходите к источникам загрузки оттуда. Письмо или реклама «MPC-патча» не являются достаточным подтверждением подлинности.

2. Запишите текущую версию каждой участвующей программы. Для кошелька с несколькими устройствами проверьте каждое. Обновление одной стороны при старой версии другой может оставлять риски совместимости или прежнего поведения; точные требования нужно смотреть в официальных объявлениях для вашей платформы.

3. Прочитайте официальный changelog и раздел безопасности. Ищите объяснение изменений, связанных с остановкой подписи при критических ошибках, но не делайте вывод «исправлено всё» только по одному слову security. Если ситуация не ясна, обратитесь в официальную поддержку Vultisig, не передавая резервных файлов.

4. Проверьте резервные доли, не экспортируя их на чужой сайт. Убедитесь, что у вас есть необходимые зашифрованные копии и известны условия их восстановления. Не фотографируйте секреты и не пересылайте файлы в чаты. В руководстве по восстановлению криптокошелька объясняется общий принцип: наличие публичного адреса не заменяет резервные секретные данные.

5. Проверьте доверенность устройств. Не используйте для финансовых операций телефон с подозрительной удалённой программой, неустановленными обновлениями безопасности или неизвестными профилями управления. В MPC захват одного участника был необходимым условием описанной атаки, поэтому защита самих устройств остаётся важной.

6. Не повторяйте бесконечно подозрительную подпись. Если приложение показывает необычное сообщение о криптографической ошибке, незнакомом участнике или нераспознанном действии, остановитесь. Сохраните время, несекретный текст ошибки и версию программы для обращения в поддержку. Не передавайте vault shares, пароли или приватные ключи даже тому, кто представляется специалистом по безопасности.

7. При конкретных признаках компрометации составьте план с доверенным специалистом. Например, при необъяснимых подписью операциях, утрате контроля над одним из устройств или доказанной утечке доли кошелька. Безопасность переноса зависит от того, какие секреты могли стать известны и существует ли уже риск полного раскрытия ключа; произвольное пересоздание долей - не универсальный ответ.

Почему Reshare не равен созданию нового приватного ключа

Это особенно важный момент, который легко упустить после новости об утечке ключей. Vultisig поддерживает операцию Reshare - перераспределение долей между новым набором устройств без изменения адресов кошелька. Это удобно при потере устройства, смене участников или изменении порога. Но официальная инструкция Vault Reshare отдельно предупреждает: старые резервные доли могут оставаться работоспособными вместе со своим прежним набором.

Если потенциально раскрыт полный приватный ключ, изменение того, кто сейчас хранит новые доли, само по себе не меняет право подписи, связанное с прежним адресом. Старый секрет может продолжать контролировать средства. В такой ситуации может потребоваться совершенно новый кошелёк с новой криптографической основой и безопасный перенос активов, но конкретный план зависит от обстоятельств компрометации и подтверждённых инструкций разработчика.

Не путайте Reshare с обновлением старого протокола GG20 до DKLS23: документация Vault Upgrade описывает другую процедуру и также подчёркивает необходимость новых резервных копий. Пользователям не стоит самостоятельно экспериментировать с этими функциями ради «очистки» кошелька без ясного понимания последствий.

Почему нельзя советовать всем срочно переводить BTC и ETH

В исследовании есть потенциально критическая ошибка, но нет опубликованного списка похищенных адресов или доказательства эксплуатации против каждого пользователя. Поэтому массовый призыв немедленно вывести Bitcoin и Ethereum противоречил бы установленным фактам. Сам перевод создаёт риск неверной сети, подмены адреса, потери комиссии и попадания на поддельный «новый безопасный кошелёк».

Другое дело - установленная компрометация устройства или доли, подозрительные транзакции, известное несанкционированное участие в сеансах подписи. Здесь бездействие тоже рискованно. Прежде чем подписывать какие-либо операции, следует отдельно проверить новый адрес получателя на доверенном устройстве, состав доступных подписантов и официальный порядок реагирования.

Для крупных сумм полезно различать защиту от удаления приложения, от кражи резервной копии и от неправильного подписания. Аппаратное устройство, например, не делает операцию безопасной автоматически: важна подлинность и правильность проверки адреса. Эту часть раскрывает руководство «Как проверить Ledger Nano X на подлинность».

Чем MPC отличается от обычного мультисиг-кошелька

Слова «MPC» и «мультисиг» часто ставят рядом, поскольку обе схемы распределяют контроль. Но техническая разница существенна. В обычном on-chain мультисиге отдельные участники могут выпускать собственные подписи, а блокчейн или смарт-контракт проверяет, достигнут ли заданный порог. В MPC несколько участников совместно создают одну подпись, которая в ряде сетей выглядит как обычная подпись одного кошелька.

У Bitcoin мультисиг может опираться на специальное условие расходования, а в Ethereum - на кошелёк-смарт-контракт с несколькими владельцами. MPC-подпись может не требовать такого особого условия в самой сети, но предъявляет более сложные требования к процедуре совместных вычислений. Это обмен: меньше специальных правил на блокчейне, больше криптографической сложности внутри приложения.

У нас уже есть отдельный материал «Мультисиг-кошелёк: как работает защита 2 из 3». Здесь не станем повторять все варианты настройки: урок случая Vultisig именно в том, что безопасность MPC зависит от программного поведения между получением сообщения и завершением подписи.

Почему проблема с ECDSA не означает уязвимость всего Bitcoin

Bitcoin и Ethereum проверяют действительность представленных им подписей. Описанная атака направлена против конкретного механизма получения секретных данных в MPC-кошельке, а не против математической возможности вычислить приватный ключ по публичному адресу. Поэтому выражение «взломали Bitcoin» искажает факт. Наличие других защищённых алгоритмов и кошельков не отменяется ошибкой одной реализации.

Почему уязвимость нельзя считать обычным фишингом

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

Какие признаки указывают на срочную проблему

Сам по себе отказ подписи ещё не является доказательством атаки. Сеть может не отвечать, устройство - быть офлайн, а пользователь - отменить операцию. Но серьёзного внимания требуют неизвестные операции в истории, подтверждение транзакций без вашего согласия, подозрительный удалённый доступ к одному из устройств и повторяющиеся сообщения о вредоносном участнике. Эти случаи нельзя списывать на «типичный баг» без проверки.

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

Не стоит путать утечку ключа с разрешениями токенов. В Ethereum самостоятельный риск создают allowance, которые пользователь ранее выдал смарт-контракту. Отзыв таких разрешений может ограничить контракт, но не исправит раскрытый приватный ключ. Этот отдельный механизм объяснён в руководстве «Как отозвать разрешения смарт-контрактов».

Что делать, если резервная доля потеряна или устройство повреждено

Сначала определите, какая именно доля недоступна и сохранился ли необходимый порог доверенных подписантов. Для Secure Vault 2 из 3 потеря одного устройства может не лишить доступа, если два оставшихся работают; в Fast Vault сценарий зависит от пользовательской и серверной долей и резервных копий. Подробные ограничения описаны в официальных инструкциях Vultisig по восстановлению и обслуживанию хранилищ.

Не пытайтесь «проверить» свои доли в случайном онлайн-декодере: пороговый набор секретов сам по себе способен дать контроль над средствами. Даже официальные аварийные инструменты, собирающие полный приватный ключ, меняют модель безопасности; разработчик рекомендует применять их только при действительной необходимости. Для обычной диагностики версий они не нужны.

Сотрудник поддержки может помочь понять порядок действий и восстановить сведения об ошибке, но не должен получать ваши доли в чате. Если уже действуете в аварийной ситуации, зафиксируйте рекомендации из официальных каналов и проверьте их до первой необратимой транзакции. Подмена адреса при «спасении средств» - отдельный распространённый риск.

Могут ли мошенники использовать новость об уязвимости

Да. Публичное сообщение о потенциальной потере ключа создаёт удобный повод для фальшивых «обновлений безопасности», доменов с похожим названием проекта и предложений перевести монеты на «карантинный» адрес. Особенно опасны страницы, которые обещают автоматически проверить, атакован ли ваш vault, и для этого требуют загрузить .vult-файл либо ввести пароль резервной копии.

Безопасная проверка проводится через официальное приложение, достоверную историю релизов и подтверждённые каналы поддержки. Никакая новость не делает стороннюю форму с секретными данными обязательной. Если сайт требует объединить все доли «для установки патча», остановитесь: обычное обновление пользовательского приложения не должно начинаться с передачи кому-либо полного набора секретов.

Частые вопросы о Vultisig и безопасности MPC

Значит ли это, что все кошельки Vultisig взломаны?

Нет. Исследование описывает потенциальную возможность компрометации при определённой модели угроз. В публичном материале ChainSecurity не заявлена массовая кража пользовательских активов через этот сценарий. Проверить свою версию и безопасность устройств разумно, объявлять каждый vault украденным - нет.

Можно ли получить приватный ключ, имея только одну долю?

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

Влияет ли ошибка на BTC и ETH одинаково?

В фокусе исследования - MPC-получение подписей ECDSA, применяемых при работе с этими сетями. Однако нельзя автоматически распространять все технические выводы на каждый поддерживаемый Vultisig блокчейн или иную схему подписи. Важны конкретный протокол и реализация.

Какую версию Vultisig можно назвать полностью безопасной?

По доступным первоисточникам нельзя добросовестно назвать одну универсальную версию для всех платформ с гарантией полного устранения всех рисков. Нужно использовать официальные поддерживаемые сборки и отслеживать сведения разработчиков, учитывая отсутствие независимой перепроверки ChainSecurity.

Достаточно ли сделать Reshare после возможной утечки?

Нет, если опасение связано с возможным раскрытием полного приватного ключа. По документации Vultisig прежние доли способны оставаться действительными в старой группе, а сам адрес после Reshare не меняется. При доказанной компрометации ключа требуется оценка необходимости нового адреса и безопасного переноса, а не механическое нажатие одной кнопки.

MPC лучше обычного мультисига?

Нельзя назвать абсолютного победителя. MPC может создавать привычную подпись без специального on-chain кошелька, но повышает требования к безопасности межучастникового протокола. Классический мультисиг даёт прозрачные правила независимых подписей, но может быть дороже или сложнее в конкретной сети. Важна вся система, включая устройства, резервные копии и качество реализации.

Главное для владельцев криптовалют

История Vultisig показывает, что нельзя сводить безопасность к фразе «приватный ключ нигде не хранится целиком». Реальная защита состоит из математической модели, надёжных устройств, корректной интеграции библиотек, обработки ошибок и жизненного цикла резервных долей. Ошибка в одном из этих слоёв способна обойти преимущества остальных.

На 26 октября 2026 года разумный вывод не в том, чтобы панически выводить все BTC и ETH, а в том, чтобы использовать проверяемые обновления, знать тип собственного vault, контролировать участников подписи и иметь безопасные резервные копии. Если появились реальные признаки компрометации, действовать нужно адресно и с пониманием, что Reshare не всегда уничтожает прежние возможности подписания. Для общего изучения способов защиты и восстановления есть раздел BarbadosNews «Кошельки и безопасность».

Материал подготовлен 26 октября 2026 года по публичному исследованию ChainSecurity и документации Vultisig. Он не заменяет индивидуальную техническую экспертизу и не является рекомендацией переводить активы. Версии приложений, статус исправлений и процедуры восстановления могут изменяться.

Автор

Barbados