BTCPay Server предупредил о краже Bitcoin из горячих кошельков: какие версии под угрозой

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

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

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

Что произошло 1-2 ноября 2026 года

BTCPay Server - программа с открытым кодом для самостоятельного приёма платежей в криптовалюте Bitcoin и сети Lightning. Компания может установить её на собственный VPS или выделенный сервер, создать магазин, получать инвойсы и связывать оплату с заказами на сайте. Такой подход уменьшает зависимость от посредника, но переносит безопасность самого сервера на его владельца.

В ночь с воскресенья на понедельник события развивались быстро. В своём предупреждении 1 ноября проект сообщил о поступающих жалобах на несанкционированный вывод средств и попросил операторов остановить сервер до окончания проверки. Затем сооснователь BTCPay Nicolas Dorier уточнил, что в изученных случаях злоумышленник смог войти с правами администратора. Каким именно способом он получил эти права, на тот момент ещё выясняли.

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

Почему горячий кошелёк может опустеть без участия владельца

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

Представим магазин, который получил в течение дня 0,15 BTC. Средства видны в панели BTCPay, а приватные ключи для отправки хранятся на самом сервере. Если злоумышленник получает доступ к ключам или функциональности подписи, он способен создать обычную Bitcoin-транзакцию на собственный адрес. Блокчейн проверит криптографическую подпись, а не законность действий человека, который её инициировал.

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

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

Какие версии BTCPay Server под подозрением

Уточнение разработчиков от 2 ноября полезно, но его нельзя читать как окончательную таблицу безопасности всех сборок. Из публичного заявления известно о найденном векторе атаки для 2.4.1 и старше. Для версии 2.4.7 проект не получил достоверных сообщений о краже. По промежуточным версиям 2.4.2-2.4.6 аналогичного безусловного вывода публичное сообщение не содержит.

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

Прошлая редакционная публикация BarbadosNews о BTCPay Server 2.4.6 и защите API-ключей касается другого исправления от 26 октября. Она полезна для понимания разграничения полномочий интеграций, но наличие ошибки в правилах API не доказано как причина краж 1-2 ноября.

Что делать оператору сервера прямо сейчас

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

1. Временно остановите BTCPay в соответствии с установкой

В первоначальном уведомлении команда рекомендовала для типовой установки BTCPay команду ./btcpay-down.sh. В стандартном Docker-развёртывании установлен также служебный сценарий btcpay-down.sh, который останавливает стек контейнеров. Команда должна запускаться на своём сервере, из корректного окружения и с пониманием текущей конфигурации, а не на локальном компьютере покупателя.

sudo su -
btcpay-down.sh

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

2. Сохраните журналы и зафиксируйте состояние

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

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

3. Проверьте блокчейн, а не только таблицу заказов

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

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

4. Не включайте сервис автоматически после обновления

Официальный btcpay-update.sh для Docker обычно пересоздаёт и снова запускает стек. Поэтому установка новой версии на остановленном сервере - отдельная операция с последствиями: если команда первоначально попросила оставаться офлайн до расследования, обычный сценарий обновления может вернуть сервис в сеть раньше, чем оператор принял такое решение.

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

Если Bitcoin уже украдены: чем поможет расследование

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

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

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

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

Что делать магазину, который принимал BTC через watch-only

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

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

Отдельно учитывайте Lightning: баланс каналов, авторизационные файлы и резервные копии LND требуют собственной процедуры безопасности. Наблюдающий Bitcoin-кошелёк на одном из компонентов не гарантирует, что другие подключённые части сервера не используют горячие ключи.

Почему ноябрьский инцидент не равен августовской уязвимости LND

В августе BTCPay действительно публиковала экстренное предупреждение о критическом дефекте, исправленном в 2.4.2. Тогда речь шла о возможном похищении административных файлов .macaroon у LND - реализации Lightning Network. Через такие полномочия злоумышленник мог управлять связанным узлом и похищать средства. Позднее разработчики отдельно уточнили, что обычные on-chain кошельки BTCPay, включая горячие, не были затронуты именно тем августовским дефектом.

Сегодня сообщения, напротив, касаются горячих Bitcoin-кошельков на старых экземплярах BTCPay. Упоминание общего номера версии 2.4.2 не доказывает, что это та же самая уязвимость или что преступники применили идентичный способ доступа. Если команда обнаружит связь, она должна появиться в отдельном техническом разборе с указанием подтверждённых фактов.

Такое разделение важно для действий администратора. Исправление API, восстановление повреждённого Lightning-узла и реагирование на компрометацию горячего кошелька требуют разных проверок. Универсальная рекомендация «просто замените пароль» не решает их всех.

Почему обновление 2.4.7 не даёт автоматической гарантии

В журнале официального релиза от 29 октября указано, что 2.4.7 исправляет найденные ошибки безопасности, надёжности и учёта платежей. Это объективная причина обновиться с устаревшей сборки, когда процедура безопасного возобновления работы будет определена. Но новый бинарный файл не удаляет ранее украденные ключи, не блокирует посторонние SSH-учётные записи и не устраняет подозрительные изменения в других компонентах VPS.

Технически нужно ответить на несколько вопросов. Кто получал административный доступ к серверу и магазину? Существуют ли незнакомые API-токены и дополнительные пользователи? Откуда запущены подозрительные процессы и команды? Хранились ли на машине ключи с полномочием отправлять BTC? Подтверждены ли в блокчейне исходящие операции на неизвестные адреса? Какую конфигурацию платёжного процессора нужно возвращать на чистом сервере?

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

Как не потерять продажи во время остановки Bitcoin-оплаты

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

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

Отделите три состояния заказов: уже подтверждённая оплата; транзакция есть, но подтверждения или внутренняя обработка ещё не завершились; покупателю был показан инвойс, но отправки в блокчейн не было. Такая сверка поможет корректно обслужить клиентов после восстановления инфраструктуры.

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

Признаки, которые стоит проверить перед повторным запуском

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

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

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

Частые вопросы об угрозе BTCPay Server

BTCPay Server взломали целиком, включая Bitcoin-сеть?

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

Какую версию срочно проверять?

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

Можно ли просто нажать Update и продолжить принимать платежи?

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

Пострадали ли все клиенты, которые платили Bitcoin в магазине?

Сведения об этом отсутствуют. Сообщения касаются серверов продавцов и их горячих кошельков. Покупателю не следует отправлять пароль, сид-фразу или дополнительную «компенсационную оплату» по запросу стороннего лица.

Известно, сколько Bitcoin украдено?

На момент написания статьи BTCPay не опубликовала подтверждённую общую сумму потерь и число пострадавших установок. Отдельные оценки отдельных адресов не равны проверенному общему размеру ущерба.

Поможет ли отключение сервера вернуть уже отправленные монеты?

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

Что известно сейчас и за чем следить

На утро 2 ноября подтверждены три важные вещи: команда BTCPay получила сообщения о реальных списаниях, указала на путь атаки в сборках 2.4.1 и старше и сообщила об отсутствии достоверных случаев для версии 2.4.7. При этом причина получения административного доступа, общая сумма потерь и окончательный режим безопасного возобновления работы оставались предметом расследования.

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

Автор

Barbados