Last Updated on 2026年8月11日 by oba3
ビットコイン（Bitcoin）決済基盤のBTCPay Serverは2026年8月7日、実際の攻撃で悪用されている重大な脆弱性を修正したバージョン2.4.2を公開し、利用者へ早急な更新を求めた。問題の一つは、Greenfield APIのBasic認証を経由することでTOTP方式の二要素認証を回避できる脆弱性だ。開発チームは対策として、新規アカウント作成から5分後にBasic認証を標準で無効化する変更も導入した。今回注意すべきなのは、ビットコインの暗号方式やブロックチェーンそのものが破られたわけではない点だ。加盟店が実際の決済を受け付けるサーバーにはアカウント、API、ウォレット、ライトニング（Lightning）接続など複数の権限が集まるため、決済周辺インフラが侵害されれば資金管理へ近い場所まで攻撃者が到達する余地が生まれる。
何が起きたのか？
BTCPay Serverは8月7日に公開した2.4.2のリリース情報で、重大な脆弱性が現実の攻撃で悪用されていると明言した。開発チームは利用者に可能な限り早い更新を求めるとともに、BTCPay Serverと組み合わせて利用されるブロックチェーン監視コンポーネントNBXplorerについても2.6.10への更新を推奨している。
BTCPay Server 2.4.2で明示された重要な修正が、Greenfield APIのBasic認証を利用したTOTP二要素認証の回避だ。TOTPは認証アプリなどが生成する時間制限付きコードをパスワードに追加する仕組みだが、問題の経路ではBasic認証を利用することで、この追加確認を期待通りに適用できない状態が存在した。
対策としてBTCPay Serverは、アカウント作成直後を除きBasic認証を標準で利用できない設計へ変更した。新規アカウントでは作成から5分後に自動的にBasic認証が無効になり、必要な利用者だけが設定やAPIから明示的に再有効化する方式となる。開発側は通常の連携ではAPIキー認証が一般的であり、この変更による既存利用者への影響は把握していないとしている。
脆弱性はビットコイン・レッド・チーム（Bitcoin Red Team）の活動を通じてブルーノ・ガルシア（Bruno Garcia）とベン・カーマン（Ben Carman）から報告された。つまり今回の更新は通常の機能改善ではなく、攻撃が確認された状態で認証経路を閉じる緊急性の高いセキュリティ対応だった。
なぜ重要なのか？
BTCPay Serverは、加盟店が第三者の決済会社へ全面的に依存せず、ビットコイン決済を受け付けるためのオープンソース基盤だ。請求書の生成、支払い状況の確認、ウォレットとの接続、API経由の店舗システム連携など、実際の商取引に必要な機能が一つのサーバー上に集まる。
そのため認証を突破されることの意味は、一般的なウェブサイトのログイン情報漏えいより重い場合がある。侵害されたアカウントの権限や設定によっては、店舗情報や決済データへアクセスされるだけでなく、ウォレット操作に関係する機能や外部サービスとの接続設定まで攻撃対象になる可能性がある。
ただし今回公表された情報だけから、すべての侵害環境で加盟店資金が盗まれた、あるいはライトニング接続情報が流出したと断定することはできない。BTCPay Serverが確認しているのは重大脆弱性が実際に悪用されていることと、その認証経路を2.4.2で修正したことだ。具体的な被害範囲や侵害された利用者数は公表情報からは確定していない。
この区別は重要だ。今回破られたのはビットコインの秘密鍵方式やコンセンサスではなく、ビットコインを現実の店舗決済へ接続するアプリケーション層だ。暗号資産の安全性は基盤チェーンだけで決まらず、その上で動くサーバー、API、認証、プラグインなどの安全性にも依存している。
市場構造への影響
ビットコイン決済では、自己管理を選ぶことで中央集権型決済会社への依存を減らせる。しかし加盟店が自前で決済サーバーを運用する場合、運用責任も同時に加盟店側へ移る。サーバー更新、認証設定、APIキー管理、ネットワーク公開範囲などが決済セキュリティの一部になる。
ここでは「自己管理だから安全」「中央管理だから危険」という単純な比較は成立しない。第三者を減らしても、BTCPay Serverのような決済アプリケーションが新しい権限集中点になる場合がある。特に管理者アカウントや高権限APIが侵害されれば、複数の店舗機能へ横断的にアクセスされる余地が生じる。
逆に今回の対応では、Basic認証を常時有効にしておく設計そのものが変更された。使える認証方式を増やして利便性を高めるのではなく、通常使われない経路を標準状態では閉じる考え方だ。高権限機能へ到達できる入口を少なくすることが、決済インフラの安全性に直結する。
今後、ビットコイン決済の普及を測る際には、加盟店数や決済額だけでなく、その決済を支えるソフトウェアがどの程度迅速に更新され、不要な権限を制限できるかも重要になる。利用者が増えるほど、一つの周辺ソフトウェアの脆弱性が多数の加盟店へ同時に影響する可能性があるからだ。
資金・規制・流動性との関係
今回の事件がビットコイン市場全体の流動性を直接変えたと確認されているわけではない。影響が集中するのは、BTCPay Serverを利用して実際に決済を受け付ける事業者の運用側だ。決済サーバーが侵害された場合、加盟店はサービス停止、認証情報の交換、ログ確認、ウォレットやライトニング構成の点検などを迫られる可能性がある。
加盟店決済では可用性も重要になる。セキュリティ対策のためサーバーを停止すれば、その間は支払いを受け付けられない。逆に更新を先送りすれば既知の攻撃経路を残すことになる。実攻撃が確認された脆弱性では、通常の保守更新よりも決済停止のコストと侵害リスクを短時間で比較する必要がある。
また、決済サーバーとライトニングノードを接続している構成では、BTCPay Serverだけを見れば十分とは限らない。開発チームがNBXplorer 2.6.10への更新も推奨しているように、実際の決済環境は複数のソフトウェアから構成される。どこか一つだけを最新版にしても、周辺コンポーネントに弱点が残れば全体の安全性はその弱い部分に左右される。
規制面でも、企業が暗号資産決済を扱う場合は秘密鍵管理だけでなく、管理画面へのアクセス制御、ログ保存、ソフトウェア更新、インシデント対応を含む運用統制が重要になる。今回新しい規制が導入されたわけではないが、暗号資産を商用決済へ組み込むほど、サーバー管理は一般的な情報セキュリティと資金管理の両方にまたがる問題になる。
初心者向け補足
BTCPay Serverはビットコインそのものではなく、店舗やウェブサービスがビットコイン決済を受け付けるためのソフトウェアだ。顧客向けの請求書を作り、支払いを検知し、店舗側のシステムへ結果を返す役割を持つ。
Greenfield APIは、外部のアプリケーションからBTCPay Serverを操作するための接口だ。ECサイトなどがAPIを利用すれば、注文に応じて自動的に請求書を作成したり、支払い状況を取得したりできる。その分、APIの認証を突破されると人間向けの管理画面とは別の経路から機能へアクセスされる危険がある。
TOTP二要素認証は、パスワードに加えて認証アプリが生成する一時コードを求める防御策だ。今回の修正では、特定のBasic認証経路からこの追加防御を回避できる問題が修正された。
重要なのは、今回の脆弱性をビットコインネットワークの侵害と混同しないことだ。ブロックチェーンそのものが改ざんされたわけでも、ビットコインの暗号方式が破られたわけでもない。店舗がビットコインを受け付けるために利用する周辺ソフトウェアの認証問題である。
Web3Timesの視点
Web3Timesが今回見るのは、BTCPay Serverに一つ重大なバグが見つかったという個別事故だけではない。ビットコイン利用が現実の商取引へ広がるほど、攻撃面がブロックチェーン本体から決済アプリケーション、API、認証基盤へ広がる点だ。
ビットコインは秘密鍵を持つ主体だけが資産を署名できる設計でも、その前段にある業務システムが攻撃されれば別の問題が生まれる。攻撃者が秘密鍵そのものを盗まなくても、請求書、管理権限、API、ウォレット操作に関係する機能へ到達できれば、加盟店の決済業務へ影響を与えられる可能性がある。
今回の2.4.2で注目したいのは、脆弱性の修正と同時にBasic認証を原則閉じる設計へ変えたことだ。問題が起きるたびに検知機能を追加するだけでなく、通常必要のない認証経路そのものを減らして攻撃面を狭めている。決済システムでは、機能数を増やすことより不要な権限を残さないことが安全性につながる。
現時点では攻撃による具体的な被害額や影響サーバー数は公表情報だけでは確認できない。そのため今後追うべきなのは被害額の推測ではなく、実際にどのバージョンや設定が悪用されたのか、侵害された環境でどの権限まで取得されたのか、NBXplorerを含む周辺コンポーネントにどこまで影響が及んだのかだ。ビットコイン決済の安全性を評価するなら、チェーンそのものだけでなく、加盟店の資金とブロックチェーンを接続するサーバー群まで一つの決済インフラとして見る必要がある。
