⠀
Свежий сигнал пришёл из X от BTCPay Server: если у вас LND и BTCPay Server ниже 2.4.2, включая release candidate 2.4.2, нужно обновляться сразу. Проект пишет, что уязвимость могла дать удалённому неавторизованному атакующему доступ к
.macaroon-файлам LND. Это не «ещё один баг в кошельке», а утечка ключей управления Lightning-нодой.⠀
Что удалось подтвердить.
BTCPay сам признал активную эксплуатацию: пользователи пострадали, средства были украдены, технические детали пока не раскрывают, чтобы операторы успели обновиться. В релизе 2.4.2 тоже прямо сказано, что исправлена критическая уязвимость, которая активно эксплуатируется.
⠀
Граница важная: по заявлению BTCPay, риск относится именно к LND. Другие реализации Lightning и установки без Lightning не попадают в этот конкретный LND credential risk. Стандартные on-chain кошельки BTCPay, включая hot wallets, команда тоже отделяет от проблемы. Но средства внутри LND-ноды и её on-chain wallet всё равно могут быть под риском.
⠀
В X уже есть реальные отчёты операторов. Zach Herbert из Foundation пишет, что hot wallet не тронули, а Lightning-ноду вычистили: каналы закрыли, средства вывели. Citadel21 через hodlonaut сообщил о похожем swept node. Суммарный ущерб и число затронутых операторов публично не названы.
⠀
Для меня главный вывод здесь не «Lightning плохой» и не «самохостинг умер». Вывод проще: если сервис может достать bearer-credentials к платёжной ноде, то внешний периметр сервера становится частью custody-модели. Даже если базовый протокол жив, деньги могут уйти через админский доступ к инфраструктуре вокруг него.
⠀
Что я бы проверял в таком кейсе:
• версия BTCPay Server и LND;
• была ли нода доступна через домен BTCPay, Tor onion, reverse proxy или проброшенный порт;
• обновление до 2.4.2 и LND 0.21.1;
• ротация macaroons, особенно если LND открыт не только через стандартный BTCPay Docker path;
• неожиданные платежи, закрытия каналов, незнакомые peers и расхождения балансов.
⠀
Пока полного postmortem нет, нельзя честно утверждать точный путь атаки и масштаб потерь. Но уже понятно, где проходит проверка: не по лозунгу «self-hosted значит безопаснее», а по тому, какие credential-файлы доступны снаружи и кто фактически может управлять нодой.
