Bitcoin (BTC) BTCPay Server、アクティブなエクスプロイトを受け緊急パッチ2.4.2をリリース

ビットコイン決済インフラのセキュリティ速報

Bitcoin(BTC)のセルフホスト型決済プロセッサであるBTCPay Serverは金曜日、深刻なソフトウェア脆弱性がすでに未特定的攻击者によって悪用されていることを公表した。マーチャントやノードオペレーターが利用するこのオープンソースプロジェクトは、当該脆弱性が資金の喪失につながる可能性があると警告し、管理者に即時対応を促している。脆弱性を公表したのは、ビットコインのオープンソースプロジェクトに対するセキュリティレビューを行うボランティアグループ「Bitcoin Red Team」だ。同グループは直近のColdcard攻撃(1,700 BTC超の盗難に関連)を契機に精査を強化していた。BTCPay Serverの公式アドバイザリによると、最も安全な対応は管理ダッシュボードからバージョン2.4.2へ更新し、サーバーフッターのバージョン文字列を確認することだ。即時パッチ適用が困難な場合は、更新完了までサービスを停止するよう指示されている。さらに、macaroonsの更新、macaroons.dbファイルの再作成、認証文字列のローテーション、プラットフォーム内で生成されたウォレットに保管されているコインの移動も推奨された。初期段階の報告によれば、攻撃はランダムなスキャンではなく標的型の資金引き出し(ドレイン)とみられる。Foundationの共同創設者兼CEOであるZack Herbert氏は、同社のノードが一晩で空にされたと述べた。コミュニティメンバーのHodlonaut氏も、Citadel 21 Lightningノードがドレインされたことを報告しているが、BIP-110アクティベーションの可能性に備えた予防策により残高は限定的だったという。このパターンから、攻撃者はビットコインに強い動機を持つ愛好家やインフラ構築者が使用するツールに照準を合わせていたと推測される。現時点で少なくとも2件のノード資金枯渇が公に確認されているが、プロジェクト側が公式な被害集計を公表していないため、全体像は不明のままだ。オペレーターは迅速なパッチ適用と認証情報のローテーションに頼らざるを得ず、中央集権的な補償プロセスは存在しない。

もう一つの重要な論点は、BTCPay Serverがユーザーに提示した具体的な緩和策の内容だ。金曜日に公開された通知では、管理者に対しバージョン2.4.2をインストールした上でサーバーフッターのビルドラベルを確認するよう求めている。自動更新が成功したと想定するのではなく、手動での検証が不可欠だ。即時パッチが不可能なチームへの指示は明快で、不正アクセスを遮断するためにサーバーを停止すること。通知はまた、macaroonsとして知られる公開された認証情報の置き換え、macaroons.dbファイルの再構築、Lightning Networkバックエンドが使用する認証文字列の更新も求めている。BTCPay内でオンチェーンのホットウォレットを生成したユーザーには、資金の移動と新規ウォレットの作成が推奨されている。プロジェクト側は脆弱性の技術的メカニズム、攻撃の開始時期、影響を受けたサーバー数、AIの関与の有無について一切説明していない。この情報不足により被害規模の特定は困難だが、より広範な脅威モデルの変化を浮き彫りにしている。5月にはセキュリティ研究者Taylor Hornby氏がAnthropicのClaude Opus 4.8モデルを使用し、4年間存在していたZcashの脆弱性を発見した。この脆弱性はZECの無制限偽造を可能にする恐れがあった。8月にはColdcardハードウェアの製造元Coinkiteが、AI支援による発見が疑われるファームウェア欠陥を公表し、1億ドル超のビットコイン盗難に関連付けられた。火曜日にはビットコインのスワッププロバイダーBoltzが複数のエクスプロイトを受けてサービスを一時停止し、自動化された攻撃が開発者のパッチ適用速度を上回っていると述べた。同様の自動化の議論は、AIトレーディングボットソフトウェアの分野でも起きており、速度の優位性が即座に運用リスクに転化する構造は共通している。メンテナーにとって、パッチの適用頻度、認証情報の衛生管理、迅速な情報開示は、機能開発と同等かそれ以上に重要な課題となりつつある。これは単一アプリケーションの問題にとどまらず、ホビイストのノードからマーチャントのデプロイまで、セルフカストディスタック全体に対するストレステストだ。

BTCPay Serverの開発チームは、脆弱性の技術的詳細を非公開にしていることについて、オペレーターがパッチ適用を完了するまでの間に攻撃者へ追加的な悪用ベクトルを与えないための意図的な判断であると明確に述べている。プロジェクトはまた、正確な更新手順も公開している。管理ダッシュボードから「Server」「Maintenance」「Update」の順に操作することで、管理者は自動メカニズムに依存するのではなく、正しい手順を踏んでいることを確認できる。BTCPay Serverはセルフホスト型ソフトウェアであるため、中央の主体が個々のオペレーターに代わって修正をデプロイすることはできない。修復の全責任は各ノードオーナーに帰属する。この姿勢は、アクティブに悪用されている脆弱性に対する標準的な対応实践を反映している。パッチ適用のウィンドウが閉じるまで公開情報を制限し、直接的な脅威が収まった後に詳細なポストモーテムを発行するという手順だ。

（03:58 UTC 時点） (UTC 03:58時点)COINOTAGの分析では、これらの動向を一つのテーマに集約できる。Bitcoin(BTC)スタックは、イデオロギーではなくセキュリティオペレーションが信頼性を決定するフェーズに入りつつある。今回の一次情報源はBTCPay Server自身のアドバイザリであり、ユーザーに対してバージョン2.4.2のインストール、必要に応じたノード停止、macaroonsの置き換え、macaroons.dbの再構築、Lightning認証文字列の更新、ホットウォレット資金の移動を明示的に指示している。最終的な被害額や影響サーバー数は示されておらず、確定した事実は限定的だ。この抑制は重要である。オペレーターにとっての教訓は手続き的なものだ。ビルドを検証し、認証情報をローテーションし、被害を評価する前に公開されたウォレットを隔離すること。史上最高値の更新に市場の注目が集まりがちな局面において、今回のインシデントは、カストディの配管(プラミング)こそがシステム全体で最も脆弱なレイヤーであり続けるという事実を改めて突きつけている。