Поделиться

Ссылка скопирована

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

Обновление политики от 22 октября ускоряет процесс обработки таких ошибок. Разработчики планируют выпускать небольшие обновления для всех поддерживаемых основных версий как можно быстрее и публиковать уведомления о безопасности вместе с исправлениями. Для других уязвимостей сохраняется существующий график раскрытия информации. Ни одна конкретная новая уязвимость не была объявлена в связи с изменением политики, и отчет, сгенерированный искусственным интеллектом, автоматически не является реальной уязвимостью. Изменение касается времени между подтвержденным обнаружением, выпуском исправленной версии и публикацией подробной информации.

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

СРОЧНЫЕ НОВОСТИ: Основатель Avalanche предупреждает, что искусственный интеллект может украсть миллиарды долларов, используя уязвимости в программном обеспечении для криптовалют, прежде чем будет взломана ECDSA.

Эмин Гюн Сирер говорит, что уязвимости в кошельках, библиотеках и системном коде представляют более непосредственную угрозу, чем квантовые атаки на существующую криптографию, что делает программное обеспечение… изображение

— crypto.news (@cryptodotnews) 12 октября 2026

Новая политика разделяет обнаружение и серьезность

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

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

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

Для отчетов, попадающих в новую категорию, Bitcoin Core заявляет, что будет выпускать небольшие обновления с исправлениями для каждой поддерживаемой основной версии и одновременно публиковать уведомление. Фраза "как можно скорее" описывает намерение, а не фиксированное количество часов с момента получения первого отчета. Разработчикам все еще необходимо подтвердить наличие проблемы, написать и проверить исправление, протестировать его на каждой ветке и подготовить релизы. Политика не гарантирует, что неподдерживаемая версия получит исправление, или что все пользователи обновятся до появления уведомления.

Старый срок ограничения доступа может превысить несколько релизов

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

Примечение к выпуску версии 32.0 содержат конкретное сравнение. В них говорится, что три уязвимости средней или высокой степени серьезности, исправленные в версии 30.0, будут раскрыты через две недели после выхода новой версии, в то время как в версии 32.0 не было уязвимостей низкой степени серьезности, информация о которых должна была быть опубликована в тот же срок. Версия 30.0 была выпущена 10 октября 2025 года, согласно таблице жизненного цикла Bitcoin Core. Версия 32.0, согласно графику выпуска, была помечена как выпущенная 21 октября 2026 года. Между этими датами прошло 376 дней, что является арифметическим сравнением даты исправления старой версии и даты выпуска новой, а не даты, объявленной проектом для отдельного уведомления об уязвимости.

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

Предыдущий случай раскрытия информации демонстрирует этот подход на практике. Bitcoin Core раскрыл CVE-2024-52911 в мае 2026 года, после того как уязвимость уже была исправлена в версии 29.0, выпущенной в апреле 2025 года. Специально созданный блок мог вызвать ошибку "использование после освобождения" в интерпретаторе скриптов и привести к сбою уязвимых узлов. Создание блока с достаточным объемом вычислений делало атаку дорогостоящей, и проект считал, что удаленное выполнение кода маловероятно. Промежуток времени между исправлением и публикацией подробностей был частью предыдущего подхода к раскрытию информации; это не доказывает, что старая проблема соответствовала бы сегодняшним критериям легкой обнаружимости.

Три поддерживаемые версии определяют, кто получит исправление

В описании жизненного цикла программного обеспечения Bitcoin Core говорится, что разработчики поддерживают последние три основные версии. Когда выходит новая основная версия, самая старая из трех переходит в режим окончания поддержки и, как правило, перестает получать исправления безопасности. Поскольку версия 32.0 была помечена как выпущенная 21 октября, а в примечаниях к выпуску указано, что версии 29.x и более ранние перешли в режим окончания поддержки, ветки для нового быстрого пути – это 30.x, 31.x и 32.x. Выпуск обновления для каждой из этих веток позволит пользователю, работающему с версией 30.x, применить целевое исправление, не внедряя сразу все новые функции и изменения поведения, присутствующие в версии 32.0.

Цикл предварительной версии 32.0 начался 14 сентября, а стабильная версия была помечена 21 октября. Важно различать метку релиза, исполняемый файл и установленный узел. В расписании указана метка 32.0; официальное распространение и собственная установка оператором – это последующие этапы. На момент подготовки этого материала страница жизненного цикла все еще отображала дату выпуска 32.x как "TBA" (To Be Announced), несмотря на то, что в расписании выпуска была указана эта метка. В примечаниях к выпуску 32.0 говорится, что версии 29.x и более ранние достигли конца своего жизненного цикла. Bitcoin Core еще не обновила дату 32.x, отображаемую в таблице жизненного цикла.

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

Операторы, использующие ветки, отличные от трех основных, сталкиваются с другим решением. Версия 29.x может продолжать запускаться и проверять обычные блоки после окончания срока ее поддержки, но, как правило, она не будет получать новые обновления безопасности. Оператор, использующий эту версию, должен перейти на поддерживаемую ветку, чтобы получать будущие обновления. Bitcoin Core рекомендует использовать последнюю версию обслуживания самой новой основной версии, которую может использовать оператор. Компания, использующая собственные интеграции или данные кошельков, может нуждаться в собственных проверках совместимости, прежде чем совершить этот переход. Окончание срока поддержки описывает границы поддержки проекта, а не переключатель, который отключает старое программное обеспечение в определенный день.

Вам также может быть интересно: Cardano запускает тестовую сеть Dijkstra, пока узел 11.2 готовится к обновлению протокола

Страница жизненного цикла Bitcoin Core делает еще одно различие, которое может быть упущено в предупреждении о безопасности. Основная версия – это ветка, а дополнительная версия – это обновление обслуживания в этой ветке. Пользователь, использующий 30.0, и пользователь, использующий 30.3, оба используют 30.x, но они не обязательно установили одни и те же исправления. Если проект выпускает новую версию 30.x для устранения легко обнаруживаемой ошибки, простого указания того, что сервис работает в "версии 30", недостаточно для обеспечения защиты. Необходим полный номер версии и список исправлений, включенных в эту версию. Именно поэтому заявление компании о том, что она обновила свои узлы, не называя конкретной версии, оставляет главный вопрос без ответа.

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

Исправление может быть опубликовано до того, как большинство узлов его установят

Bitcoin Core не имеет центрального оператора, который мог бы принудительно установить обновление на все узлы. Пользователь, запускающий домашний узел, может загрузить обновление вскоре после получения уведомления. Хранитель или биржа может протестировать обновление на внутренних сервисах, системах кошельков и системах мониторинга, прежде чем обновлять производственные узлы. Майнинговый пул имеет свой набор требований к проверке и формированию блоков. Это лишь возможные сценарии, а не точный список того, как быстро каждая группа установила конкретное обновление Bitcoin Core; количество пользователей, внедривших обновление, не сопровождалось изменением политики.

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

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

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

Отчеты, созданные с помощью ИИ, требуют проверки перед любым публичным уведомлением.

Команда "Bitcoin Red Team" предоставила яркий пример масштаба, которого могут достичь проверки с использованием искусственного интеллекта. В августе новостной портал crypto.news сообщил о 4962 потенциальных проблемах, выявленных в ходе анализа 390 проектов, связанных с биткоином, за первые 29,8 часов работы группы. Группа классифицировала 720 из них как серьезные или критические, и заявила, что более пятой части выявленных потенциальных проблем было подтверждено на момент публикации отчета. Эти данные относятся к широкому спектру проектов, а не к количеству уязвимостей в Bitcoin Core или к точному списку эксплуатируемых ошибок.

Различие между выявленной проблемой и подтвержденным дефектом является ключевым элементом новой политики. Модель может предложить определенный путь в коде, но разработчики должны воспроизвести его, установить, может ли злоумышленник получить к нему доступ, и определить, какие версии программного обеспечения затронуты. Проблема, выявленная в тестовой среде, может отсутствовать в рабочей среде; отсутствие проверки в одной ветке кода может быть компенсировано другим механизмом контроля. Оценка серьезности требует анализа реальных условий и последствий. Классификация как "срочная" следует за проведением технической работы, а не после того, как инструмент искусственного интеллекта выдает правдоподобное объяснение.

В описании проекта указано, что проверка кода и тестирование являются узкими местами в процессе разработки. Обилие отчетов низкого качества может отвлекать внимание от решения серьезных проблем. С другой стороны, достоверный и воспроизводимый отчет может предоставить разработчикам более раннее предупреждение. Инструкции по сообщению об уязвимостях в Bitcoin Core [https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md] направляют сообщения о серьезных проблемах на специальный адрес электронной почты службы безопасности, а не в публичный раздел сообщений об ошибках. Обновление политики не предполагает, что хорошей практикой является публичное распространение непроверенных данных об уязвимостях, пока разработчики еще проверяют их.

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

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

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

Разработчики не пришли к согласию относительно самой рекомендации

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

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

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

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

Core Lightning демонстрирует другой пример работы

Политика Bitcoin Core регулирует только сам Bitcoin Core, а не все программы в экосистеме Bitcoin. Разработчики Core Lightning в августе столкнулись с большим объемом отчетов, сгенерированных искусственным интеллектом, и подтвердили, что некоторые из них описывали реальные уязвимости. В октябре команда предупредила операторов устаревших узлов после сообщений о нападениях на системы, работающие на версии 26.06.7 или более ранних. Они настоятельно рекомендовали обновить программное обеспечение до более новой версии. В этом предупреждении команда не раскрыла публично метод атаки и не подтвердила случаи убытков для пользователей, поэтому эти отчеты не следует рассматривать как доказательство конкретной уязвимости или применять к коду Bitcoin Core.

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

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

Разницу между "доступным" и "установленным" легче всего увидеть, когда уязвимость не затрагивает все системы. Майнер может запускать службу шаблонов блоков рядом со своим узлом проверки. Хранилище может изолировать процесс Bitcoin Core от общедоступного интернета, но при этом позволять внутренним программам обращаться к его RPC-интерфейсу. Домашний пользователь может использовать стандартные сетевые настройки со встроенным кошельком. Одно обновление может исправить все три варианта использования, но степень подверженности риску и время, необходимое для тестирования обновления, могут различаться. Публичная политика Bitcoin Core не пытается установить единый срок для всех этих операторов.

Хорошо сформулированное уведомление может содержать информацию о затронутых версиях и настройках, о последствиях успешной эксплуатации уязвимости, а также о том, требуется ли для атаки доступ к сети, локальный доступ или определенные действия пользователя. В прошлом проект использовал эти критерии при классификации уведомлений. Операторы могут сравнить свои собственные конфигурации с описанными условиями. В поправке от 22 октября обещано опубликовать уведомление с исправлением для группы уязвимостей, которые легко обнаружить, но конкретные детали, которые будут раскрыты, будут зависеть от первой подтвержденной проблемы, классифицированной таким образом.

Первое быстрое уведомление установит темп

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

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

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

Что следует отслеживать

• Первый классифицированный случай: Уведомление, идентифицирующее легко обнаруживаемую уязвимость, затронутые версии и причины для быстрого выпуска исправления.
• Три отдельных выпуска: Соответствующие исправления для версий 30.x, 31.x и 32.x, или обновленная стабильная версия, если будет выпущена новая основная версия.
• Детали уведомления: Четкое разграничение между майнерами, продавцами, хранилищами и домашними узлами, когда их фактическая подверженность риску различается.
• Внедрение операторами: Датированные данные о версиях с указанием конкретной выборки, а также информация от сервисов, использующих частные узлы.
• Нерассмотренные старые случаи: Три исправления уязвимостей средней или высокой степени серьезности из версии 30.0, о которых, согласно документации к версии 32.0, будет сообщено после обычной задержки.

Часто задаваемые вопросы

Что изменилось в политике безопасности Bitcoin Core в октябре 2026 года?

Обновление, которое вступило в силу 22 октября, позволяет разработчикам сообщать об обнаруженных уязвимостях в сводках безопасности, когда они выпускают исправления для каждой поддерживаемой основной версии. Для других случаев действует обычный порядок, основанный на степени серьезности уязвимости.

Означает ли новая политика, что в Bitcoin Core сегодня обнаружена новая ошибка?

В рамках изменения политики не было объявлено о какой-либо конкретной уязвимости. Она меняет способ классификации и раскрытия подтвержденных будущих сообщений об ошибках.

Что считается легко обнаруживаемой уязвимостью в Bitcoin Core?

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

Сколько версий Bitcoin Core получают более быстрые исправления?

Bitcoin Core поддерживает свои три последние основные версии. После выпуска версии 32.0, актуальными являются ветки 30.x, 31.x и 32.x; версии 29.x и более ранние не поддерживаются.

Будут ли все уязвимости Bitcoin Core немедленно раскрыты?

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

Почему публичное уведомление может создавать риски?

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

Все ли отчеты об уязвимостях, сгенерированные искусственным интеллектом, являются достоверными?

Нет. 4962 потенциальных обнаружения, сделанные командой Bitcoin Red Team, охватывали 390 проектов и требовали воспроизведения и проверки. Эти цифры не являются подсчетом подтвержденных уязвимостей в Bitcoin Core.

Когда мы узнаем, смогут ли операторы обновить программное обеспечение вовремя?

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

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

Читать далее: Милей нацелился на пятерых журналистов после отмены уголовного дела LIBRA