В криптовалютах есть почти священная формула: "Don't trust, verify". Не доверяй — проверяй. Каждый пользователь может сам запустить узел, сам проверять правила сети и не зависеть ни от команды разработчиков, ни от позиции .
Но у этой формулы есть серьёзное ограничение. Как бы я ни проверял код, я не найду уязвимость, для обнаружения которой нужно быть настоящим хакером. У меня просто не хватит знаний для этого. И я всё равно вынужден доверять: доверять тем, кто проверит всё вместо меня и расскажет мне об обнаруженных уязвимостях.
5 мая 2026 года разработчики Bitcoin Core раскрыли уязвимость CVE-2024-52911. Она затрагивала версии Bitcoin Core начиная с 0.14.0 и была исправлена в 29.0. Её суть была в том, что майнер мог удалённо остановить чужие узлы.
Но самое интересное здесь — в том, как долго об этой ошибке было известно. Кори Филдс приватно сообщил разработчикам о баге 2 ноября 2024 года. Уже 6 ноября 2024 года Питер Вюлле внёс скрытое исправление. 3 декабря 2024 года патч попал в официальный репозиторий без публичных объявлений об этом (он был назван "незначительными обновлениями"). 12 апреля 2025 года вышел Bitcoin Core 29.0 с исправлением. А публично о проблеме рассказали только 5 мая 2026 года, после того как последняя уязвимая ветка 28.x дошла до конца поддержки.
Полтора года клиент для Биткоина, считающийся самым надёжным, работал с уязвимостью, о которой знали разработчики, но не знали владельцы узлов, использовавшие этот клиент на своих компьютерах. И это не исключение, а традиционная история для криптовалют. Разработчики разных криптовалютных проектов поступают так уже много лет.
В этой статье я хочу рассказать о других подобных примерах, чтобы в итоге ответить на вопрос: так ли безопасно хранить сбережения в криптовалютах.
Биткоин: как DoS оказался инфляционным багом
В сентябре 2018 года Bitcoin Core выпустил срочное обновление 0.16.3. Пользователям сказали, что оно закрывает DoS-уязвимость.
Через два дня выяснилось, что это была только половина истории. Та же ошибка в версиях 0.15.x и 0.16.x могла позволить майнеру раздуть предложение биткоина: фактически потратить один и тот же выход внутри блока дважды и получить лишние BTC. Разработчики признали, что сначала раскрыли только менее опасную DoS-часть, а полное описание инфляционной угрозы задержали, чтобы майнеры, бизнесы и другие важные участники успели обновиться.
В худшем сценарии это был бы удар не по кошельку отдельного пользователя, а по главному обещанию Биткоина — ограниченной эмиссии. Если правило "21 миллион" можно обойти ошибкой в клиенте, то вся экономическая легенда Биткоина оказывается пшиком.
Насколько мне известно, уязвимость не была использована. Но случай CVE-2018-17144 хорошо показывает этическую дилемму. С одной стороны, полное раскрытие сразу могло дать злоумышленникам инструкцию. С другой — пользователям фактически сообщили не всю правду о критичности обновления.
Zcash: невидимые фальшивые монеты
В Zcash история была ещё тревожнее, потому что речь шла о приватной криптовалюте, в которой далеко не всё можно увидеть в блокчейне. В 2018 году команда обнаружила уязвимость в криптографии zero-knowledge proofs. До исправления атакующий мог создавать фальшивые ZEC так, что это никому не было бы видно. Для обычной прозрачной сети инфляционный баг хотя бы теоретически можно заметить по балансу, а приватная система усложняет такую проверку.
Zcash исправил проблему в обновлении Sapling, активированном 28 октября 2018 года, а публично рассказал о ней только спустя месяцы. В официальном раскрытии команда прямо написала: "одиннадцать месяцев назад мы обнаружили уязвимость", а также признала, что до исправления атакующий мог создавать фальшивые Zcash без обнаружения.
Здесь молчание было особенно понятным. Раскрыть такую дыру до исправления означало бы подарить кому-то рецепт уничтожения монеты. Но и обратная сторона очевидна: пользователи почти год владели активом, в котором теоретически могла идти скрытая подделка монет, и не знали об этом.
И вот парадокс:
- чем серьёзнее уязвимость, тем сильнее аргумент в пользу секретности;
- но чем больше секретность, тем сильнее удар по идее проверяемости. (Какой смысл в проверках, если сам я ничего не пойму, а квалифицированные проверяющие мне ни о чём не расскажут?)
Monero: как правду спрятали под несуществующим DoS
Monero в 2017 году столкнулась с похожей угрозой, но отреагировал ещё более театрально. Команда обнаружила критический баг в CryptoNote — базовом протоколе, на котором работали Monero и ряд других приватных монет. Уязвимость позволяла создавать неограниченное количество монет способом, который невозможно было бы заметить обычному наблюдателю, если он не знает, где искать.
Патч в Monero внесли скрытно. Более того, релиз объяснили как защиту от RingCT DoS-атаки, которой, по собственному последующему признанию команды, на самом деле не существовало. Это была легенда, нужная для того, чтобы заставить биржи и майнинг-пулы обновиться, не раскрывая реальный инфляционный риск.
Для самого Monero история закончилась удачно: команда заявила, что проверила блокчейн и не нашла следов эксплуатации. Но уязвимость затрагивала не только Monero. После того как Monero обновился, команда начала уведомлять другие CryptoNote-проекты. Один из таких проектов, Bytecoin, вскоре подвергся атаке, и в нём было создано 693 млн дополнительных монет.
И вот новая проблема, заставляющая скрывать уязвимости. Когда код переиспользуют десятки проектов, объявление о найденной угрозе в одном месте может стать подсказкой для атаки в другом. Разработчикам приходится решать не только когда рассказать своим пользователям, но и кого из конкурентов предупредить, и в каком порядке. Ведь конкурент, предупреждённый первым, может провести атаку на конкурента, который ещё не получил информацию.
Снова Monero: баг, который позволял сжигать чужие монеты
В 2018 году у Monero был другой, менее фундаментальный, но очень показательный случай — так называемый burning bug. Он не позволял печатать XMR из воздуха и не ломал эмиссию. Зато злоумышленник мог нанести ущерб биржам, продавцам и другим сервисам. Баг давал возможность отправить средства так, что часть полученных выходов становилась непригодной к трате.
От такого бага мог бы пострадать и наш обменный сервис. Ведь как происходят обмены криптовалют на rabbit.io:
- вы отправляете криптовалюту (например, XMR) на адрес, который видите на странице заявки на вашем сайте,
- наша автоматизированная система видит поступление нужной суммы на этот адрес,
- и автоматически отправляет вам другую криптовалюту на тот адрес, который вы указали в заявке.
Нашего сервиса в то время ещё не было, но если бы он был, то атака могла бы произойти так:
- злоумышленник создаёт заявку по обмену XMR на, скажем, BTC;
- он отправляет нам XMR и получает BTC;
- мы остаёмся и без BTC, и без XMR (ведь мы не можем использовать полученные монеты);
- злоумышленник сам ничего не теряет и не приобретает, но разоряет нас и всех остальных, кто принимает XMR.
Команда Monero подготовила приватный патч и уведомляла напрямую биржи и известных мерчантов, принимающих XMR. В постмортеме разработчики честно признали, что этот метод оповещения неизбежно исключает организации, с которыми у команды нет контакта, и создаёт ощущение привилегированного доступа к информации.
Это практический пример того, что неизбежно появятся участники рынка, которые узнают о риске раньше других. И это дополнительная угроза безопасности при избирательном распространении информации.
Stellar: утаённый баг, который уже был использован
История Stellar отличается от многих других тем, что баг не просто существовал, и никто, кроме разработчиков, о нём не знал. Его реально использовали.
В 2017 году атакующий воспользовался ошибкой параллелизма в протоколе Stellar и создал 2,25 млрд XLM — примерно на $10 млн по тогдашнему курсу и около четверти всех выпущенных монет на тот момент. По данным Messari, созданные XLM были переведены на биржи и, вероятно, проданы.
Stellar Development Foundation позже сожгла эквивалентное количество XLM из собственных запасов, чтобы не размывать эмиссию. Но публично об этом не рассказывали, пока в 2019 году на это не обратила внимание Messari. В ответе Messari представители Stellar говорили, что упоминали баг в заметках к релизу обновлений протокола. Формально это не полное молчание. Но тихая запись в технических примечаниях, о которой рынок не узнал до расследования Messari два года спустя.
Этот кейс особенно неприятен для индустрии. Здесь нельзя сказать: "Мы скрывали дыру, чтобы никто не успел ею воспользоваться". Ею уже воспользовались. Молчание защищало не пользователей от атаки, а, скорее, разработчиков от критики.
Ethereum Geth: как тихий патч расколол сеть
У Geth, самого популярного клиента Ethereum, практика "тихих патчей" была фактически нормализована. В документации команда прямо пишет, что для уязвимостей, которые угрожают работоспособности основной сети Ethereum, она оставляет за собой право тихо выпускать исправления в новых релизах, ничего не сообщая о самих уязвимостях. Объяснение понятное: владельцы узлов могут не обновлять их неделями или месяцами, и если прямо сказать, какую ошибку исправляет релиз, то кто-то может попытаться атаковать сеть быстрее, чем большинство успеет обновить свои узлы.
Но в августе 2021 года эта логика дала сбой. В Geth была исправлена уязвимость CVE-2021-39137. Релиз с патчем вышел 24 августа, но детали не были разглашены. Однако кто-то из хакеров понял, в чём дело, и 27 августа уязвимость была использована, в результате чего часть старых Geth-узлов откололась от основной цепи.
Это обратная сторона секретности. Если сказать слишком много, можно ускорить атаку. Если сказать слишком мало, часть операторов не поймёт, что обновление критически важно. В итоге сеть может получить именно то, чего пыталась избежать: эксплуатацию уязвимостей.
Polygon: $24 млрд под угрозой и реальные потери
В декабре 2021 года похожая дилемма возникла у Polygon. Исследователи безопасности сообщили о критической уязвимости в genesis-контракте Polygon PoS, позволяющей злоумышленнику украсть токены MATIC на общую сумму около $24 млрд. Команда решила провести обновление без лишнего шума: по её словам, "учитывая природу этого апгрейда, его нужно было выполнить, не привлекая слишком много внимания". Валидаторы и владельцы полных узлов были уведомлены, и сеть быстро обновилась.
Но даже быстрая реакция не успела полностью закрыть окно атаки. До вступления обновления в силу злоумышленник смог украсть 801 601 MATIC (чуть менее $2 млн). Разработчики сообщили, что фонд Polygon возьмёт этот ущерб на себя, а исследователям, рассказавшим об уязвимости, выплатили около $3,46 млн вознаграждения.
Команда не стала скрывать проблему, но пользователи узнали о масштабе риска уже после того, как всё произошло. Основных причин было две: во-первых, нужно было действовать, а не разглагольствовать; во-вторых, до полного решения проблемы каждый новый обладатель информации о ней мог злоупотребить этой информацией.
Возможно, именно так и должен выглядеть компромисс: не раскрывать атаку до патча, но и не превращать исправление в секрет на месяцы или годы.
Так разработчики защищают пользователей или обманывают их?
Иногда секретность действительно спасает сеть. Без тихого исправления Zcash мог получить невидимую инфляцию. Без скрытого патча Monero мог столкнуться с подделкой монет. Без быстрых закрытых действий ущерб для сети Polygon мог быть несравнимо больше.
Но секретность не бесплатна. Она создаёт классы посвящённых и непосвящённых. Она даёт привилегию тем, кого команда успела предупредить лично. Она снижает мотивацию владельцев узлов обновляться, если релиз выглядит как обычное техническое обслуживание. И она подрывает важное психологическое преимущество использования криптовалют — ощущение, что правила игры известны всем одновременно.
Да, это ощущение действительно ложное. Каждая такая история повторяет один и тот же сюжет: сначала тихий патч, потом долгое молчание, потом признание, что всё это время безопасность сети держалась на доверии к маленькой группе людей, которые знали больше остальных.
