オープンソース開発とAI時代のサイバー攻撃 | ビットコイン周辺のOSSに対する攻撃と、これからの防御

加藤規新 • 2026年09月14日

今からおよそ1か月前の2026年8月初旬、ビットコイン界隈に震撼を与えたColdcardの脆弱性発覚の陰で、ビットコインを利用する上で広く採用されていたインフラを揺るがす事件が相次いで発生していました。

ノンカストディアルなスワップサービスを提供するBoltzは脆弱性対応のためにサービスを停止し、彼らのOSS（オープンソースソフトウェア）を利用していた別のプロジェクトもほぼすべてが一時的にスワップの提供を取り下げました。また、セルフカストディ型の決済ソリューションであるBTCPay Serverにも深刻な脆弱性があったことがユーザーからの資金盗難の報告により発覚したため、緊急アップデートがリリースされる騒ぎとなりました。

その後、今に至るまで、ビットコインに関わる多くのOSSにおいて脆弱性対応のリリースが相次いでいます。最近印象的だったのは、Blockstreamが開発を主導するライトニングノード実装「CLN（Core Lightning）」が脆弱性修正リリースをクローズドソースで公開したことです。変更内容をコンパイル前のコードとして公表してしまうとすぐに悪用されてしまう恐れがあるので、時間を稼ぐためにリリースから２週間は「開発陣を信じてアップデートするか、信用できるノードとのみ接続するよう確実に設定する」という選択をユーザーにさせる形です。

💡

この記事の執筆中に、Liquid Networkノードの脆弱性とSideswapというサービスの運用の甘さが突かれて4000BTC流出するという事件も発生しました。

これらの攻撃や脆弱性発覚の背景にあるのは、AIによる脆弱性分析や攻撃コードの生成能力の大幅な改善です。特に今年に入ってリリースされたAIモデルは、対象の技術に精通した攻撃者が利用すると、プログラムのコードに潜む脆弱性をあぶりだすことに長けています。OSSは定義上コードが公開されているので、そのような攻撃者が比較的簡単に狙うことができてしまうわけです。

ビットコインのエコシステムは「Don’t Trust, Verify」の精神を実現するために多くのソフトウェアがOSS、あるいは利用は制限されているがソースコードを提供する形で提供されています。これからのAI時代には、このやり方は難しくなっていくのでしょうか？

本稿ではAI時代のビットコインエコシステムとオープンソースについて、どのような未来をたどるのかについて、現在の出来事と未来予測を織り交ぜて考えてみます。

脆弱性発見のコストが大幅に低下している

2026年の前半、Claudeで知られるAnthropic社は自社が開発したMythosというAIモデルがサイバーセキュリティにおける脆弱性発見において驚異的な能力を発揮しているとして、全世界に先んじて銀行など特定企業にのみ提供するという判断を下しました。一般リリースにあたっては、一時は安全性を懸念した米国政府まで巻き込んで、最終的にはセーフガードを実装したFableというモデルとして公開することになりました。

💡

AI企業の「高性能すぎて危険すぎるモデル」アピールは、もちろん性能向上の事実も含んでいますが、マーケティングの側面も大きいことは意識しておくとよいと思います。

ChatGPT擁するOpenAI社なども追随して、米国の最上位AIモデルはセーフガードが搭載され、サイバーセキュリティ関連の質問には答えてくれなかったりするようになってしまったのですが、実はセーフガードなしで最上位モデルに匹敵する性能を利用する方法があります。中国政府はAI企業にセーフガードの搭載を義務付けていないため、中国のAIモデルを利用するのです。その代表例として、7月16日にリリースされたKimi K3というモデルは、Fable/Mythosに匹敵する性能をうたいます。

ちょうどKimi K3がリリースされた頃から、ビットコイン関連のOSSの脆弱性を発見して直そうという動きと、直される前に発見して悪用しようという動きが活発化しました。特にビットコイン研究所で以前に解説したColdcardの脆弱性発覚後は、AnchorWatch社のRob Hamilton氏が主導してBitcoin Red Teamと呼ばれるボランティアによるOSSの脆弱性修正活動が活発化しました。

I have spent over $10,000 scanning 100+ bitcoin ecosystem related libraries looking for vulnerabilities with Kimi K3 running as quarterback.

Myself and a small "Red Team" have found multiple serious vulnerabilities impacting the ecosystem. They vary in scope severity, but this…
— Rob Hamilton 🟥 (@Rob1Ham) August 3, 2026

OSSの脅威モデルとしては、公開されているコード内の脆弱性を攻撃者が見つける可能性があるという点では以前と何も変わりません。変わってしまったのは、脆弱性を見つける人的コストがこのように大幅に低下してしまったことです。

もちろん、守る側についても同じことが言えるので、コードをリリースする前に脆弱性を発見することも以前より大幅に簡単になりました。しかし、今あるコードの大半はAIによるレビューを経たものではないので、短期的には攻撃者有利という状況があります。

💡

リリースごとの診断コストを誰が負担するのかという問題のほかに、LLMの特徴の１つであるランダム性がゆえにリリース前に脆弱性を確実に発見しきることはできないと思われるため、今後もこのタイプの攻撃手法は完全にはなくならないでしょう。

発覚した脆弱性をどう修正しリリースすべきか？

今回、Coldcardの事件やBTCPay Server、Core Lightningの脆弱性修正のすべてに当てはまる大きな問いが生まれました。AIがすぐ脆弱性を見つけてしまう時代に、どうやって脆弱性修正を公表しリリースするのか？というものです。

例えばColdcardの場合は過去に生成されたシードに脆弱性があるため、ユーザーの資産を保全するには別のシードを生成して資金を移してもらう必要がありました。しかし、開発元が「Coldcardユーザーは新しいシードへの移行を」と発表してしまうと、AIを使って原因となる脆弱性（しかもシード生成に関わるものと推測される）を探す動きを誘発してしまいます。かといって、内密に移行の必要性を伝えていくにも限度があります。

OSSにおけるシード生成の脆弱性は原理的にかなり公開するのが難しいといえます。

💡

なお、Coldcardの場合は攻撃者が先に脆弱性に気づいたので公表プロセスは何もありませんでした。

BTCPayやCLNの場合は、通常はソースコードとともにバイナリ／コンテナ（実行ファイル）がリリースされ、ユーザーは自分でコードからビルドするか、ビルド済みのバイナリを利用することが選べます。しかし、今回は修正した内容を秘匿するために、リリース時点ではソースコードを公開しないことを決めました。

ユーザーは２つの選択肢を迫られる形となります。BTCPayやCLNの開発者を信じ、内容がわからないソフトウェアを実行するか、コードの公開を待つ間は実行しているソフトウェアを停止するか。（※CLNの場合は停止よりも安全な実行モードの案内もありました）

これはOSSとしては非常によくない形です。「Don't Trust, Verify」を諦める形になるためです。しかし、他にマシなやり方があったかというと、なかったのかもしれません。

この施策は多少は時間を稼ぐことができたようです。例えばCLNはリリースの２週間後にソースコードも公開しましたが、リリースしたバイナリからソースコードがデコンパイル（復元）されてしまうのには数日かかったそうなので、CLNユーザーは最初の数日は対応策を検討したり実行する時間があったことになります。しかし、AIの性能が改善していくと考えると、この方法が今後どれくらい有効かはわかりません。

これらのケースに共通した問題は、脆弱性修正の内容を公開してしまうと、脆弱性自体がすぐに解析されてしまい、攻撃につながることです。もはやコードを公開しなくてもそうなってしまうので恐ろしいです。

これから個人はどう対応したらよいのか

AIを使った脆弱性を攻撃者が突いてきたり、脆弱性修正が攻撃のきっかけになる時代に、私たち個人のビットコインユーザーはどう対応していくべきなのでしょうか？いくつか重要な心がけがあると考えています。

基本的なサイバーセキュリティは引き続き重要

ビットコインを扱う上で、フィッシングに遭わないための基本的なサイバーセキュリティ知識（メールの見分け方、検索よりブックマーク、複数情報源のクロスチェックなど）は従来より重要なことです。セルフカストディにしろ、取引所を利用するにしろ、ここをないがしろにしては危険です。

取引所を利用する際のセキュリティ対策について、２年前の記事ですが今も重要な内容です

ここに追加するとしたら、ご自身でAIを利用する場合も、AIがマルウェアの混入したソフトウェアをダウンロードしてきたりするリスクがあるので、ビットコイン関係のことをする端末とは極力分けてAIを利用するのがよいでしょう（特にAIエージェント）。チャットボットのみの利用であれば、ホストPCへのアクセスが難しいブラウザ内で利用するのも手です。AI提供会社の社員などログを見れる立場の人もいるので、AI利用時にセンシティブな情報を送信してしまわないようにも注意しましょう。

複数社のLLM利用をまとめて使い分けるための「ルーター」と呼ばれるサービスに至っては、利用者の送信したファイルのログを販売してしまうこともある模様

依存するソフトウェアを最小限にする

脆弱性はソフトウェアの数だけ、そしてそれらのソフトウェアが依存している先の別のソフトウェアの数だけ発見される可能性が高くなります。特に今はサプライチェーン攻撃と呼ばれる、ソフトウェアの部品として利用されるライブラリに悪意あるコードが混入してしまい、ソフトウェアをインストールした際に実行されてしまうという攻撃が流行しています。

対策の簡単な考え方としては、いらないソフトウェアは入れない、活発にメンテナンスされていないソフトウェアは入れない、入れているソフトウェアは定期的に見直す、ということになります。もしあなたがエンジニアであれば、依存先が多そうか少なそうか危なそうかなど、ご自身でもある程度判断できるかもしれません。

また、アップデートによって新しい脆弱性が入る可能性もありますが、既存の脆弱性の修正を含む場合もあるので、アップデートは基本的には追従したほうがよいと思います。（乗っ取りによるリリース対策など、ここは難しいところで正解はありません。従来は2日ほど待ってからアップデートするような対策が定石でした）

金額が大きい場合は特に、ビットコイン関連の作業は専用端末を用意して行うことも検討してもよいでしょう。普段遣いのパソコンやスマホはどうしても他のソフトウェアがリスク要因となります。

コールドウォレットは桁違いに安全

Coldcardの脆弱性はともかく、Boltz・BTCPay Server・Core Lightning・Liquid Network/Sideswapの共通点は「常時オンラインのホットウォレットとして機能し、他人からのアクセスを受け付ける」という非常に攻撃者に有利なタイプのソフトウェアであることです。逆にいえば、外部からアクセスできないものはAIを使っても攻撃するのは困難です。そう考えると、ライトニングノードなどは少しリスクが高めともいえます。

したがって、適切にコールドウォレットを運用して資産の大部分はそこに保管しましょう。シード生成についても最近いくつか記事が出ていますので、そちらも参考にセルフカストディ体制を検討してみてください。

💡

今はオープンソースソフトウェアから攻撃が始まっているためセルフカストディに不安を抱いている方が多いと思いますが、これからは取引所などに標的が移っていく可能性も高いと思います。これまでも多かったソーシャルエンジニアリングに加えて、今後１～２年は取引所に対する技術的なハックが増えるかもしれません。

余裕があれば脆弱性についての情報収集体制を構築する

最後に、脆弱性修正をどうやって公表するかについての問題は未解決問題です。したがって、いまできる一番いいことは「いち早く情報を入手できるようにしておく」ことでしょう。そうすれば攻撃方法が明らかになる前に対応できる可能性が高くなります。

例えば利用しているソフトウェアの開発元をXでフォローしておくなどの方法が考えられます。本当はこういうのを一元管理するアラートサービスみたいなのがあると嬉しいですね。

幸い、ライトニングノードを除けば一般的なビットコインユーザーが実行するソフトウェアは外部から接続できるようなものでないことが多いので、脆弱性修正のアップデートの緊急度はそれほど高くないかもしれません。対応速度はどちらかというと事業者やサービス運営者にとって非常に重要です。

💡

なお、脆弱性対策リリースが公開されても、アカウントが乗っ取られていないかのチェックは念入りにしたほうが良いでしょう。メールやツイートで不安を煽ってマルウェアを入れさせる攻撃が増えると思います。）

まとめ

AIによってオープンソースソフトウェア（OSS）の脆弱性を発見するコストが低下したことによって、既存のOSSが脆弱性対応に追われています。修正した内容を公表すると攻撃者に大きなヒントを与えてしまうという側面においても、どのように利用者にアップデートを促すかという課題があります。

一般的な利用者としては、フィッシングへの警戒や不要なソフトウェアを入れないなどこれまで同様のセキュリティ対策を徹底しつつ、AI利用時に不正なソフトウェアをダウンロードしたり、秘密情報を送信してしまわないために端末を分けるなどの対策が重要になります。

事業者やサービス運営者の場合は不特定多数からアクセスできてしまうソフトウェアを実行していることが多いので、脆弱性対応のアップデートに急いで対応できることが重要です。リリースが真正なものか慎重にチェックしつつ、いつでも対応できるように情報収集の仕組みを用意しておきましょう。

Liquid Networkの事例からもわかるように、ウォレットや取引所経由で被害に遭うリスクもあります。トータルで考えると、自前のコールドウォレットに保管するのが一番リスクは低いと考えます。

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び学士号取得。2016年末よりビットコインに関するリサーチや実験的な開発をしており、今までにいくつかのブログやサロンで解説を担当。ビットコインについて一番好きなところはパーミッションレスに誰でも使うことができること。 2024年11月より日本ビットコイン産業株式会社取締役。