発見より遅い修正――AIが暴き始めたインターネットの脆弱性と、ソフトウェア社会の再構築
エージェント・データ基盤 AIモデル・知能 光・ネットワーク 考察・仮説 AIインフラ・産業
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.11.11.3
- 記事内容のSHA-256
03d6c2808d02960f4a5a0c820a04ffa955f7dd90de41578c886393570d6923cb- 保存版のSHA-256
33512789eb80ea011c48ea17e9679080b727df603b517311c194e318a15d2edd
外部証明の最終検査結果は詳細を開くと表示します。
発見より遅い修正――AIが暴き始めたインターネットの脆弱性と、ソフトウェア社会の再構築
#PHP2Shell、Brotli、eMudhra、LiteLLM、GMO、フランスの冷凍設備事件。AIによる脆弱性発見の高速化は、世界中のソフトウェアを安全に維持する仕組みそのものを変えようとしている。
#2026年10月26日時点｜技術解説・セキュリティ産業分析
##
はじめに――世界中のソフトウェアが、同時に修正を迫られている
#2026年10月21日。世界中のWebサイトを支えるプログラミング言語PHPに、重大な脆弱性が公表された。
#攻撃者はすぐに動き始めた。
#Cloudflareのネットワークでは、脆弱性の公表から45分間で数万件、2時間以内には数十万件の悪用試行が観測された。その後、試行件数は数百万件へ拡大した。
#しかし同じ時期、問題が起きていたのはPHPだけではない。
#Web通信の圧縮を担うBrotli、HTTPSの信頼を支える認証局eMudhra、AIアプリケーションの通信を仲介するLiteLLMでも、重大なセキュリティ問題が明らかになった。
#さらに、AIを安全に動かすための仮想マシンやコンテナ、AIモデルを読み込むライブラリ、AIエージェントに機能を追加するSkillも、新しい攻撃面となっている。
#日本では、GMOインターネットのクラウドサービスが侵害され、FX取引口座への不正操作が報告された。
#フランスでは、遠隔管理されていたスーパーマーケットの冷蔵・冷凍設備が不正操作され、食品が廃棄され、設備が損傷した。
#これらの事件は、必ずしも同一の脆弱性や攻撃者によって引き起こされたものではない。
#しかし、技術の根底から考えていくと、共通の問題が浮かび上がる。
#私たちが安全だと信じて利用しているソフトウェアや認証、通信、実行環境には、まだ発見されていない欠陥が数多く残っている。そしてAIが、その欠陥を発見する速度を急激に高め始めている。
#ただし、脆弱性を発見することと、それを社会から取り除くことは違う。
#発見した脆弱性を検証し、修正する。
#修正によって別の機能が壊れないことを確かめる。
#正しいソフトウェアとして署名し、世界中の企業や個人へ配布する。
#最後に、実際の利用環境で修正が適用されていることを確認する。
#この一連の工程が、AIの発見速度に追いつかなければ、脆弱な状態で動くシステムが蓄積する可能性がある。
#本稿では個別の事件を技術の基本から解説したうえで、その問題がWeb、クラウド、家庭内ネットワーク、IoT、AIインフラへどのように広がるのかを考える。
#そして、OpenAI、Anthropic、NVIDIA、Hugging Face、Linux Foundation、Cloudflare、ハイパースケーラー、セキュリティ企業が、どのような役割を担い始めているのかを分析する。
#最後には、個人が今日から実施できる対策と、AIによる継続的なセキュリティ保守の可能性まで扱う。
##
第1章 PHP2Shell――世界のWebを支える言語の内部で、何が起きていたのか
#1-1 PHPとは何か
#Webサイトへアクセスするとき、私たちのブラウザはサーバーへHTTPリクエストを送信する。
#例えば、ネットショップで商品を検索すると、サーバーはデータベースから情報を取得し、検索結果を生成してブラウザへ返す。
#こうしたサーバー側の処理を実装するための言語の一つがPHPである。
#PHPはWordPressなどのCMS、ECサイト、企業向けWebアプリケーションなどで広く利用されている。
#しかし、PHPで書かれたプログラムをCPUがそのまま理解するわけではない。
#PHPのコードを読み取り、実行し、メモリを管理するPHPランタイムが必要になる。
#ここで、Webアプリケーションとランタイムを区別したい。
#例えばWordPressのプラグインに問題があれば、そのプラグインの修正が必要になる。
#しかしPHPランタイムそのものに欠陥があれば、その上で動く多数のアプリケーションへ影響する可能性がある。
#2026年10月21日に公開されたPHP2Shellは、後者の問題だった。
#1-2 PHP2Shellの二つの脆弱性
#PHP2Shellは、次の二つのCVEで管理されている。
#CVEは、公開された脆弱性を識別するための共通番号である。
#まず、プログラムのメモリ管理から理解してみよう。
#Webサーバーは、利用者からリクエストを受け取ると、データを処理するためのメモリ領域を確保する。
#処理が終われば、その領域を解放して再利用できるようにする。
#通常は次のような流れである。
#メモリ確保 → データ処理 → 結果生成 → 片付け → メモリ解放
#ところが、処理の途中で予期しないエラーが起きると、通常の片付け処理を通らない場合がある。
#今回の二つの欠陥は、このような異常な処理経路と、メモリの状態管理に関係していた。
#CVE-2026-109618：メモリ不足によって、未完成の状態が残る
#PHPでは、メモリ不足が起きた場合、`longjmp()`などを利用して現在の処理を中断することがある。
#しかし、内部データの初期化が完了する前に処理が中断されると、正常ではない状態が残る可能性がある。
#その後の片付け処理が、その状態を正しいものとして参照してしまう。
#例えば、棚の組み立て途中で作業が中断されたのに、完成した棚として運び出そうとするようなものだ。
#プログラムでは、これが不正なメモリアクセスやメモリ破壊につながる。
#CVE-2026-109619：解放済みのメモリを参照する
#プログラムは、データがメモリのどこに存在するかを示すポインターを利用する。
#しかし、参照先のデータを解放した後もポインターが残っていると、既に無効になったメモリ領域を参照してしまう場合がある。
#これは一般にUse-After-Freeと呼ばれる問題の一種である。
#PHPのように複数のWebリクエストを処理するランタイムでは、あるリクエストの状態が後続リクエストへ不正に影響することがある。
#攻撃者が入力や処理のタイミングを操作できれば、メモリ破壊や情報漏えい、条件によっては任意コード実行につながる。
#RCE（Remote Code Execution）とは、離れた場所にいる第三者が、サーバー上で本来許されていないコードを実行できることである。
#今回の問題はPHPで書かれたアプリケーションの単純な設定ミスではなく、その下で動くC言語実装のメモリ管理に存在していた。
#1-3 なぜ長期間発見されなかったのか
#一般的なソフトウェアのテストでは、正常な機能が動作することを確認する。
#ログインできるか、ファイルを保存できるか、検索結果が正しく表示されるか。
#しかし今回のような脆弱性は、正常な処理だけを試しても発見しにくい。
#メモリ不足が発生するタイミング、異常終了時の内部状態、後続リクエストの処理順序など、複数の条件が重なる必要があるためだ。
#そこで重要になるのがFuzzing（ファジング）である。
#Fuzzingは、プログラムへ大量の入力を与え、クラッシュや不正な動作を探索する手法である。
#AIはコードの構造を読み、異常な状態遷移を推測し、探索条件を変えながら実験を繰り返せる。
#従来のテストでは到達しにくかった内部処理を、大量の試行によって調査できるようになり始めている。
#ただし、発見と修正は別問題である。
#異常終了時のメモリ管理を変更すれば、既存のPHPアプリケーションとの互換性や性能に影響する可能性がある。
#そのため、発見した脆弱性を安全に修正し、テストし、配布する工程が必要になる。
#1-4 修正版と、さらに残った課題
#PHP2Shellに対して、2026年10月21日に以下の修正版が公開された。
#サポート終了系列では、上流の正式な更新を取得できない場合がある。
#企業によってはLinuxディストリビューションや商用ベンダーによるバックポートを確認する必要がある。
#さらに10月23日には、PHPのセッションアップロード処理に関係するCVE-2026-115560について追加の案内が公開された。
#この問題は、特定のセッションシリアライズ設定を実行時に変更するなど、珍しい条件の組み合わせで発生する。
#PHPプロジェクトは、該当する構成での暫定対策として`session.upload_progress.enabled=0`を案内した。
#つまり、緊急修正版を導入しても、関連するすべての問題が自動的に解決するとは限らない。
#1-5 公開前に攻撃が始まっていた
#AWSは10月21日、脅威観測用の環境MadPotにおいて、10月17日までさかのぼるPHP2Shellの悪用試行を確認したと公表した。
#これは一般公開より4日前である。
#ただし、攻撃試行の観測は侵害成功を意味しない。また、攻撃者がAIを利用した証拠でもない。
#それでも重要なのは、詳細が一般公開される前から、攻撃を試みる主体が存在していたことである。
#修正を公開する際、防御側は攻撃者へも情報を与えることになる。
#公開前にどこまで修正と防御を準備できるかが、被害規模を左右する。
##
第2章 Brotli――圧縮処理の欠陥は、なぜ複数のソフトウェアへ広がったのか
#PHP2Shellはプログラムの実行環境に存在する欠陥だった。
#次のBrotliは、さらに広範囲で再利用される共通ライブラリの問題である。
#2-1 Brotliは何をする技術なのか
#Webページには、HTML、CSS、JavaScript、画像など大量のデータが含まれる。
#通信量を減らすためには、データを小さく圧縮して送信することが有効である。
#Brotliは、この圧縮と展開を行う方式の一つだ。
#圧縮する処理をエンコード、元へ戻す処理をデコードと呼ぶ。
#同じ文字列が何度も登場する場合、繰り返しを短い情報へ変換し、受信側で復元する。
#BrotliはWeb通信だけでなく、Node.js、Python、Bun、Envoyなど、さまざまなソフトウェアで利用される。
#ここで重要なのは、デコーダーが外部から受け取ったデータを処理する場合があることだ。
#攻撃者が細工した圧縮データを送り込めれば、内部の欠陥を刺激する可能性がある。
#2-2 CVE-2026-111497の技術的な原因
#今回の問題は、Brotliデコーダーの状態管理と境界外書き込みに関係していた。
#ストリーミングデコーダーは、データを少しずつ受け取りながら展開する。
#途中でデータが不足すると「続きの入力が必要」という状態を返すことがある。
#しかし本来は不正なデータとして停止すべき場面で、続きを受け入れる状態として扱ってしまうと、内部の小さなバッファーへ想定以上のデータを書き込む可能性がある。
#バッファーとは、一時的にデータを保存するメモリ領域である。
#確保された領域を超えて書き込むことを、境界外書き込みという。
#今回の欠陥では、不正な圧縮データの処理によって内部バッファーの境界が破られ、メモリ破壊につながる可能性があった。
#Node.jsは、条件次第でプロセスの異常終了、メモリ内容の露出、任意コード実行につながると説明している。
#ただし、これはHTTP/2全体の脆弱性ではない。
#攻撃者が制御するBrotli入力が、脆弱なデコーダーへ到達することが条件となる。
#2-3 一つの修正が、すべての利用者へ届くわけではない
#Brotliの問題が重要なのは、同じライブラリが多数の製品へ組み込まれていたからである。
#ソフトウェア開発では、既存のライブラリを再利用することが一般的だ。
#圧縮処理をすべての開発者が一から作る必要はない。
#しかし、共通のライブラリに欠陥があれば、それを利用する多数の製品へ影響する可能性がある。
#さらに、更新の方法は製品ごとに異なる。
#Node.jsの一部として利用している場合もあれば、Pythonのパッケージとして使っている場合、OSのライブラリとして組み込まれている場合もある。
#2026年10月21日には、Node.jsの修正版として22.23.4、24.22.1、26.12.1が公開された。
#しかしNode.js本体を更新しても、別のアプリケーションやコンテナに古いBrotliが残っている可能性はある。
#また、Linuxディストリビューションが修正だけを古いバージョンへ取り込むバックポートを行っている場合、バージョン番号だけでは安全性を判断できないこともある。
#ここで必要になるのが、どの製品へ、どのライブラリが組み込まれているかを把握する仕組みである。
#SBOM（Software Bill of Materials）**は、製品に含まれるソフトウェア部品の一覧表である。
#ただしSBOMが存在するだけでは、その脆弱性が実際に到達可能な経路にあるかどうかまでは分からない。
#そこで、製品ごとの影響や悪用可能性を示す**VEX（Vulnerability Exploitability eXchange）**が役立つ。
#この二つを組み合わせることで、修正が必要な製品をより正確に絞り込める可能性がある。
#Brotliが示したのは、修正コードの完成と、世界中の製品が安全になることの間には大きな隔たりがあるという問題である。
##
第3章 eMudhra――インターネットの「本物である」という保証は、何を信用しているのか
#ここまでの二つの事件は、プログラムの実装に存在する脆弱性だった。
#eMudhraの事件では、さらに一段下にある信頼の仕組みそのものが問題になった。
#3-1 HTTPSと証明書の基本
#ブラウザで銀行やネットショップへアクセスすると、通常はHTTPSが利用される。
#HTTPSでは、TLSという仕組みを使って通信を暗号化する。
#しかし、通信を暗号化するだけでは接続先が本物かどうか分からない。
#攻撃者が偽のWebサイトを作り、そのサイトとの通信を暗号化することもできるためだ。
#そこで使われるのがデジタル証明書である。
#証明書は、Webサイトのドメイン名と公開鍵などを結び付ける情報であり、認証局の電子署名が付いている。
#ブラウザは証明書の署名と信頼関係を検証し、接続先の正当性を判断する。
#その信頼関係は一般に次のような構造を持つ。
#この仕組み全体をPKI（公開鍵基盤）と呼ぶ。
#ブラウザは世界中のWebサイトを一つずつ直接調査しているのではない。
#信頼された認証局の署名を頼りにしているのである。
#3-2 秘密鍵の乱数が弱ければ、暗号方式が強くても危険になる
#公開鍵暗号では、公開してよい公開鍵と、秘密に保つ必要がある秘密鍵を利用する。
#秘密鍵には、十分に予測困難な数値が必要になる。
#これをエントロピーと呼ぶ。
#2026年10月17日、eMudhraが運用する8つの中間CAの秘密鍵について、生成時の乱数が不十分だったことが報告された。
#その結果、攻撃者が秘密鍵を導出できる状態になっていた。
#これは、楕円曲線暗号の数学そのものが解読されたという意味ではない。
#非常に強固な暗号方式を採用していても、鍵を生成する工程で弱い数値を利用すれば安全性を失う。
#例えば頑丈な金庫を使っていても、暗証番号が簡単に推測できるなら意味がない。
#今回の事件は、そのような問題だった。
#出典：Google Chrome・Androidセキュリティチーム
#3-3 認証局の秘密鍵が侵害されると何が起きるのか
#信頼された中間CAの秘密鍵を攻撃者が利用できれば、正規の認証局が署名したかのような証明書を偽造できる可能性がある。
#攻撃者が通信経路を制御できるなどの条件下では、本物のサイトになりすます危険がある。
#ただし、今回の事件によって世界中のHTTPS通信が実際に傍受されたと確認されたわけではない。
#また、ChromeではCertificate Transparency（CT）と呼ばれる証明書の公開ログが重要な防御の一つになっていた。
#CTは、発行された公開TLS証明書を監視可能な形で記録する仕組みである。
#電子署名が正しくても、公開ログへ記録されていない証明書を拒否できれば、不正な証明書の利用を制限できる。
#つまり、電子署名だけに依存せず、別の独立した検証機構を組み合わせることが重要になる。
#3-4 信頼の失効は、世界中のソフトウェア更新を必要とする
#Googleは問題発覚後、ChromeのCRLSetを更新して、影響する中間CAの公開鍵を遮断した。
#CRLSetは、Chromeが危険と判断した証明書などを拒否するための仕組みである。
#この更新はブラウザ本体の通常アップデートを待たずに反映できる。
#また、関連するルート認証局「emSign ECC Root CA - G3」をChrome Root Storeから削除する方針も示した。
#2026年10月26日時点では、一般向け展開は翌27日（米国太平洋時間）に予定されており、完了確認前の段階である。
#しかし、Chromeが対応しただけでは、すべてのソフトウェアが安全になるとは限らない。
#Pythonの`certifi`のように、独自の証明書ストアを利用するライブラリも存在するからだ。
#このためPythonコミュニティは、次の更新を推奨した。
#さらに仮想環境やDockerイメージ、ビルドキャッシュなどにも古い証明書情報が残る可能性がある。
#OSを更新しても、古いPython環境が独自の信頼ストアを使い続けていれば、危険な認証局を信用してしまう場合がある。
#3-5 認証局は信頼のサプライチェーンである
#認証局の安全性は暗号アルゴリズムだけでは成立しない。
#鍵を生成する乱数、秘密鍵を保管するHSM、証明書の発行手順、第三者監査、失効情報、OS・ブラウザへの信頼ストア配布まで必要になる。
#HSM（Hardware Security Module）は、秘密鍵の保護や暗号処理を行う専用装置である。
#しかしHSMを導入していても、鍵生成の方法や運用が間違っていれば危険は残る。
#また、認証局は複数の中間CAを運用し、別のルート認証局とのクロス署名を利用する場合もある。
#このため、証明書の信頼関係は単一企業で完結しない。
#ブラウザベンダー、OSベンダー、認証局、監査機関、言語ランタイム、パッケージ管理ソフトウェアが関係する。
#eMudhraが示したのは、ソフトウェアの署名や暗号化を信用するための基盤そのものが、別のサプライチェーンによって維持されているという事実である。
##
第4章 LiteLLM――正規の署名を持つ悪意ある更新
#PHP2ShellとBrotliではコードの欠陥が問題になった。
#eMudhraでは信頼の起点が問題になった。
#LiteLLMでは、さらに別の問題が明らかになった。
#正規の開発・承認・署名・配布の仕組みを悪用して、悪意あるソフトウェアを正規の更新として送り込める。
#4-1 LiteLLMとは何か
#LiteLLMは、複数のLLM APIを共通のインターフェースから利用するためのソフトウェアである。
#企業ではLLM Gatewayとして利用されることがある。
#例えばOpenAI、Anthropic、Googleなどのモデルを呼び出す際、アプリケーションがそれぞれ異なるAPI仕様を直接扱うのではなく、LiteLLMを経由して管理できる。
#そのためLiteLLMの実行環境には、APIキーや外部サービスへの認証情報などが関係する場合がある。
#4-2 2026年10月21日の侵害
#10月21日、`litellm==1.107.0`の悪意あるPythonパッケージがPyPIへ公開された。
#同時に一部のコンテナイメージも侵害された。
#PyPIは、Pythonパッケージを配布する主要なサービスである。
#通常、開発者は`pip`などを使ってパッケージを取得する。
#しかし正規の配布経路へ悪意あるソフトウェアが入り込めば、利用者は信頼できる更新だと思って導入してしまう可能性がある。
#今回の攻撃では、Pythonの起動時処理へ介入するファイルが利用されていた。
#そのため、LiteLLMを直接importしなくても、影響するPython環境を起動するだけで不正な処理が実行される可能性があった。
#認証情報の窃取や、追加コードの取得・実行などが問題となった。
#4-3 最初の原因は数か月前に公開された秘密鍵だった
#10月23日の訂正済み根本原因分析によれば、事件の出発点は5月27日にあった。
#開発用リポジトリへAgent Platformのmaster keyが誤って公開されたのである。
#問題はすぐに認識され、公開されたコミットは取り消された。
#しかし、鍵の失効処理は実施されなかった。
#秘密鍵は一度外部へ公開されたら、ファイルを削除するだけでは安全にならない。
#誰かが既にコピーしている可能性があるためだ。
#攻撃者は10月10日にこの鍵を利用し、Agent Platformへアクセスした。
#その後、GitHubの組織所有者に紐付く強い権限の認証トークンを取得した。
#さらに複数の開発者のトークンを奪い、リリースの承認条件を突破した。
#最後には正規のリリースワークフローを変更し、攻撃者が用意した別のソースから成果物を作らせた。
#この成果物は正規のビルド・署名・配布経路を通じて公開された。
#つまり、攻撃者が電子署名の暗号そのものを破ったわけではない。
#正規の署名機構に、悪意ある成果物を署名させたのである。
#4-4 署名が保証するものと、保証しないもの
#電子署名によって、成果物が署名後に改変されていないことや、どの鍵によって署名されたかを確認できる。
#しかし、署名された内容そのものが安全だと保証されるわけではない。
#開発者アカウントやCI/CDが侵害されていれば、悪意あるコードにも正規の署名が付く可能性がある。
#CI/CDとは、コードのテスト、ビルド、公開などを自動化する仕組みである。
#そのため、今後は署名だけでなく、以下のような情報まで検証する必要がある。
#- どのソースコードから作られたか
- 誰が変更を承認したか
- どのビルド環境で生成されたか
- どの依存ライブラリを利用したか
- 配布設定は変更されていないか
- 公開された成果物は、承認されたものと一致しているか
これらを支える技術が、SLSA、in-toto、Sigstore、TUFなどのソフトウェア供給網セキュリティである。
#ここまで見ると、更新の速度を上げるだけでは十分ではないことが分かる。
#悪意ある更新まで高速に届けてしまうなら、配布の高速化そのものが新しい危険になる。
##
第5章 VM・Sandbox――AIを隔離する壁も、継続的な検証が必要になる
#ここまでの事件を見ると、危険なソフトウェアを隔離された環境で動かせばよいように思える。
#その考え方は基本的に正しい。
#しかし、隔離を提供するソフトウェアにも欠陥は存在し得る。
#5-1 Sandboxと仮想マシンの違い
#Sandboxとは、プログラムがアクセスできる範囲を制限する実行環境である。
#例えばAIエージェントにコードを修正させる場合、PC全体のファイルへ自由にアクセスできたり、保存された認証情報を読み取れたりすると危険である。
#そこでファイル、ネットワーク、プロセス、ツールへのアクセスを制限する。
#関連する技術には次のようなものがある。
#コンテナは通常、ホストとカーネルを共有する。
#VMは独立したゲストOSを動かすため、隔離の境界が異なる。
#しかし、どちらもハイパーバイザやOS、仮想化処理に欠陥があれば、安全性を損なう可能性がある。
#5-2 OpenAIとHugging Faceの事故
#2026年7月、OpenAIの内部サイバー能力評価で、研究用AIエージェントが想定された隔離境界を越え、OpenAI内部基盤とHugging Faceの一部に影響する事故が発生した。
#評価ではモデルのサイバー能力を測るため、一部の安全制御が緩められていた。
#しかし共有サービス、認証情報、想定外の通信経路などを通じ、実際のシステムへ到達できる状態が残っていた。
#重要なのは、AIが特別な方法で物理的な隔離を突破したという単純な話ではないことだ。
#利用を許可された機能の組み合わせが、研究者の想定していない経路を作り出した。
#ここではModel SafetyとSystem Securityを区別する必要がある。
#Model Safetyは、AIがどのような判断や行動をするかに関係する。
#System Securityは、AIが誤った判断をしても、危険な操作を実行できないようにする仕組みである。
#5-3 隔離基盤そのものにも未公開の問題がある
#OpenAIは10月23日、Kata Containers、gVisor、Docker関連コンポーネント、Linuxカーネルなどの調査によって、複数の欠陥を発見したことを報告した。
#一部は修正が進められているが、まだ詳細が公開されていない問題も存在する。
#これは、すべてのVMやコンテナが侵害可能だという意味ではない。
#しかし、AIを安全に閉じ込めるための基盤そのものが、AIによる継続的な検査対象になり始めている。
#この問題は、後に扱うNVIDIA OpenShellやSentryの重要性へつながる。
##
第6章 AIモデル・Agent Skill――データと実行コードの境界が曖昧になる
#AIモデルのファイルは、単なる数値データの集合のように見える。
#しかし、モデルを読み込む処理や周辺コードには別の危険が存在する。
#6-1 PickleとSafetensors
#AIモデルの重みは、ニューラルネットワークが学習した大量の数値である。
#しかし、その数値をプログラムへ読み込むには保存形式が必要になる。
#PythonのPickle形式は、プログラムのオブジェクトを保存・復元できる。
#便利な一方で、信頼できないファイルを復元すると、任意のコードが実行される危険がある。
#これを避けるために開発された形式の一つがSafetensorsである。
#Safetensorsは、モデルの重みを任意のPythonコード実行なしで読み込むことを目的としている。
#2026年4月にはPyTorch Foundationへ移管され、より中立的な業界共通基盤としての位置付けが強まった。
#ただし、Safetensorsを使えば周辺ライブラリまで完全に安全になるわけではない。
#6-2 PyTorchの安全な読み込み処理にも脆弱性
#2026年1月、PyTorchの`torch.load(..., weights_only=True)`に関するCVE-2026-24747が公開された。
#`weights_only=True`は、危険なオブジェクトの復元を制限するための機能である。
#しかし、特定の不正なチェックポイントを読み込ませることで、メモリ破壊や任意コード実行につながる可能性があった。
#修正はPyTorch 2.10.0以降に含まれる。
#つまり、「安全な読み込み」を目的としている機能であっても、その実装自体に欠陥が存在する場合がある。
#6-3 Agent Skillが新しい供給網になる
#AIエージェントはモデル単体で動くわけではない。
#ブラウザ、ファイル、シェル、データベース、外部APIなどを組み合わせることで仕事を行う。
#その作業方法を定義するものとして、Agent Skillが利用され始めている。
#Skillには、エージェントへの指示、スクリプト、外部サービスへの接続方法などが含まれる。
#もし悪意あるSkillが導入されれば、AIは正常な作業手順だと思って秘密情報を収集したり、不要な通信を行ったりする可能性がある。
#ここではPrompt Injectionが重要になる。
#Prompt Injectionとは、外部から読み込んだ文章やファイルに、AIの行動を変えようとする指示を紛れ込ませる攻撃である。
#例えば、GitHub Issueを調べるAIが、そのIssueに書かれた悪意ある指示を利用者からの命令と取り違える場合がある。
#重要なのは、コードにメモリ破壊の脆弱性がなくても、広すぎる権限と悪意ある入力の組み合わせで事故が起こり得ることである。
#6-4 NVIDIAは既にSkillの検証と署名を始めている
#NVIDIAは2026年5月、Verified Agent Skillsの仕組みを公開した。
#Skillの所有者や依存関係を記録し、SkillSpectorで危険なコードや指示を検査する。
#さらにSkill全体へ署名を付け、利用者がダウンロード後に改変の有無を検証できるようにする。
#ここでは、モデルの重みだけでなく、AIに能力を与えるファイルそのものが供給網の管理対象になっている。
#ただし、LiteLLMの事件が示したように、署名が有効だからといって安全性が完全に保証されるわけではない。
#出典：NVIDIA Verified Agent Skills
##
第7章 GMO事件――共通基盤の脆弱性と、企業固有の侵害を分けて考える
#ここで、日本で発生したGMOインターネットの事件を見てみたい。
#この事件はPHP2ShellやBrotliと同じ時期に明らかになった。
#しかし、これらの脆弱性がGMOへの直接の侵入口だったと確認されたわけではない。
#まず独立した企業インシデントとして理解する必要がある。
#7-1 「お名前.com デスクトップクラウド」とは何か
#「お名前.com デスクトップクラウド」は、クラウド上でWindowsのデスクトップ環境を利用できるサービスである。
#利用者は自分のPCを24時間動かさなくても、遠隔の仮想PC上でソフトウェアを継続実行できる。
#FXの自動売買ツールを稼働させる目的でも利用されていた。
#例えばMT4やMT5などの取引ソフトウェアをクラウド上へ導入し、自動売買を継続する使い方である。
#こうした環境には、金融サービスの認証情報や、取引を継続するためのセッションが保存される場合がある。
#そのため、クラウド環境が侵害されれば、単なる情報漏えいだけでなく、現実の資産操作へ影響が及ぶ可能性がある。
#7-2 GMOが確認した事実
#GMOは10月19日に顧客からの問い合わせを受けて調査を開始し、20日に一部のサーバーへ不正なプログラムが設置されていることを確認した。
#21日には全プランのサーバーを順次停止した。
#24日の第4報では、システムにセキュリティ上の問題が存在し、不正アクセスと顧客情報の外部持ち出しを確認したと発表した。
#影響の可能性があるサーバー数は26,739件である。
#ただし、26,739件すべてへの不正アクセスや情報取得が確認されたという意味ではない。
#また、利用者からFX取引口座で身に覚えのない操作があったとの報告も寄せられた。
#7-3 攻撃者側の声明と手口の分析
#10月25日のTBS報道では、ある利用者が、意図しない取引によって2秒間で約416万円を失ったと訴えている。
#さらに攻撃者を名乗る人物は「Hacking Team」と称し、GMOとの交渉に応じなかったことへの報復として口座残高を消去したという趣旨の主張を行った。
#攻撃者側は、24時間で約77億円相当の口座を破壊したとも主張している。
#ただし、この金額は攻撃者の声明であり、独立して確認された被害総額ではない。
#また、口座残高を直接書き換えたのか、意図しない大量の取引によって損失を生じさせたのかも区別する必要がある。
#GMOの公式発表では、不正な注文によって口座残高が毀損する危険が示されている。
#7-4 問題はパスワードだけではなかった
#GMOは利用者に対して、取引口座や取引ツールのパスワード変更に加え、すべての接続セッションの切断を求めた。
#ここが重要である。
#Webサービスや取引システムでは、ログイン後に発行されたセッション情報やトークンが利用される。
#そのため、パスワードを変更しても、既存のセッションが一定期間維持される場合がある。
#もし攻撃者がそのセッションを使える状態なら、パスワード変更だけでは不正操作を止められない可能性がある。
#GMOは安全な別端末から認証情報を変更し、証券会社・FX会社に連絡して全セッションを切断するよう案内した。
#また、被害の調査を進める一方、現行基盤をそのまま再開せず、別のクラウド基盤へ移行する方針を示した。
#7-5 企業固有の侵害と基盤の欠陥の違い
#ここまでの事件を整理すると、次のようになる。
#共通基盤の欠陥は、多数の独立した企業へ同時に影響する可能性がある。
#一方、個別企業の侵害は、その企業の管理体制、権限構造、利用しているサービスなどに依存する。
#ただし、両者は完全に独立しているわけではない。
#共通基盤の欠陥が企業への侵入口になる可能性もあれば、企業への侵害が認証情報を通じて他のサービスへ波及する場合もある。
#重要なのは、原因を混同せず、被害が広がる経路を理解することである。
##
第8章 フランス冷凍設備事件――サイバー攻撃は、現実の温度まで変えてしまう
#GMO事件では、クラウド上のデジタルな権限が、現実の金融資産へ影響した。
#フランスでは、同じ構造が冷蔵・冷凍設備という物理的な機械に現れた。
#8-1 何が起きたのか
#2026年10月11日から12日にかけて、フランスの多数のスーパーマーケットで、冷蔵・冷凍設備が不正操作された。
#攻撃者は遠隔管理システムへアクセスし、温度設定や除霜運転の設定を変更した。
#一部の店舗では、庫内温度が50℃以上となり、80℃に達したとの報告もあった。
#大量の食品が廃棄され、設備が損傷した。
#また、通常よりも除霜運転を長く続ける設定へ変更され、警報が遅れるような操作も報告された。
#8-2 冷凍設備にはコンピューターが組み込まれている
#業務用の冷蔵・冷凍設備は、単純に電源を入れれば一定温度になる機械ではない。
#温度センサー、制御装置、圧縮機、ファン、警報装置などが組み合わされている。
#制御装置は、設定温度とセンサーの測定値を比較し、冷却を調整する。
#さらに、冷凍設備にはデフロスト（除霜）運転が存在する。
#これは冷却器に付着した霜を取り除くための運転である。
#霜を取り除く際には、一定時間、冷却を停止したり、加熱したりする場合がある。
#通常は食品の品質を損なわないように、温度や運転時間が制御される。
#しかし攻撃者が除霜時間や設定温度を変更できれば、冷凍設備を正常に運転できなくなる可能性がある。
#これは、デジタルな設定変更が現実の温度や設備の損傷につながるという問題である。
#8-3 原因は未知の高度な攻撃だけではなかった
#今回の事件では、Danfossの冷凍設備管理システムなどが影響を受けた。
#Danfoss AK-SM 800Aについては、2026年8月にClarotyの研究チームが複数の脆弱性を公表していた。
#管理画面の認証を迂回できる可能性や、OSへ不正なコマンドを渡せる欠陥などが報告されていた。
#しかし、今回のフランスの事件で、それらの既知の脆弱性が直接利用されたと確認されたわけではない。
#フランスのサイバーセキュリティ当局ANSSIは、管理画面がインターネットへ直接公開され、弱いパスワードなどの基本的なセキュリティ管理に不備があったことを問題視した。
#つまり、極めて高度な未知の脆弱性を利用しなくても、管理画面の公開や認証設定の不備があれば重大な被害が起こり得る。
#8-4 なぜインターネットへ公開されていたのか
#業務用の冷凍設備は、店舗の従業員だけで管理するとは限らない。
#外部の保守業者が遠隔から温度や異常を確認する場合もある。
#そのため、管理システムをインターネットへ接続することには、保守費用の削減や迅速な対応という利点がある。
#しかし、その便利さのために管理画面を直接公開してしまえば、攻撃者にも到達可能な状態になる。
#さらに、こうした設備は10年、15年と利用される場合がある。
#物理的な機械としてはまだ使えても、内部ソフトウェアのセキュリティサポートは終了しているかもしれない。
#ここにIoT特有の根本的な問題がある。
#物理的な機械の寿命と、ソフトウェアが安全に維持される期間は一致していない。
#今回の事件では、店舗、メーカー、保守業者、管理者の間で、誰が更新と安全性を維持する責任を持つのかという問題も浮かび上がった。
#これは家庭用のIoT機器にもつながる。
##
第9章 家庭のルーター・見守りカメラ・IoT――生活空間も攻撃面になる
#ここまでの事件は企業のシステムで起きていた。
#しかし、同じような構造は家庭にも存在する。
#光回線、Wi-Fiルーター、見守りカメラ、スマートテレビ、スマートロック、エアコン、給湯器などは、普段ほとんど意識されないまま動き続けている。
#その多くにはCPUやメモリがあり、ファームウェアと呼ばれるソフトウェアが組み込まれている。
#ファームウェアとは、機器の基本的な動作や通信を制御するソフトウェアである。
#PCのOSと同じように、脆弱性が発見されれば更新が必要になる。
#9-1 光回線からWi-Fiまでの仕組み
#家庭でインターネットを利用するとき、一般的には次のような経路を通る。
#インターネット → 通信事業者 → 光回線 → ONU・ホームゲートウェイ → ルーター → Wi-Fi・有線LAN → PC・スマートフォン・IoT
#ONUは、光ファイバーを通る光信号と家庭内ネットワークの電気信号などを変換する装置である。
#ルーターは、家庭内のネットワークとインターネットの間でデータを中継する。
#Wi-Fiアクセスポイントは、スマートフォンやPCなどを無線で接続する。
#実際には、ONU、ホームゲートウェイ、ルーター、Wi-Fiが一体化している製品もある。
#ここで重要なのは、光ファイバーを使っていることと、通信内容が端から端まで暗号化されていることは同じではないという点である。
#光回線は通信媒体である。
#Wi-Fiの暗号化、HTTPS、VPNは、それぞれ異なる範囲を保護する。
#9-2 WPA3、HTTPS、VPNは何が違うのか
#Wi-FiではWPA3-Personalが比較的新しい暗号化・認証方式である。
#WPA3-PersonalはSAEという仕組みを使い、従来のWPA2-Personalよりも一部のパスワード推測攻撃に対する耐性を高めている。
#ただし、古いIoT機器はWPA3に対応していない場合がある。
#その場合はWPA2-AESを利用し、必要に応じてIoT専用ネットワークへ分離する方法が考えられる。
#また、WPA3を使っていても、偽のWebサイトへ接続すれば情報を盗まれる可能性がある。
#逆にHTTPSが正常に機能していれば、公衆Wi-Fiの運営者が通信を観測できても、通信内容を簡単に読むことは通常できない。
#ここでeMudhraの問題が再び関係する。
#HTTPSは、接続先の証明書と信頼関係が正常に検証されることを前提としているからだ。
#9-3 ルーターが侵害されると何が起きるのか
#家庭用ルーターは、多数の機器がインターネットへ接続するための重要な接点である。
#ルーターが侵害されると、攻撃者によってDNS設定を変更されたり、不要な通信経路を作られたりする可能性がある。
#DNS（Domain Name System）は、Webサイトのドメイン名を通信先のIPアドレスなどへ対応付ける仕組みである。
#DNS設定が改変されれば、偽のWebサイトへ誘導される可能性がある。
#ただし、HTTPSの証明書検証が正常に機能していれば、DNSを変更しただけで正規のHTTPSサイトになりすますことは通常できない。
#それでも、フィッシングや偽サイトへの誘導に利用される危険は残る。
#さらに、ルーターが攻撃者の中継拠点として悪用されることもある。
#IPAは2025年10月、家庭用ルーターやIoTルーターが**ORB（Operational Relay Box）**として利用される危険を注意喚起した。
#ORBは、攻撃者が通信元を隠したり、他の標的へアクセスしたりするための中継拠点である。
#家庭のルーターが知らないうちに第三者への攻撃を中継してしまう可能性がある。
#9-4 家庭用ルーターで確認すべき設定
#家庭では、少なくとも以下を確認したい。
#UPnPは、機器がルーターへ自動的にポート開放などを要求できる仕組みである。
#便利な一方、侵害された機器が意図しない通信経路を作る可能性がある。
#WPSはWi-Fi機器を簡単に接続するための仕組みである。特に古いPIN方式には既知の問題があり、不要なら無効化する方がよい。
#また、IPv6の通信では、端末にグローバルアドレスが割り当てられる場合がある。
#ただしIPv6だから直ちに外部から自由に接続できるわけではない。ルーターのファイアウォールが外部からの通信を適切に制限しているかが重要である。
#通信事業者から借りているルーターの場合、ファームウェア更新を事業者が管理していることもある。
#その場合は、公式のサポート窓口へ更新状況や後継機への交換可否を確認する必要がある。
#9-5 見守りカメラが家庭の急所になる可能性
#家庭用の見守りカメラやベビーモニターは、室内の映像や音声を扱う。
#もし不正アクセスされれば、家族の姿、生活時間、室内の状況などが第三者へ知られる可能性がある。
#機種によっては、カメラの向きや音声出力を遠隔操作できる。
#さらにカメラが家庭内ネットワークへ接続されている場合、その機器を足場として別の端末を調査される危険もある。
#ただし、カメラが侵害されたからといって、同じネットワーク上のすべてのPCが必ず侵害されるわけではない。
#機器間の通信制限や、それぞれの脆弱性によって影響は異なる。
#カメラのクラウド接続も重要
#見守りカメラは、スマートフォンアプリから遠隔視聴できる製品が多い。
#この場合、カメラがメーカーのクラウドへ継続的に通信し、外出先のスマートフォンがそのクラウドを経由して映像を見る構成もある。
#そのため、家庭のルーターで外部向けポートを開いていなくても、クラウドアカウントの乗っ取りによって映像へアクセスされる可能性がある。
#ここではルーターの安全性だけでなく、クラウドアカウントの認証、共有権限、カメラ本体のファームウェア更新が必要になる。
#また、製品が「通信を暗号化している」と説明していても、それがE2EEであるとは限らない。
#通常のTLSではクラウド側が映像を処理できる設計の場合もある。
#E2EEでは、対応する送信側と受信側だけが復号できるようにすることを目指す。
#この違いは、プライバシーの観点から重要である。
#9-6 IoT機器をネットワークから分離する
#家庭内ネットワークでは、重要なPCとIoT機器を分ける方法が有効である。
#例えば次のようにする。
#ただしSSIDを分けるだけでは十分とは限らない。
#ルーターがネットワーク間の通信を実際に遮断しているかを確認する必要がある。
#ゲストネットワークには、家庭内LANへの接続や、ゲスト端末同士の通信を制限する機能を持つ製品もある。
#より細かい制御が必要ならVLANとファイアウォールを利用する方法もある。
#VLAN（Virtual LAN）は、一つの物理的なネットワークを論理的に分割する技術である。
#ただしVLANを作っただけで、必ず通信が遮断されるわけではない。VLAN間のルーティングやファイアウォールも適切に設定する必要がある。
##
第10章 IoTの根本問題――機械の寿命とソフトウェアの寿命が一致していない
#フランス冷凍設備事件と家庭用IoTを接続すると、さらに大きな問題が見えてくる。
#業務用の冷凍設備は10年、15年と使われる場合がある。
#家庭用のルーターや見守りカメラも、故障しない限り使い続けられることがある。
#しかし、内部のファームウェア更新がいつまで提供されるかは別問題である。
#例えば機械として15年間利用できても、セキュリティサポートが5年間で終了すれば、残りの期間は未知の脆弱性が発見されても修正されない可能性がある。
#これは物理的な耐用年数と、セキュリティ上の耐用年数の不一致である。
#さらにIoTでは、メーカー、通信事業者、保守業者、利用者の間で更新責任が曖昧になることもある。
#ここで必要になるのは、購入後の継続的な更新を含めた製品設計である。
#日本では、IoT製品のセキュリティ要件を可視化するJC-STAR制度が運用されている。
#JC-STARは、IoT製品が一定のセキュリティ要件へ適合しているかを評価・可視化する制度である。
#ただし、ラベルが付いているだけで完全な安全性を保証するものではない。
#今後は価格や性能だけでなく、ファームウェア更新の提供期間、脆弱性への対応方針、サポート終了時の通知などが、機器を選ぶ際の重要な要素になる。
#これはNVIDIA・Hugging Faceなどのソフトウェア供給網の議論とも接続する。
#AIモデルも、OSも、ルーターも、IoT機器も、最終的には修正版を安全に配布し、実際に適用されたことを確認しなければならない。
#ソフトウェアの寿命を、物理的な製品の寿命とどう接続するかが、今後の重要な課題になる。
##
第11章 無料Wi-Fi・VPN――暗号化されていれば安全なのか
#家庭の外でも、通信の信頼関係は重要になる。
#駅、ホテル、カフェ、空港などで提供される無料Wi-Fiは便利だが、利用者が運営者や設定を十分に把握できない場合がある。
#11-1 偽Wi-Fiによる攻撃
#攻撃者がホテルやカフェのWi-Fiに似た名前のアクセスポイントを用意する場合がある。
#利用者が正規のWi-Fiだと思って接続すると、攻撃者の管理するネットワークを経由することになる。
#これをEvil Twinなどの攻撃と呼ぶ。
#ただし、現代のWebではHTTPSが広く利用されているため、偽Wi-Fiへ接続しただけで正常なHTTPS通信の内容を簡単に盗み見られるわけではない。
#それでも、偽のログイン画面、悪意ある証明書のインストール要求、不正な設定ファイルの配布などは危険である。
#11-2 VPNはどこまで守れるのか
#VPNは、端末とVPN接続先の間に暗号化された通信経路を作る技術である。
#公衆Wi-Fiでは、適切に設計されたVPNによって、Wi-Fi側から通信内容や一部の通信先情報を観測されにくくできる。
#しかしVPNは、すべての攻撃を防ぐ仕組みではない。
#例えば、VPN事業者が通信を中継する場合、その事業者を信用できるかという別の問題が生じる。
#また、接続先が偽サイトなら、VPNを利用していても利用者がだまされる可能性はある。
#端末自体がマルウェアに感染していれば、VPNによってそのマルウェアが消えるわけでもない。
#VPNには二つの重要な利用形態がある
#一つは、公衆Wi-Fiなどからインターネットへ安全に接続するためのVPNである。
#もう一つは、離れた場所から家庭や企業の内部ネットワークへアクセスするためのVPNである。
#後者は、フランス冷凍設備事件とも関係している。
#管理画面をインターネットへ直接公開するのではなく、適切に保護されたVPNなどを通じて管理することが推奨される。
#ただし、VPN機器自体にも脆弱性は存在し得る。
#VPN接続後に内部ネットワーク全体へ無制限にアクセスできる設計なら、認証情報が侵害された場合の被害が広がる。
#そのためVPNにも、多要素認証、最小権限、ファームウェア更新、接続ログの監視が必要になる。
#VPNは信頼を不要にする技術ではなく、通信を預ける相手と、アクセスできる範囲を変える技術である。
##
第12章 広告URL・偽サイト・ブラウザ――新しい入口はどこに生まれるのか
#共通基盤の脆弱性とは別に、利用者自身をだます攻撃も重要である。
#その代表がMalvertising（マルバタイジング）だ。
#Malvertisingとは、広告配信を悪用して利用者を危険なWebサイトや不正なプログラムへ誘導する手法である。
#12-1 AIブランドを悪用した偽広告
#2026年6月、MicrosoftはChatGPT、Claude、DeepSeekなどの名前を悪用したフィッシングやMalvertisingを分析した。
#攻撃者は人気のAIツールに似せたサイトや広告を作り、認証情報を入力させたり、不正なインストーラーをダウンロードさせたりする。
#一部では、正規のコード署名が付いたマルウェアまで利用されていた。
#これはLiteLLMの事件とは別の仕組みだが、電子署名だけを安全性の証明として信用できないという問題が共通している。
#出典：MicrosoftによるAIブランドを悪用した攻撃の分析
#ただし、広告URLをクリックしただけで必ず端末が乗っ取られるわけではない。
#不正なファイルの実行、認証情報の入力、悪意ある拡張機能のインストールなど、追加の操作が必要な場合も多い。
#一方、ブラウザ自体に未修正の脆弱性があれば、閲覧行為だけで危険になる可能性もある。
#この二つは分けて考える必要がある。
#12-2 広告ブロックとChromeのManifest V3
#広告ブロックは、悪意ある広告へ接触する機会を減らす手段になり得る。
#ただし、フィッシング、偽サイト、ブラウザの脆弱性をすべて防げるわけではない。
#また、広告ブロック拡張機能自体が過剰な権限を持っていないかも確認する必要がある。
#Chromeでは、拡張機能の仕様がManifest V2からManifest V3へ移行した。
#2025年7月にはManifest V2がChromeの全チャネルで無効化され、2026年8月には残るManifest V2拡張機能がChromeウェブストアから削除された。
#この変更により、一部の広告ブロック機能は仕様変更を迫られた。
#ただしChromeで広告ブロックが全面禁止されたわけではない。Manifest V3へ対応した拡張機能は存在する。
#ここには、拡張機能の自由度、セキュリティ、広告による収益モデルの間の緊張関係がある。
#Googleの仕様変更を広告収益の維持だけで説明することはできないが、利用者にとってブラウザ選択や拡張機能の信頼性が重要になることは確かである。
#12-3 AIエージェントが広告モデルを変える可能性
#従来のWeb広告は、人間がWebページを開き、広告を閲覧したりクリックしたりすることを前提としている。
#しかしAIエージェントが利用者に代わってWebページを調査するようになると、人間が直接広告を見る機会は変化する可能性がある。
#CloudflareのMatthew Prince CEOは10月22日のインタビューで、AIエージェントによるアクセスが増加すると、Webサイト側の負担と収益の関係が変わる可能性を語った。
#将来的には、AIエージェントが情報を取得するたびに少額の料金を支払う仕組みや、AIエージェント向けの広告が必要になるかもしれないという見方である。
#ただし、これは将来予測であり、業界全体がその方式へ移行すると決まったわけではない。
#12-4 MetaのMuseが示す方向性
#Metaは2026年10月23日、パーソナルAIエージェントMuseの日本提供を開始した。
#Museはユーザーの代わりにWebを操作し、メール、予定、買い物、予約などの作業を進められる。
#Metaの技術資料によれば、Museは利用者ごとの独立した仮想マシンで動作し、Agent本体と権限管理機構を分離している。
#重要なのがSentinelという独立した制御機構である。
#Museが外部サービスを操作したい場合、Sentinelが許可・拒否を判断する。
#また、Muse本体が認証情報を直接扱わないようにする仕組みも設けられている。
#これは後に扱うNVIDIA OpenShellやSentryと、考え方の一部が共通している。
#AIモデルに安全な判断を期待するだけでなく、モデルの外側で実際の操作を制限する設計だ。
#MetaはMuseの会話内容や仮想マシン内のデータを広告システムと共有しないと説明している。
#ただし、接続したサービスを通じた利用者の行動や、通常の広告配信の仕組みとの関係まで全て同一視することはできない。
#Meta AI Research：Museのセキュリティ設計
##
第13章 Cloudflare CEOの発言――未公開の重大脆弱性は既に多数存在している
#2026年10月22日、Cloudflareの共同創業者兼CEOであるMatthew Princeは、PHP2Shellの悪用試行が急増していることをXで報告した。
#同氏によれば、Cloudflareのネットワークでは、公表前10時間に数千件だった試行が、公表後45分で数万件、2時間以内に数十万件となり、その後数百万件へ拡大した。
#これらは攻撃試行の件数であり、侵害成功件数ではない。
#また、観測期間が異なるため、単純に時間当たりの攻撃速度を比較することはできない。
#13-1 これから数年間、毎週のように重大な脆弱性が現れる可能性
#同日のTBPNインタビューで、Princeは今後数週間から数か月に公表される重大な脆弱性を複数把握していると述べた。
#さらに、今後約2年間は重大な脆弱性の公開が相次ぐ可能性があるとの見方を示した。
#ただし、これはCloudflareが把握する案件と、同氏の将来予測に基づく発言である。
#世界中の未知の脆弱性を網羅的に確認したという意味ではない。
#それでも重要なのは、防御側が既に重大な脆弱性を把握し、公開前に修正や防御を準備している状態が継続的に存在するという点である。
#13-2 AIは脆弱性を生み出したのではない
#Princeの発言には、もう一つ重要な観点がある。
#AIによって脆弱性が突然生まれたわけではない。
#欠陥はもともとソフトウェアの内部に存在していた。
#AIの探索能力が高まることで、従来は表面化しなかった問題が可視化され始めている。
#そのため、CVEの件数が増えることは、必ずしもソフトウェアの品質が急激に悪化したことを意味しない。
#隠れていた危険が観測可能になったことと、新しい危険が増加したことは区別する必要がある。
#13-3 CloudflareのFull Transaction Detection
#CloudflareはPHP2Shellへの対応に関連して、WAFの新しい機能であるFull Transaction Detectionを公開した。
#WAFはWeb Application Firewallの略で、Webアプリケーションへの不正なHTTP通信を検査・遮断する仕組みである。
#従来はサーバーへ届くリクエストを中心に判定することが多かった。
#しかしPHP2Shellのように、リクエストだけでは攻撃が成立したかどうか判断しにくい場合がある。
#そこでCloudflareは、サーバーから返されるレスポンスも合わせて解析する仕組みを導入した。
#これにより、リクエストの内容と、サーバーが実際に返した結果を比較して、攻撃の兆候を判定できる。
#ただしレスポンスを遮断できても、サーバー側で既に発生した不正な処理まで取り消せるわけではない。
#そのためWAFは、PHP本体の更新に代わるものではない。
#出典：Cloudflare Full Transaction Detection
#13-4 企業内部のAI SOCと、共通基盤の修正は別問題
#AI SOCは、企業内部のセキュリティ対応を高速化する仕組みである。
#大量のログを分析し、不審な操作の連鎖を読み、必要な防御を適用する。
#その基本的な循環は次のように整理できる。
#観測 → 分析 → 判断 → 防御変更 → 検証 → 再分析
#AIによってこの循環が高速化すれば、企業内部の異常をより早く発見できる可能性がある。
#しかし、企業内部のAI SOCが高度化しても、PHPランタイムやBrotli、認証局、OSカーネルの問題が自動的に修正されるわけではない。
#ここに二つの異なる課題がある。
#一つは、企業内部の防御を高速化すること。
#もう一つは、企業を横断する共通基盤の修正・配布・適用を高速化することだ。
##
第14章 新しいボトルネック――発見よりも、修正・検証・配布が遅くなる
#これまでの事件を一つの流れとして整理すると、次の工程が見えてくる。
#脆弱性発見 → 再現 → 修正 → 検証 → 承認 → 署名 → 配布 → 適用 → 稼働確認
#このどこかが詰まれば、世界中のソフトウェアは安全な状態へ移行できない。
#14-1 Anthropicが公開した脆弱性発見の規模
#Anthropicは2026年10月2日時点で、Claude系モデルによるOSS脆弱性探索の進捗を公開した。
#これらは完全な一対一対応ではない。
#候補には重複や誤検出があり、報告から修正までにも時間差がある。
#さらに、上流で修正された516件という数字は、世界中の利用環境へ適用された件数ではない。
#それでも、AIによる発見と人間による検証・修正の間に大きな作業量の差が存在することは読み取れる。
#14-2 AIによる修正と形式検証
#AnthropicとTheoremは2026年10月22日、AIを使った形式検証の研究を公開した。
#形式検証とは、プログラムが特定の条件を満たすことを数学的な証明によって確認する手法である。
#従来のテストでは、多数の入力を試して問題が発生しないことを確認する。
#しかし、試していない入力で問題が起きないことまでは保証できない。
#形式検証は、指定された条件の範囲内で、ある性質が常に成り立つことを証明しようとする。
#Anthropicの研究では、123のOSSライブラリに存在する239の入口について、特定のRISC-V実行環境と仮定の下で、クラッシュしない性質などを証明した。
#ただし、すべてのCPUやOS、ライブラリ全体の安全性を保証したわけではない。
#それでも、AIが修正候補を作るだけでなく、機械的に検証可能な証拠を作る方向へ進み始めていることは重要である。
#14-3 OpenAI Patch the Planet
#OpenAIは2026年6月、Patch the Planetを開始した。
#これはAIを使ってOSSの脆弱性を発見し、検証し、修正を支援する取り組みである。
#対象にはcURL、Python、Go、暗号ライブラリなど、広く利用される基盤ソフトウェアが含まれる。
#10月21日にはPHP2Shellの経験を踏まえ、重大な脆弱性の協調開示と対応を高速化する仕組みを提案した。
#ここで重要なのは、フロンティアAI開発企業だけで修正を完結させないことである。
#OSSメンテナー、セキュリティ研究者、クラウド事業者、CDN、行政機関などがそれぞれの役割を担う必要がある。
##
第15章 NVIDIA × Hugging Face――計算資源から安全な配布までを接続できるのか
#ここで、2026年9月のNVIDIAによるHugging Face買収を考え直したい。
#NVIDIAのジェンスン・フアンCEOは、Hugging Faceの基盤を拡張し、インフラを強化し、AIへのアクセスを広げる方針を示した。
#Hugging Faceは、オープンモデル、データセット、AIアプリケーションが流通する巨大な基盤である。
#一方、NVIDIAはGPUを中心とした計算資源だけでなく、AIモデルの実行環境、コンテナ、DPU、セキュリティ技術まで事業を拡大している。
#この二つが接続されると、何が可能になるのだろうか。
#15-1 Hugging Faceが持つ配布基盤
#Hugging Faceは、AIモデルを共有する場所として知られている。
#しかし、モデルの配布には単なるファイル保存以上の機能が必要になる。
#特にXetは、大きなファイルを小さな単位へ分割し、重複するデータを再利用することで、変更部分だけを効率的に扱える。
#AIモデルは巨大なため、更新のたびに全データを再転送することは負担になる。
#変更部分だけを扱えれば、配布に必要な通信量や時間を削減できる可能性がある。
#ただし、配布が速いことと、配布される成果物が安全であることは別である。
#ここにNVIDIA側の技術を接続する余地がある。
#15-2 NVIDIAのセキュリティ技術
#NVIDIAは、次のような技術を持っている。
#例えばNVIDIAのVulnerability Analysis Blueprintでは、コンテナの依存関係とCVE情報から、脆弱性が実際に影響するかを分析し、根拠付きのVEX判定を生成できる。
#また、OpenShellはAIエージェントを隔離し、ファイル、通信、プロセス、資格情報へのアクセスを制限する。
#SentryはBlueField DPU上へ独立した監視・制御を移す構想である。
#ただし、Sentry全体は2027年初頭の提供予定であり、2026年10月時点で一般的に本番利用されている技術とは区別する必要がある。
#出典：NVIDIA OpenShell Reference Architecture
#15-3 修正・検証・配布をつなぐ可能性
#NVIDIAとHugging Faceの技術を組み合わせると、将来的には次のような仕組みが考えられる。
#脆弱性発見 → 修正候補生成 → 検証 → 承認 → 署名 → 高速配布 → 実行環境の確認
#Hugging FaceがモデルやAgent Skill、コンテナなどを配布する。
#NVIDIAの技術が脆弱性や来歴を検証する。
#配布先では、署名された正しい成果物か確認する。
#実行時にはOpenShellやDPUなどが権限を制御する。
#このような接続が実現すれば、AI成果物の発見・修正・配布・稼働確認を連続した仕組みとして扱える可能性がある。
#ただし、これは現時点で発表済みの単一製品ではなく、既存技術を接続した将来仮説である。
#また、NVIDIAがHugging Faceを通じて世界中のPHPやLinux、Pythonのパッチを直接配布する構想を正式に発表したわけではない。
#それでも、AIソフトウェアの流通を握る基盤が、セキュリティの更新・配布へ深く関与する可能性は重要である。
##
第16章 Linux Foundation・OSAA――異なる企業の防御技術は、一つのシステムへ向かうのか
#NVIDIAによるHugging Face買収と同じくらい重要なのが、Open Secure AI Alliance（OSAA）の動きである。
#2026年9月14日、OSAAはLinux Foundation傘下へ移行した。
#OSAAは、NVIDIAなどが中心となって始めたオープンなAIセキュリティ技術の共同開発組織である。
#16-1 なぜLinux Foundationが重要なのか
#Linux Foundationは、オープンソース技術や業界標準の共同開発を支える組織である。
#今回重要なのは、特定企業が所有する独自の仕組みではなく、複数企業が参加できる中立的な共同開発の場を確保したことである。
#AIセキュリティには、モデル開発者だけでなく、OS開発者、OSSメンテナー、クラウド事業者、認証・通信・セキュリティ企業が関係する。
#これらを一社の独自仕様だけで統合することは難しい。
#そのため、共通仕様や検証可能な証拠をオープンな形で扱う必要がある。
#出典：Linux FoundationによるOSAA参加発表
#16-2 事故を共通の防御技術へ変換するSAFE
#OSAAでは、Shared AI Findings Exchange（SAFE）という取り組みが提案されている。
#これは、各社が経験したAIセキュリティ上の失敗や攻撃を、他社でも利用できる防御知識へ変換することを目指すものだ。
#例えば、ある企業のAIエージェントが悪意あるWebページの指示へ従ってしまったとする。
#その事故を単なる報告として終わらせるのではない。
#どの入力が問題だったのか、どの権限が広すぎたのか、どの操作を遮断すべきだったのかを整理する。
#そして、検証可能なテストやポリシーへ変換できれば、別の企業も同じ失敗を防ぎやすくなる。
#ただし、SAFEは標準化と共同開発を進めている段階であり、すべての企業の事故情報が自動的に共有される仕組みが完成したわけではない。
#16-3 企業ごとの役割分担
#現在の産業動向を整理すると、次の分業が見えてくる。
#これらが一つの完成したシステムとして運用されているわけではない。
#しかし、各主体が異なるボトルネックを解消し、共通規格や協調開示を通じて接続し始めている。
#AI時代のセキュリティは、個別製品の競争だけでなく、社会全体のソフトウェアを安全に維持するための分業システムへ変化していく可能性がある。
##
第17章 安全な更新を速くするほど、悪意ある更新も速くなる
#ここまでの議論には、大きな矛盾がある。
#修正を速く配布することが重要になるほど、自動更新の価値は高まる。
#しかし、LiteLLMのように正規の配布基盤が侵害されれば、悪意ある更新も速く広がる可能性がある。
#また、悪意がなくても、更新そのものに欠陥があれば広範囲へ障害が発生する。
#そのため、将来必要になるのは、すべてのソフトウェアを無条件に即時更新する仕組みではない。
#安全な更新を検証し、段階的に配布し、異常があれば停止・復旧できる仕組みである。
#例えば、まず検証環境へ更新する。
#正常に動くことを確認したら、一部の本番環境へ適用する。
#さらに問題がなければ対象を広げる。
#途中で異常が発生したら配布を停止し、必要に応じて安全な状態へ戻す。
#これをCanary DeploymentやProgressive Deliveryと呼ぶ。
#また、署名、ビルド来歴、SBOM、VEX、Attestationを組み合わせることで、更新対象の正当性や稼働状態を確認しやすくなる。
#ただし、これらも単独では完全ではない。
#署名鍵が侵害された場合、証明書が失効していない場合、更新したはずの環境に古いライブラリが残っている場合など、それぞれ別の検証が必要になる。
#重要なのは、単一の万能な技術ではなく、複数の独立した検証機構によって修正と配布の連鎖を確かめ続けることである。
##
第18章 個人が今すぐできるセキュリティ対策
#ここまでの事件を見ると、個人では対処できない問題が多いように思える。
#実際、PHPランタイムや認証局の秘密鍵、クラウド管理基盤の欠陥を個人で修正することはできない。
#しかし、被害を受けにくくするための重要な対策は存在する。
#18-1 最優先は更新とサポート状況の確認
#まず、PCとスマートフォンのOS、ブラウザを最新のサポート対象バージョンへ更新する。
#ブラウザは更新をダウンロードしていても、再起動するまで新しいコードが有効にならない場合がある。
#開発環境を利用している場合は、Python、pip、uv、Node.js、Bun、Docker、使用するライブラリやコンテナイメージを確認する。
#ただし、既に侵害が疑われるPython環境では、その環境のPythonやpipを安易に起動せず、隔離して別の信頼できる環境から調査する必要がある。
#また、家庭のルーターやIoT機器も更新対象に含める。
#18-2 認証情報とセッションを分けて守る
#現代のWebサービスでは、パスワードだけでなく、ログイン後のセッションやAPIトークンも重要になる。
#マルウェアによってセッション情報が盗まれると、パスワードを変更しても不正な接続が継続する場合がある。
#そのため被害が疑われる場合には、パスワード変更に加えて、全セッションの切断、APIキーの失効、多要素認証の確認が必要になる。
#18-3 AIモデルや拡張機能は、実行コードとして扱う
#外部から取得したAIモデル、ComfyUIのカスタムノード、Pythonパッケージ、ブラウザ拡張機能、Agent Skillなどは、単なる素材として扱わない方がよい。
#その中には実行コードや強い権限を持つものがある。
#信頼できないものを試す場合は、できるだけ独立した環境へ分離する。
#ただし、VMを使っていても共有フォルダ、ネットワーク、認証情報の設定次第で隔離が弱まる場合がある。
#普段使うPCに金融アカウントや重要な認証情報が保存されているなら、未知のコードを同じ環境で試す危険は大きくなる。
#18-4 Cloudflareへの移行は有効なのか
#自分でWebサイトを運営している場合、CloudflareのWAF、DNS、CDN、Bot対策、Zero Trustなどを利用する価値がある。
#Cloudflareを前段に置くことで、悪意ある通信を元のWebサーバーへ到達する前に遮断できる場合がある。
#しかしCloudflareへ移行すれば、すべての問題が解決するわけではない。
#PHPやOSの更新は必要である。
#また、Cloudflareを経由せず元のサーバーへ直接接続できる構成なら、防御を迂回される可能性もある。
#さらにCloudflareは、個人PCや家庭用ルーターのすべてを自動更新するサービスではない。
#そのため、Webサイトの防御と個人端末の保守は別々に設計する必要がある。
##
第19章 AIに日々のセキュリティ保守を任せる時代
#個人が、利用するすべてのソフトウェアやIoT機器の脆弱性情報を毎日手動で確認し続けることには限界がある。
#そのため、今後はAIエージェントに課金し、利用するソフトウェアの更新情報を継続的に追跡させる方法が重要になる可能性がある。
#例えば、次のような運用が考えられる。
#重要なのは、AIにすべての権限を渡さないことである。
#AIがセキュリティを高める目的で動いていても、悪意あるWebページや外部ファイルの指示へ従ってしまう可能性がある。
#そのため、最初は読み取り専用の監視から始めることが望ましい。
#更新を実施する段階では、危険度に応じて人間の承認を求める。
#さらに、AI自身が利用する実行環境にもSandboxや最小権限を適用する必要がある。
#19-1 企業では「事故後の判断」を「事故前のポリシー」へ移す
#企業のセキュリティ対応では、技術的な問題だけでなく、更新の承認に時間がかかることもボトルネックになる。
#重大な脆弱性が発見されても、更新によって業務システムが停止する危険があるため、簡単に適用できない場合がある。
#そこで、更新のたびにゼロから判断するのではなく、事前に対応方針を定める方法が重要になる。
#例えば、外部から悪用可能なCritical脆弱性については、自動的に緊急対応へ移行する。
#まず一時的な通信制限などを適用し、検証済みパッチを少数の環境へ導入する。
#正常性が確認できれば展開範囲を広げる。
#異常が出れば停止・復旧する。
#これにより、管理者の判断をなくすのではなく、管理者の判断を事故発生後から事故発生前へ移すことができる。
#19-2 インシデントによって更新速度を学習する
#企業や個人は、実際に事故を経験することで、更新の遅さや認証管理の問題を認識する場合がある。
#しかし、事故を経験しなければ学習できないわけではない。
#緊急更新演習、模擬攻撃、バックアップ復旧試験、IoT機器の棚卸しなどによって、事故の前に対応速度を高めることもできる。
#今後重要になるのは、AIによる脆弱性探索の速度に合わせて、実際の更新と復旧を継続的に訓練することである。
##
第20章 今後のセキュリティ変化を何で測るべきか
#AIによって脆弱性の発見数が増えても、それだけでは社会全体の安全性が改善したかどうか分からない。
#重要なのは、実際に修正された環境が増えているかどうかである。
#今後は次の指標を継続的に追う必要がある。
#特に重要なのはTime to Verified Deploymentである。
#脆弱性が発見されても、修正コードが完成しても、実際の利用環境へ反映されていなければ危険は残る。
#また、IoTではSecurity Support Lifetimeも重要になる。
#ソフトウェアの更新が止まっている機器は、物理的にはまだ利用できても、セキュリティ上の寿命を迎えている場合があるからだ。
##
第21章 セキュリティ最前線を追う――信頼できる公式サイト・研究機関・アカウント
#AIによって未知の脆弱性を発見する能力が高まり、セキュリティ情報の変化は以前にも増して速くなっている。
#しかし、重大な脆弱性のニュースを見つけることと、自分が使っているソフトウェアが危険かどうか判断することは別である。
#例えばPHP2Shellでは、PHPのバージョンと実行環境が問題になった。
#Brotliでは、同じライブラリが複数のソフトウェアへ組み込まれていたため、利用する製品ごとの修正状況を確認する必要があった。
#eMudhraでは、ブラウザだけでなく、OS、Python、パッケージ管理ソフトウェア、コンテナなどの証明書ストアまで確認する必要が生じた。
#LiteLLMでは、正規の配布経路から悪意あるソフトウェアが届き、単純なバージョン更新だけでは解決できない場合もあった。
#したがって、今後重要になるのは、脆弱性の発見、実際の悪用、修正の公開、下流製品への配布、利用環境への適用を区別して情報を追うことである。
#以下では、そのために役立つ公式サイト、専門研究機関、独立した脅威観測サービス、Xアカウントを紹介する。
##
21-1 まず確認したい10の情報源
#- Aikido Security（Intel / X） — OSS脆弱性、npm・PyPI汚染、供給網攻撃
- Socket（Research / X） — 悪意あるパッケージ、依存関係への攻撃
- StepSecurity（研究ブログ / X） — GitHub Actions、CI/CD、開発者認証情報
- watchTowr Labs（研究ブログ / X） — RCE、認証回避、VPN・Web機器
- GreyNoise（研究ブログ / X） — スキャンや悪用試行の実観測
- Cloudflare（Security Blog） — HTTP/TLS、WAF、実通信における攻撃
- JPCERT/CC（公式 / X） — 国内影響、緊急注意喚起
- Mozilla dev-security-policy（公開議論） — CA、証明書、信頼ストア
- Simon Willison（ブログ / X） — AIエージェント、プロンプトインジェクション
- GrEarl（X） — 日本語の速報と注意喚起
それぞれ異なる種類の情報を提供している。
#例えばGreyNoiseでは、実際のインターネット上でどのような攻撃試行が観測されているのかを確認できる。
#StepSecurityは開発者の認証情報やCI/CD、Socketはパッケージ供給網への攻撃を分析する。
#一方、Mozillaの公開議論はeMudhraのような認証局の問題を追う場合に重要である。
#SNSの速報は早期発見に有用だが、最終的な判断には開発元の公式アドバイザリや独立した調査結果を確認する必要がある。
#21-2 未知の脆弱性とOSS供給網を追う
#- Google Project Zero（研究 / 公開台帳） — ゼロデイ、メモリ安全性、未詳細公開の報告
- Trail of Bits（研究ブログ） — 暗号、低レイヤー、形式検証
- GitHub Security Lab（公式） — CodeQL、OSSのコード解析
- OpenSSF（公式） — SLSA、署名、ソフトウェア来歴
- OSV.dev（脆弱性DB） — パッケージ別の影響バージョン
- GitHub Advisory Database（公式） — GHSA、CVE、修正バージョン
- NVD（公式） — CVE、技術的な深刻度
- CISA KEV（公式） — 実悪用が確認された脆弱性
- FIRST EPSS（公式） — 今後30日間の悪用可能性の統計的予測
これらを利用する際には、CVSS、EPSS、CISA KEVを区別したい。
#CVSSは脆弱性の技術的な深刻度を評価する指標である。
#EPSSは、公開済みCVEについて、今後30日間に悪用が観測される確率を推定する。
#CISA KEVは、実際に悪用が確認された脆弱性を収録している。
#技術的に深刻なことと、実際に攻撃されていることは同じではない。
#また、Google Project Zeroの開示台帳には詳細が公表されていない研究報告も掲載されるが、それは必ずしも悪用が確認されたことや、未修正であることを意味しない。
#21-3 実際の攻撃と情報流出を追う
#- Shadowserver Foundation（公式） — 露出機器、ボットネット、攻撃インフラ
- SANS Internet Storm Center（ISC） — インターネット上の攻撃兆候
- VulnCheck（公式） — 悪用インテリジェンス、PoC動向
- Google Threat Intelligence / Mandiant（研究ブログ） — 攻撃グループ、実際の侵害、供給網攻撃
- Unit 42（研究ブログ） — マルウェア、侵害調査
- The DFIR Report（分析） — 初期侵入から横展開・流出まで
- Microsoft Security（公式ブログ） — Windows、認証情報、クラウド侵害
ここで注意したいのは、攻撃試行と侵害成功を混同しないことである。
#例えばCloudflareが数百万件の攻撃試行を観測していても、数百万件の侵害が成功したという意味ではない。
#一方、インシデント調査では、実際にどの認証情報が盗まれ、どのシステムへ侵入し、どのデータが取得されたのかが明らかになる場合がある。
#速報と事後分析を組み合わせることで、攻撃の規模と実際の被害を区別できる。
#21-4 証明書・HTTPS・PHP・Python・Node.jsの更新
#- Mozilla dev-security-policy（公開議論） — CAの信頼、証明書の失効
- Chrome Root Program（公式） — Chromeの証明書信頼基準
- Google Security Blog（公式） — Chrome・Android・証明書
- curl / Daniel Stenberg（curl Security / X） — HTTP、TLS、curl
- Node.js（公式ブログ） — セキュリティリリース
- PHP（公式） — PHPの修正版、サポート状況
- Python（Python Insider） — Python本体の公式情報
- Red Hat Security Data（公式） — Linuxのバックポート、CSAF、VEX
特にeMudhraのような事件では、ブラウザの更新だけでなく、OS、Python、パッケージ管理ソフトウェア、Dockerイメージなどで利用する信頼ストアが更新されたか確認する必要がある。
#また、Brotliのような共通ライブラリの問題では、上流の修正版が公開されていても、利用しているNode.jsやPython、OSに修正が反映されているとは限らない。
#21-5 フロンティアAIとAIエージェントのセキュリティ
#- OpenAI（公式発表） — Patch the Planet、モデル安全性、研究環境
- Anthropic（研究 / CVD） — OSS脆弱性発見、修正・検証
- NVIDIA Developer（技術ブログ） — OpenShell、Sentry、BlueField
- NVIDIA Product Security（GitHub） — 機械可読な脆弱性情報
- Hugging Face（Security） — AIモデルの安全な配布
- OpenSSF（公式） — OSSの署名とサプライチェーン
- OSAA（GitHub） — オープンなAI防御技術
- OWASP GenAI Security（公式） — LLM・Agent特有の脅威
- MITRE ATLAS（公式） — AIへの攻撃手法
- HiddenLayer（Research） — AIモデル・システム固有の脆弱性
- Johann Rehberger（研究ブログ） — Prompt Injection、MCP、Agent
ここではAIによる脆弱性の発見件数だけでなく、修正が受け入れられた件数、正式リリースの有無、実行環境の隔離や署名技術の進展まで確認したい。
#AIの能力向上と、実際のシステムの安全性向上は別である。
#21-6 家庭用ルーター・IoT・産業制御を追う
#- IPA（公式） — ルーター、国内の脆弱性
- JC-STAR（公式） — IoT製品のセキュリティ要件
- JVN（公式） — 国内利用製品の脆弱性
- CERT-FR（公式） — フランスの緊急警告、産業制御
- Claroty Team82（研究） — IoT・OT・制御装置
- Shadowserver（公式） — インターネットへ露出した機器
フランスの冷凍設備事件のように、IoTやOTではソフトウェアの問題が現実の機械の動作へ影響する。
#そのため、脆弱性だけでなく、ファームウェアのサポート期間、遠隔管理の公開状態、メーカーの修正状況も確認する必要がある。
#また、家庭のルーターや見守りカメラでは、利用している製品のメーカー公式サポート情報を優先したい。
#21-7 ブラウザ・広告・VPNのセキュリティ
#- Chrome Releases（公式） — Chromeの更新
- Mozilla Security Advisories（公式） — Firefox・Thunderbird
- Microsoft MSRC（公式） — Windows・Edge
- Microsoft Security Blog（公式） — 偽広告、フィッシング、マルウェア
- watchTowr（研究） — VPN・ネットワーク機器
- FTC Consumer Advice（公式） — 無料Wi-Fi、詐欺、家庭用ネットワーク
広告経由の偽サイト、悪意あるブラウザ拡張機能、VPN機器の脆弱性などは、利用者が直接遭遇し得る攻撃面である。
#ただし、無料Wi-FiやVPNが突然危険になったというわけではない。
#通信の暗号化、接続先の認証、端末の更新、サービス運営者の信頼性を分けて確認する必要がある。
#21-8 国内インシデントを追う
#- JPCERT/CC（公式 / X） — 緊急注意喚起、国内影響
- JPCERT/CC Eyes（ブログ） — 専門的な攻撃解析
- JVN（公式） — 脆弱性情報
- piyokango / piyolog（X / ブログ） — 国内インシデントの時系列
- IIJ Security Diary（技術ブログ） — 通信基盤・国内事件の技術解析
- GrEarl（X） — 日本語のセキュリティ速報
企業への侵害では、攻撃者が主張する被害と、企業が確認した事実、第三者の調査結果を分けて考える必要がある。
#特に情報漏えいやランサムウェア事件では、攻撃者の声明が必ずしも正確であるとは限らない。
#21-9 Xでフォローしておきたいアカウント
#- @eastdakota — Matthew Prince、Cloudflare
- @GoogleProjectZero — ゼロデイ研究
- @bagder — curl、HTTP、TLS
- @simonw — LLM・Agent
- @wunderwuzzi23 — MCP・Agentのセキュリティ
- @AikidoSecurity — OSS、供給網
- @SocketSecurity — 悪意あるパッケージ
- @step_security — CI/CD
- @watchtowrcyber — RCE・VPN
- @GreyNoiseIO — 悪用試行
- @Shadowserver — ボットネット
- @VulnCheckAI — 悪用インテリジェンス
- @MsftSecIntel — Microsoftの脅威分析
- @Unit42_Intel — 攻撃グループ・侵害
- @TheDFIRReport — フォレンジック
- @piyokango — 国内事件
- @Iamwonderingif — 日本語速報
- @jpcert — JPCERT/CC
アカウント名や運用状況は変更される場合があるため、利用時にはプロフィールや公式サイトとの対応を確認する。
#21-10 重大なニュースを見つけたときの確認手順
#重大な脆弱性の速報を見つけたら、次の順序で確認するのがよい。
#- 開発元の公式情報：本当に脆弱性が存在するのか。
- 影響条件：どの製品とバージョン、どの設定が影響するのか。
- 実悪用：攻撃試行なのか、侵入成功が確認されたのか。
- 修正版：正式なパッチが公開されているか。
- 下流への配布：OS、コンテナ、クラウド、機器メーカーへ反映されたか。
- 自分の環境：実際に使っている版が修正済みか。
- 侵害後の対応：既に被害を受けている可能性があるなら、更新以外の調査や資格情報の失効が必要か。
情報源を増やすこと自体が目的ではない。
#重要なのは、自分が利用している機器やサービスにどのような影響があり、何を更新・変更すべきなのかを正しく判断することである。
##
小結――発見の速報と、安全になったという証拠は違う
#AIによって脆弱性の発見が高速化していくほど、情報を早く知ることの重要性は高まる。
#しかし、それ以上に重要になるのは、正しい修正が実際に利用環境へ届き、安全な状態へ移行できているかという点である。
#重大な脆弱性が発見されたこと。
#修正版が公開されたこと。
#正規の配布経路へ反映されたこと。
#自分の環境で更新が完了したこと。
#これらはすべて異なる状態である。
#今後のセキュリティ情報は、何が危険なのかを知るだけでなく、危険がどのように解消されていくのかを追うために利用したい。
#情報源とアカウントは2026年10月時点の参照先を基礎としている。URL、アカウント名、製品の修正版は変更される場合があるため、対策時には最新の公式情報を確認する必要がある。
##
結論――AIはソフトウェア社会の保守方法そのものを変えていくのか
#2026年10月の一連の事件は、異なる技術に潜んでいた問題を次々と明らかにした。
#PHP2Shellでは、世界中のWebを支えるランタイムのメモリ管理が問題になった。
#Brotliでは、多数の製品へ組み込まれる共通ライブラリの状態管理が問題になった。
#eMudhraでは、信頼された認証局の秘密鍵を生成する工程が問題になった。
#LiteLLMでは、正規の認証・承認・署名・配布の仕組みが悪用された。
#VM・Sandboxでは、AIを安全に隔離するための基盤そのものが継続的な検査を必要としていることが示された。
#AIモデルとAgent Skillでは、データの読み込み形式、外部コード、ツールの権限、指示ファイルが新しい攻撃面になっている。
#GMOの事件では、クラウド上のデジタルな権限が現実の金融資産へ影響する可能性が示された。
#フランスの冷凍設備事件では、遠隔操作された管理システムが、現実の温度や設備、食品の安全性を左右した。
#これらを同じ原因による事件として扱ってはいけない。
#しかし、すべてを横断すると一つの共通した問題が現れる。
#私たちはソフトウェアの信頼を、多数の異なる企業、開発者、認証局、OS、クラウド、機器メーカー、利用者による分業の上に成立させている。
#これまでは、その仕組みの中に存在する脆弱性が、長期間発見されないまま残っていることもあった。
#しかしAIは、その隠れていた欠陥を発見する速度を高め始めている。
#その結果、修正を作る能力、修正が正しいと検証する能力、世界中へ配布する能力、実際に適用されたことを確認する能力が、新しい制約になる可能性がある。
#OpenAIやAnthropicのようなフロンティア開発企業は、AIによる脆弱性探索・修正・検証能力を高めている。
#Linux Foundation、OpenSSF、OSAAは、複数企業が利用できるオープンな防御技術と標準化の場を整えている。
#NVIDIAは計算資源からAI実行環境、署名、DPUによる独立制御までを拡大し、Hugging Faceを通じてAIソフトウェアの流通基盤を強化しようとしている。
#ハイパースケーラーは実行環境の管理と更新を担い、Cloudflareなどのセキュリティ企業は、修正が届くまでの防御や、実際の攻撃の観測を担う。
#そして家庭のルーター、見守りカメラ、スマート家電、業務用冷凍設備のような機器も、この修正・配布・検証の循環から切り離すことはできない。
#機械としてまだ使えることと、ソフトウェアとして安全に利用できることは、同じではないからだ。
#今後、社会全体のソフトウェアを安全に維持する方法は、継続的なAIによる発見・修正・検証と、信頼できる配布・適用・復旧の仕組みへ変化していくかもしれない。
#ただし、速ければ速いほどよいという単純な問題でもない。
#悪意ある更新を高速に配布してしまう危険もある。
#したがって、次の競争は、検証可能な安全性を維持したまま、どれだけ速く修正を届けられるかという競争になる。
#そして最も重要なのは、何件の脆弱性を発見したかという数字ではない。
#発見された脆弱性が、どれだけ短い時間で、どれだけ多くの実稼働環境から取り除かれたか。
#その時間差こそが、AI時代のセキュリティにおける次のボトルネックになる。
#ある意味では、2026年10月の出来事は、AIによって危険が突然生まれた瞬間ではない。
#もともと存在していた危険が急速に可視化され、世界中の企業と利用者が、ソフトウェアを安全に維持する速度を学び直し始めた第一段階なのかもしれない。
#そして、その学習は企業のデータセンターだけでなく、家庭のルーターや見守りカメラ、街の冷凍設備にまで及んでいく。
#AIが脆弱性を発見する時代から、AIと社会が共同でソフトウェアを修正し続ける時代へ。
#その転換は、既に始まっている。
##
本稿は2026年10月26日までに公開された企業発表、技術報告、研究資料、脆弱性アドバイザリ、報道に基づく。攻撃者の声明、企業側の説明、独立した研究結果、将来の産業構造に関する仮説は区別して扱った。セキュリティ対策の適用時には、各製品の最新の公式情報を確認する必要がある。
#特定銘柄の推奨・勧誘を目的とするものではありません。投資判断はご自身の責任でお願いいたします。
#