Last Updated on 2026年8月10日 by oba3
ビットコイン（Bitcoin）決済基盤のBTCPay Serverは2026年8月7日、重大な脆弱性が実際の攻撃で悪用されているとして、バージョン2.4.2への緊急更新を呼びかけた。今回修正された問題には、グリーンフィールドAPI（Greenfield API）の基本認証を経由して時間ベースワンタイムパスワードによる二要素認証を回避できる脆弱性が含まれる。重要なのは、ビットコインのブロックチェーンや暗号方式そのものが破られたわけではないことだ。加盟店がビットコインやライトニング（Lightning）決済を受け付けるために運用するサーバーが侵害されれば、決済設定や管理権限など資金に近い周辺インフラが攻撃対象になる。
何が起きたのか？
BTCPay Serverの開発チームは8月7日、バージョン2.4.2を公開し、重大な脆弱性が現実の攻撃で悪用されているため、できるだけ早く更新するよう利用者へ警告した。開発チームは同時に、BTCPay Serverと組み合わせて利用されるNBXplorerについてもバージョン2.6.10への更新を推奨している。
公開された修正内容には、グリーンフィールドAPIの基本認証を利用することで、時間ベースワンタイムパスワードによる二要素認証を回避できる問題が含まれている。これを受け、2.4.2ではアカウント作成から5分後に基本認証を標準で無効化し、必要な利用者だけが設定画面やAPIから明示的に有効化する方式へ変更された。
脆弱性はビットコイン・レッド・チーム（Bitcoin Red Team）の活動を通じて報告された。BTCPay Server側は実際に悪用されている重大問題であることを明示している一方、公開情報では攻撃件数、被害を受けた加盟店数、盗難額などの具体的な規模は示していない。
また、BTCPay Serverは今回の基本認証変更について、一般的にはAPIキー認証が使われているため、この仕様変更によって影響を受ける利用者を現時点では把握していないとしている。したがって、脆弱性の存在と実悪用は確認されているが、被害範囲を推測で拡大して説明するべきではない。
なぜ重要なのか？
BTCPay Serverは、加盟店が第三者の決済会社へビットコインを預けず、自分で決済環境を運営できるオープンソースの決済サーバーだ。利用者はオンラインショップや実店舗の決済画面と接続し、ビットコインやライトニングの支払いを直接受け付けられる。
この仕組みでは、ビットコイン本体が正常に動いていても、決済サーバーの管理権限が侵害されれば別の問題が生じる。店舗設定、請求書、API、ウォレット連携など、加盟店の決済業務に近い情報や機能へ攻撃者が到達する可能性があるためだ。
特に二要素認証は、パスワードが漏れた場合にも追加の確認を要求するための防御層である。その防御を特定の認証経路から回避できる問題が実際に悪用されていたことは、管理画面だけを安全にしても、別のAPI認証経路が弱ければ全体の防御が崩れることを示している。
市場構造への影響
今回の問題を「ビットコインの重大脆弱性」と読むのは正確ではない。ビットコインのコンセンサスや暗号方式ではなく、その上で決済サービスを構築するアプリケーション層に発生したセキュリティ問題だからだ。
しかし利用者から見れば、この違いだけで安心できるわけではない。ビットコイン決済は、ビットコイン・コア、ウォレット、BTCPay Server、NBXplorer、ライトニングノード、ECサイトなど複数のソフトウェアが接続して成立する。どこか一つに重大な権限侵害があれば、決済業務全体へ影響が広がる可能性がある。
ここで問われるのは、ブロックチェーンそのものの安全性ではなく、その周囲に構築された決済基盤の更新能力だ。脆弱性が発見された際に、開発者がどれだけ早く修正版を出し、加盟店がどれだけ早く適用できるか。オープンソース決済が商用インフラとして広がるほど、この運用速度が信頼性を左右する。
また自己運用型の決済には、第三者へ資産管理を委ねない利点がある一方、サーバー管理やアップデートの責任も利用者側へ移る。セルフホストは仲介者をなくす仕組みであって、セキュリティ運用まで不要にする仕組みではない。
資金・規制・流動性との関係
決済サーバーの侵害は、取引所のように大量の顧客資産を一括保管する事故とは性質が異なる。それでも、管理者権限やウォレット関連設定へ不正にアクセスできる状態になれば、加盟店の資金管理に近い領域まで危険が及ぶ可能性がある。
ライトニングを利用する環境では、BTCPay Serverが外部または自己運用のライトニングノードと接続される場合もある。今回の公開情報だけから、ライトニング接続情報や資金が実際に盗まれたと断定することはできない。ただし決済サーバーに強い管理権限を持たせる構成では、サーバー侵害時にどこまで影響が及ぶかを事前に分離しておく必要がある。
そのため重要になるのが最小権限だ。APIごとに必要な権限だけを与える、不要な認証方式を停止する、ウォレット署名権限を別環境へ置く、ライトニングノードへの接続権限を限定するといった設計によって、一つのサーバー侵害が全資産の侵害へ直結する状態を避けやすくなる。
規制された事業者や大規模加盟店がビットコイン決済を導入する場合も、どのソフトウェアを利用しているかだけでなく、重大脆弱性への更新時間、アクセスログ、認証方式、権限分離をどのように管理しているかが運用評価の対象になっていく。
初心者向け補足
BTCPay Serverとは、店舗やウェブサービスがビットコイン決済を受け付けるためのオープンソースソフトウェアだ。決済代行会社へ資金管理を任せる方式とは異なり、自分のサーバーで運用できることが特徴になっている。
二要素認証とは、パスワードだけでなくスマートフォンなどで生成する一時的なコードも要求する認証方法だ。今回修正された問題では、グリーンフィールドAPIの基本認証という別の経路を利用することで、この追加認証を回避できる状態が問題となった。
また「実際に悪用されている」とは、研究者が理論上の攻撃方法を発見しただけではなく、現実の環境で攻撃に使われていることを開発側が認識していることを示す。ただし現時点で公開されている情報から、被害件数や盗難総額まで判断することはできない。
Web3Timesの視点
Web3Timesが今回注目するのは、ビットコイン自体が安全か危険かという議論ではない。見るべきなのは、実際の決済が増えるほど、攻撃対象がブロックチェーン本体からその周辺へ広がることだ。
ビットコインのコンセンサスが強固でも、加盟店が使う決済サーバー、API認証、ライトニング接続、ECサイトのプラグインに弱点があれば、利用者の資金や決済業務は別の経路から狙われる。実用化が進むほど、セキュリティの中心はプロトコルだけではなく運用ソフトウェアへ広がる。
今回特に見るべきなのは、脆弱性発見から修正版公開までの対応だけでなく、実際のサーバーがどの速度で更新されるかだ。BTCPay Server側が緊急更新を出しても、インターネット上に古いバージョンが長期間残れば攻撃面は消えない。分散型の決済インフラでは、中央運営者が一斉更新できないこと自体が運用上の課題になる。
今後追うべきなのは被害額だけではない。2.4.2への更新率、悪用された認証経路の詳細、実際の侵害範囲、加盟店側での権限分離がどこまで行われていたかが重要になる。ビットコイン決済の普及を支えるのはブロック生成だけではない。周辺サーバーで重大な問題が見つかった際に、発見、修正、配布、適用までを継続的に回せる体制が、決済ネットワーク全体の信頼を左右する。
