BTCPay Server に重大な脆弱性、現在も攻撃継続中：今すぐアップグレードし、認証情報をローテーションせよ
BTCPay Server に重大な脆弱性、現在も攻撃継続中：今すぐアップグレードし、認証情報をローテーションせよ
オープンソースの Bitcoin 決済処理サービスである BTCPay Server に、実際に悪用されているとみられる重大なセキュリティ脆弱性が見つかったとして、管理者に対し直ちに対応するよう呼びかけが出ています。プロジェクト側は、サーバー運用者に対してバージョン 2.4.2 へのアップグレード、サーバーフッターで更新が反映されていることの確認、そして漏えいの可能性がある認証情報のローテーションを指示しています。
BTCPay Server を使って Bitcoin や Lightning Network の支払いを受け付けている加盟店、ノード運用者、そして暗号資産ネイティブの事業者にとって、これは単なる定期メンテナンスの案内ではありません。今回の警告は、不正アクセスの可能性、そして最悪の場合には直接的な資金損失を含むものです。
何が起きたのか？
BTCPay Server は、広く利用されているセルフホスト型の Bitcoin 決済処理スタックであり、サーバーのセキュリティに影響する深刻な脆弱性があるとして管理者に警告を出しました。この問題は、Bitcoin 関連インフラを調査しているセキュリティ重視のグループ「Bitcoin Red Team」のメンバーによって報告されたものです。
執筆時点で、BTCPay Server チームはこの脆弱性の詳細な技術情報をまだ公開していません。これは、実際に悪用が進行している状況ではごく一般的で、かつ責任ある対応です。というのも、攻撃手法の仕組みを早すぎる段階で公開してしまうと、未修正のシステムを狙う攻撃者を利するおそれがあるためです。
現時点で分かっていることは以下のとおりです。
- BTCPay Server は、必要なセキュリティ更新としてバージョン 2.4.2 をリリースしました。
- 管理者は、サーバーフッターに更新後のバージョンが表示されていることを確認して、アップグレード完了を検証する必要があります。
- すぐにアップグレードできない場合は、一時的にサーバーを停止すべきです。
- 運用者は、漏えいの可能性がある認証情報、特に Lightning 関連の macaroon をローテーションする必要があります。
- BTCPay Server 内で作成したホットなオンチェーンウォレットを使っているユーザーは、ただちに資金を移し、新しいウォレットを再作成すべきです。
- プロジェクト側はまだ、攻撃がいつ始まったのか、どれほどの台数のサーバーが影響を受ける可能性があるのか、あるいは資金がすでに盗まれたのかどうかを公表していません。
管理者は、公式の BTCPay Server GitHub releases ページ から最新のリリース情報を確認できます。
Bitcoin 決済インフラにとってなぜ重要なのか
BTCPay Server が人気を集めている理由は、管理者が保管代行型の決済処理業者に依存せずに Bitcoin 決済を受け付けられるからです。この仕組みは、自己保管、検閲耐性、直接決済という、本来の暗号資産の思想に非常に近いものです。
しかし、セルフホストであるということは、同時に自己責任でもあります。
BTCPay Server のインスタンスは、以下のようなものに接続されることがあります。
- Bitcoin Core やその他のオンチェーンバックエンド
- Lightning Network ノード
- 加盟店ダッシュボード
- API 連携
- ホットウォレット
- Web ストアや会計ツール
攻撃者が特権アクセスを得た場合、その影響は Web インターフェースだけにとどまらない可能性があります。設定次第では、漏えいした認証情報によって請求書の改ざん、バックエンドへのアクセス、Lightning ノードの操作、あるいはホットウォレットからの資金移動まで可能になるかもしれません。
今回の件は、暗号資産の決済インフラが単なる Web サイトではないことを思い出させます。多くの場合、実際の流動性とつながっているのです。
BTCPay Server 管理者が直ちに行うべき対応
BTCPay Server を運用しているなら、最優先は調査ではなく封じ込めです。
1. BTCPay Server 2.4.2 にアップグレードする
できるだけ早く、インスタンスを 2.4.2 に更新してください。アップグレード後は、処理が正常に完了したと決めつけないでください。ログインし、サーバーフッターに新しいバージョンが表示されていることを必ず確認してください。
Docker デプロイを使っている場合は、BTCPay Server のドキュメント にある公式のアップグレード手順に従ってください。
2. すぐにパッチを当てられないならサーバーを停止する
今すぐアップグレードできない場合は、対応できるまでサーバーをオフラインにしてください。攻撃が進行している最中に、脆弱性のあるインスタンスをそのまま公開し続けるのは不要なリスクを招きます。
これは、外部から到達可能なサーバー、ストアのチェックアウトと連携しているサーバー、あるいは Lightning バックエンドにつながっているサーバーでは特に重要です。
3. Lightning Network の macaroon をローテーションする
BTCPay Server は、漏えいの可能性がある macaroon を置き換えるよう、特に注意喚起しています。Lightning インフラにおいて macaroon は、LND や関連サービスがアクセス権限を制御するために使う認証トークンです。
macaroon が漏えいすると、攻撃者はその認証情報で許可された操作を実行できる可能性があります。権限範囲によっては、これは非常に重大です。
運用者は、必要に応じて macaroons.db ファイルを再作成し、その他の Lightning Network バックエンドについても認証文字列を更新してください。LND がこれらの認証情報をどう使うかについては、公式の Lightning Labs の macaroon に関するドキュメント を参照してください。
4. BTCPay Server 内で作成したホットなオンチェーンウォレットから資金を移動する
BTCPay Server 内で直接作成したホットなオンチェーンウォレットがある場合は、資金をただちに新しい安全なウォレットへ移してください。
ホットウォレットは、自動決済フロー、返金、加盟店運用には便利ですが、その一方でサーバー側のリスクにさらされています。サーバーが侵害された可能性があるなら、そのウォレットは安全ではないものとして扱うべきです。
資金を移したあと、クリーンな設定と新しい認証情報でウォレットを再作成してください。
5. ログとアクセスパターンを確認する
パッチ適用と認証情報のローテーション後、管理者は以下を確認すべきです。
- 最近のログイン履歴
- API キーの使用状況
- ストア設定の変更
- 新規ユーザーや権限変更
- 不審な請求書の動き
- Lightning ノードのアクセスログ
- 外向きのトランザクション
- Web サーバーのアクセスログ
資金の流出が見当たらない場合でも、攻撃者が永続化の仕組みを仕込んだり、後で使うために認証情報を収集している可能性があります。
さらに大きなセキュリティ上の教訓：ホットウォレットに保有させる資産は厳しく制限すべき
今回の脆弱性は、暗号資産運用における最重要設計原則のひとつを浮き彫りにしています。つまり、オンラインシステムにさらす資産価値を最小化することです。
決済サーバーは、短期運用に必要な以上の資金を保持すべきではありません。加盟店や事業者は、次のような階層化されたウォレット戦略を検討すべきです。
- ホットウォレットは小額の運転資金にのみ使う
- 余剰資金は定期的にコールドストレージへ移す
- 決済受領用の資金と長期保管用の資金を分離する
- API キーと Lightning 認証情報の権限は必要最小限にする
- バックアップはオフラインかつアクセス制御の下で保管する
- 緊急時を迎える前にインシデント対応手順をテストしておく
暗号資産の世界では、ソフトウェア保守と資産保全の境界は非常に薄いものです。サーバー更新の失敗が、そのままウォレットのセキュリティ事故につながることがあります。
2025 年に攻撃者の動きが速くなっている理由
今回のタイミングは、デジタル資産業界全体で進む大きな流れとも一致しています。セキュリティ研究者と攻撃者の双方が、AI 支援ツールを使ってコードをレビューし、不審なパターンを見つけ、脆弱性の発見を自動化するようになってきています。
防御側にとって、AI は監査を加速し、オープンソースプロジェクトがバグをより早く見つける助けになります。一方で攻撃者にとっても、同種のツールはリポジトリのスキャン、攻撃仮説の生成、脆弱な環境の大規模テストに要する時間を短縮できます。
だからといって、AI があらゆる暗号資産の不正利用の原因だというわけではありません。ただし、脆弱性の発見から実際の悪用までの猶予が、以前より短くなりつつあることは意味しています。
業界ではすでに、自動化された脆弱性調査、AI によるコードレビュー、ソフトウェアサプライチェーンリスクへの注目が高まっています。一般的な Web アプリケーションのリスクを確認するうえでは OWASP セキュリティフレームワーク が引き続き有用な参考資料ですが、暗号資産チームはそれに加えて、ウォレット鍵、ノード認証情報、スマートコントラクト権限、決済インフラも考慮しなければなりません。
Bitcoin と Lightning の運用者にとっての実践的な教訓は明確です。パッチ適用の遅れは、これまで以上に危険になっているのです。
暗号資産決済運用者のための実践的セキュリティチェックリスト
セルフホスト型インフラで Bitcoin または Lightning の支払いを受け付けているなら、次の基本的な対策を導入することを検討してください。
- 新しいセキュリティリリースを自動監視する
- 公式プロジェクトのアナウンスを購読する
- 可能であれば管理画面を VPN または IP アロウリストで制限する
- 強力で固有の管理者認証情報を使う
- API キーと macaroon を定期的にローテーションする
- ホットウォレット残高と資金保管用資産を分離する
- サーバーバックアップは暗号化し、復元テストも行う
- すべての連携に対して最小権限のアクセスを適用する
- 文書化されたインシデント対応計画を維持する
- 長期保有資産はオフラインまたはハードウェアベースの自己保管に移す
これらの対策だけでリスクを完全になくすことはできませんが、脆弱性が見つかったときの被害範囲を小さくする助けになります。
OneKey がより安全な資金管理体制で果たせる役割
加盟店や暗号資産チームにとって、BTCPay Server は、支払いの主権を手放さずに Bitcoin を受け付けるための強力なツールになり得ます。しかし、決済サーバーはオンラインシステムであり、長期保管用の金庫として扱うべきではありません。
OneKey のハードウェアウォレットは、秘密鍵をオフラインに保つことを助けるよう設計されており、ホットな決済インフラとは別に treasury 資金を保管する実用的な選択肢になります。このような構成では、BTCPay Server が日々の決済処理を担い、大きな残高は定期的にハードウェアベースの自己保管へ移すことができます。
この分離が重要です。サーバー側の脆弱性が現れたときに守りたいのは、全資産ではなく、あくまで限定された運転資金だけにするためです。
まとめ
BTCPay Server の脆弱性は、セルフホスト型の Bitcoin インフラには継続的なメンテナンスが不可欠であることを改めて示しています。運用者はただちにバージョン 2.4.2 へアップグレードし、認証情報をローテーションし、漏えいの可能性があるウォレット要素を再作成し、侵害された可能性のあるホットウォレットから資金を移動すべきです。
自己保管は強力ですが、それには規律あるセキュリティ設計も必要です。2025 年には、攻撃者の自動化能力と AI 支援ツールがさらに高度化する中で、暗号資産の利用者や事業者は、より迅速なパッチ適用、より少額のホットウォレット残高、そして決済システムと長期保管をより明確に分離することで対応していかなければなりません。
