PHP2Shell（PHP騒動）をMythosレディの観点から読み解く　～　3層モデルによる評価、国内外の対応比較と今後の推奨

コメントをどうぞ

2026年10月24日
AIWGメンバー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

エグゼクティブサマリー

  • 何が起きたか：PHP本体に、認証なしで任意コード実行（RCE）に至る可能性がある2件の重大な脆弱性（CVE-2026-109618／109619、通称PHP2Shell、CVSS v4.0で9.2）が見つかった。PHP 5.4以降、修正版より前のバージョンが影響を受ける。本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない［1］［23］。
  • AIの役割：Calif（OpenAIの「Patch the Planet」の中でGPT-5.6 Solを使用）、OpenAI、Wizが、それぞれAIを使って独立に発見した。欠陥自体は10年以上前からあった。Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している［1］［2］［3］。
  • 防御側の窓は開いたが、早く閉じた：発見から公開まで約2か月半あったが、10月20日に情報がリークし、公開の4日前（10月17日）から悪用の試みが観測されていた。公開から1日足らずで、攻撃の試みは数百万件規模に達した［10］［11］。
  • 国内外で予防停止が広がった：欧州では、複数の政府機関や公共サービスが予防的にサイトを停止した［17］［18］。日本でも首相と国家サイバー統括室が深夜に呼びかけ、省庁・自治体・銀行・交通まで停止が広がり、停止告知は502件を超えた。このうち285件は、調査対象のX上で再開告知を確認できなかったものであり、実際の停止継続件数とは一致しない可能性がある［26］［30］。
  • 被害：2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった。CISAのKEV（悪用が確認された脆弱性の一覧）にも未登録である［12］［31］。
  • 3層からの示唆：止める範囲と戻す速さには、第1層（資産管理・EOL管理）の成熟度が大きく影響したと考えられる。今回は、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。次は「攻撃側のAIが先に見つける」前提で、第2層（侵害前提の封じ込め）と第3層（VulnOps・CTEM）を同時に育てる必要がある。

1. Mythosレディの3層モデル

「Mythos」は、Anthropicが2026年4月に発表したAIモデル「Claude Mythos Preview」に由来する。このモデルが、脆弱性の発見から攻撃コードの作成までを機械の速度で行えることを示したことを受け、CSA・SANS・OWASPなどが2026年4月に緊急公開した文書「AI脆弱性の嵐（AI Vulnerability Storm）：『Mythosレディ』なセキュリティプログラムの構築」［36］が、「Mythosレディ」という言葉を広めた。同文書は言葉を明示的には定義していないが、AIによる脆弱性発見の急増に備えて、今すぐ取り組むべき対策を示している。

以前のブログ「Mythosレディとは何か」［33］は、同文書を踏まえ、これを「機械速度の攻撃が常態化した世界において、組織が生存できる状態を継続的に維持すること」と定義している。特定のAIモデルへの対抗策ではなく、その背後にある構造的なリスクに継続的に適応し続けられる組織の状態である。PHP2Shellでも、発見に使われたのはMythosではなく、他社のAIモデルだった［1］［3］。

同シリーズでは、Mythosレディの目的を「コントロール可能な状態」、すなわち攻撃を100%防ぐことは不可能でも、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することに置いている［33］［37］。そして、それを実現する道筋として、基本的なセキュリティ対策、ゼロトラスト、VulnOps・Agentic Control Planeの3層を定義している［37］。本書でも、この枠組みに沿ってPHP2Shellを評価する。

層主な内容役割
第1層
基本的なセキュリティ対策		資産管理、パッチ適用、ログ収集と保全、バックアップと復旧手順、インシデント対応手順他の層が機能するための土台。守る対象が分からなければ何も守れない
第2層
ゼロトラスト		守るべき資産（プロテクトサーフェス）ごとに「信頼せず、常に検証する」設計。最小権限、セグメンテーション、継続的な監視侵入される前提で、被害を封じ込め、攻撃者の難易度を構造的に上げる
第3層
VulnOps・CTEM・Agentic Control Plane		悪用される前に脆弱性を見つけ、事業への影響で優先順位を付けて直し続ける運用。AIを防御側にも組み込み、AIエージェントを統制する攻撃側と同じ速度で動き、誰が見つけた脆弱性でも、攻撃者より先に塞ぐ

なお、3層モデルは続編［37］で定義したもので、基本対策の重要性は第1回［33］、第3層のVulnOpsとCTEMの具体的な実装は続編-2［34］で詳しく論じている。この3層は「順番に完成させる」のではなく「同時に育てる」。第1層のログ基盤が第2層の継続的検証を支え、第2層の守るべき資産の定義が第3層の優先順位を決め、第3層で見つかった脆弱性が第1層のパッチ適用と第2層のポリシーに反映される。この循環が回っている状態がMythosレディである［37］。

2. PHP2Shellの概要

2.1 何が起きたか

  • 規模：PHP 5.4以降、修正版より前のバージョンが、2件のCVEの少なくとも一方の影響を受ける。影響を受けるCVEはバージョンによって異なる。PHPは世界のWebサイトの約70%で使われ、WordPress、Drupal、MediaWikiなどの土台になっている［1］。
  • 性質：本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない。攻撃の成立条件やリスクは、PHPの実行方式（mod_php、PHP-FPMなど）や構成も踏まえて評価する必要がある［1］［23］。
  • 影響：認証なしで任意コード実行（RCE）に至る可能性があるほか、他のリクエストのパスワード、トークン、APIキーを含むプロセスメモリを読み出せる可能性がある［1］。
  • 修正：PHP 8.5.12、8.4.27、8.3.36、8.2.35で修正。PHPの開発チームによる更新の対象外だったが、7.4・8.0・8.1には例外的なソースのバックポートが公開された［23］。

「PHP本体に起因する」ことの何が問題か

通常の脆弱性はアプリ（WordPressやEC-CUBE、自社開発のシステムなど）のコードの中にあり、アプリ側の対策で守ることができる。PHP2Shellは、PHP本体がリクエストを受け取って処理する段階に原因がある。このため、次の問題が生じる。

  1. アプリ側の対策だけでは防げない：入力チェック、ログイン認証、フレームワークのセキュリティ機能は、アプリのコードが動いて初めて効く。PHP2Shellは、構成によってはアプリのコードが動く前に成立し、PHPの開発チームは、セキュリティアドバイザリで、Apacheのmod_phpでそれを実証したと説明している［23］。アプリをどれだけ堅牢に作っても、それだけでは根本的な解決にならない［1］。
  2. アプリを最新にしても防げない：WordPressやEC-CUBE、プラグインを最新にしても、サーバのPHPが古いままでは防げない［31］。「CMSは最新だから大丈夫」という判断が通用しない。
  3. 直す責任がアプリの担当者の手を離れる：修正はPHP本体の更新でしか行えず、担当はサーバの管理者、レンタルサーバー事業者、委託先になる［31］。アプリの担当者やサイトの所有者が自分で直せない場合が多く、日本で「止める」以外の選択肢を持てなかった組織が多かった一因でもある。
  4. 見つけにくい：PHP本体の処理で起きるため、アプリのログにはほとんど手がかりが残らない可能性がある［1］。異常なリクエストやメモリ上限エラー、PHPのワーカーの異常終了など、サーバやプロセスの単位で見張る必要がある。
  5. 影響範囲が「PHPを使うものすべて」になる：特定のアプリの欠陥ではないため、PHPで動くものはアプリの種類を問わずすべて対象になる。PHPは他のソフトや機器に同梱されていることも多く、自社がPHPを使っていると認識していない場所まで影響が及ぶ［16］。

これを3層との関係でみると次のようになる。資産の把握をアプリやCMSの単位で止めず、その下で動く言語処理系やライブラリの単位まで持つ必要がある（第1層）。アプリの防御を越えられる前提で、サーバ上の権限やデータを最小化して被害を封じ込める（第2層）。検知もアプリのログだけに頼らず、サーバやプロセスの振る舞いで行う（第3層）。

2.2 発見から公開までの経緯

発見者は複数いる。最初に見つけたのはOpenAIの取り組みに参加していたCalif（8月1日）で、OpenAI自身とWizもそれぞれ独立に同じ問題にたどり着いた［2］［3］。

日付（2026年）出来事
7月30日Califが監査を開始［2］
8月1日Califの説明による発見日［2］
8月11日Califの研究者が無条件のRCEを報告。同日、OpenAIも同じ根本原因を独自に報告［2］［5］
8月14〜15日CalifがRCEのPoCをPHPに共有し、PHPが確認［2］
8月19日Wizが独自に発見（Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを使用）［1］
8月24日WizがPHPに報告［1］
9月18日OpenAIが追加の攻撃経路を報告［2］
9月21日PHPが報告を受理し、協調した修正の開発に着手［1］
10月17日最初の悪用の試みをAmazonが観測（公開の4日前）［10］
10月20日脆弱性の存在とCVE番号がオンラインでリーク［7］［14］
10月21日予定を1日前倒しして修正版を公開（日本時間22時台。予定は23時）［7］［26］
10月23日PHPが、21日の修正版では直らない別のセッション処理の欠陥（CVE-2026-115560）を公表［12］（詳細は3.3）

OpenAIは、こうした最先端のAIが攻撃者より先に脆弱性を見つけたことで、PHPの開発チームやセキュリティ事業者が、公開前に修正と防御策を準備できる期間（「Defender’s Window」＝防御側の窓）が生まれたと説明している［3］［32］。Cloudflareは公開の9時間前に防御ルールを展開するなど、業界横断の準備が行われた［14］。

2.3 AIが変えたこと

  • 欠陥は10年以上前からあり、2024年の監査でも見つかっていたが、悪用できることは示されていなかった［2］。
  • Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している。複数の欠陥をつなぎ、標的ごとのメモリ配置に合わせて調整する作業を、AIの支援で数時間のうちに行えたという。Wizによれば、1人の研究者が1週間で、以前なら一流チームが数か月かかる作業を終えた［1］。
  • Wizは、AIによって攻撃コードの作成と標的ごとの調整の手間が下がり、複雑さはもはや防壁にならない可能性があり、「実際に悪用可能」の定義が変わると指摘している［1］。これを踏まえると、これまでの「人間が現実的な手間で攻撃コードを作れるか」という判断に加えて、「欠陥が存在し、外部から届くか」を重く見る必要があると考えられる。「悪用は困難」として後回しにされてきた脆弱性も、狙われる対象になりうる。

2.4 補足：CISAの「自動化可能性」評価

CISAは「Vulnrichment」というプログラムで、公開されたCVE記録に優先順位付けのための情報を追記している。その簡略版SSVCには「悪用状況」「自動化可能性（Automatable）」「技術的影響」の3つの判断項目がある。自動化可能性は、その脆弱性を自動で悪用でき、大量の攻撃が起こりうるかを問う項目である［9］。

PHP2Shellの公開時の記録では、悪用状況は「観測なし」、自動化可能性は「No」で、CVSSでも攻撃の複雑さは「高」とされていた［8］。これはメモリ破壊型の脆弱性として一般には妥当な評価である。ただし、Wizの研究で示されたように、AIが標的ごとの調整を支援できるようになったことは、従来の自動化可能性の評価の前提を見直す理由になる［1］。一方で、本件で攻撃全体の大量自動化が実証されたわけではなく、CISAの評価がAIによって無効になったと断定することはできない。

これらを踏まえて、公的機関の評価や点数は、公開時点の、人間の攻撃者を前提にしたスナップショットにすぎず、AIの時代には、それを鵜呑みにせず、自社の環境で継続的に評価し直す仕組み（CTEM）が必要であると考える。

3. 悪用の状況とAmazonの分析

3.1 Amazonの観測（MadPot）

Amazonは、自社の大規模なハニーポット網MadPotでの観測結果を公表した。毎分2,000億件を超えるイベントを分析し、MadPotからの脅威情報と組み合わせて攻撃を検知・遮断しているとしている［10］。

日時（UTC）日本時間観測内容［10］
10月17日10月17日最初の攻撃の試み。商用の匿名化ネットワークに関連するIPから。攻撃者による活動とみられるが、公開前に情報をどう入手したかは不明
10月21日 02:0021日 11:00最も早いPoCを確認
10月21日 02:00〜08:0021日 11:00〜17:00別の匿名化基盤からの攻撃が続く。ペイロードも手段もばらばらで、複数の攻撃者とみられる。成功したかは不明
10月21日 14:0021日 23:00情報公開の解禁とパッチ公開
解禁後 数時間22日未明追加のPoCが次々に現れ、ほぼ即座にセンサーへの攻撃に使われる

なお、Amazonは、識別した6つのIPアドレスを公表したが、これらは匿名化のための共有基盤であり、遮断ではなく、観測された場合の調査に使うよう求めている［10］。

3.2 Amazonが示した教訓と、見直すべき前提

教訓1：公開日まで情報を伏せておく取り決め（エンバーゴ）が防御側を守るのは、他の誰かが同じバグを見つけるまでに限られる。協調開示は今も正しいやり方だが、公開日を最も早い悪用の日と考えてはいけない。PHP2Shellでは、公開前に侵害されている可能性がある［10］。

教訓2：パッチから攻撃コードまでの時間は、構造的に縮んでいる。かつては少数の能力ある攻撃者が攻撃コードを作り、他はそれを待つ構造だったが、AIによる分析でパッチの差分やアドバイザリーから攻撃コードを作るのが簡単になり、数時間から数分で動ける攻撃者が増えている［10］。

見直すべき前提［10］内容
修正期限は時間単位で測る脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した［10］
調査は最も早い悪用の日から公開日ではなく、最も早く悪用が確認された日から調査する。PHP2Shellなら少なくとも10月17日から
シグネチャに頼らない検知最初の悪用は、特定のCVE向けのシグネチャができる前に来ることが多い

これを踏まえ、インターネットに公開された重大脆弱性では、攻撃が修正公開前または公開直後に始まる可能性を考慮し、従来の一律的な日数ベースの期限だけでなく、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。

3.3 公開後の状況

  • Cloudflareは、公開から45分で数万件、2時間で数十万件、10月22日早朝には数百万件の攻撃の試みを観測した。23日時点で3,440万以上のPHPサービスがなお脆弱とみられる［11］。
  • 攻撃者が管理するサーバ上で、PHP 8.4.26とApacheのmod_phpを狙った攻撃ツールと、標的のPHPのバージョン、サーバ構成、セッション設定、エラー表示の有無などが攻撃の前提条件を満たすかを調べるスクリプトが確認された。このツールは、メモリの漏えいを使ってASLR（メモリ上の配置をランダムにして攻撃を難しくするOSの防御機能）を回避する仕組みだった。報道によれば、調べられたサイトでは10月22日時点でシェルアクセスの証拠はなく、前提条件を満たしていなかったとみられる。この時点では、攻撃者のツールが成功するのは特定のバージョンや構成に限られていた可能性が高い［11］。
  • 一方、VulnCheckの研究者は、PHPが推奨する本番向けの設定（エラーを画面に表示しない設定など）でも、ASLRを回避してRCEを成立させる手法を示した。攻撃者のツールより広い条件で攻撃が成立しうることを意味し、攻撃者が同様の手法を取り入れれば、成功する範囲が広がるおそれがある。ただし、確実なRCEは当初の想定より難しいとの見方もあり、状況は流動的である［11］。
  • 10月23日時点で、CISAのKEVには2件とも未登録［12］。
  • 10月23日、PHPは別のセッション処理の欠陥（CVE-2026-115560）について情報提供の告知を出し、次の定期修正版が出るまでアップロード進捗機能を無効にしておくよう勧めた［12］［13］。PHP自身はこのリスクを「起こりにくい」と評価しており、悪用には特殊なアプリの作りが必要で、悪用も報告されていない［35］。アップロード進捗機能は、ファイルのアップロード中に進み具合を表示するためのもので、多くのサイトでは使われておらず、無効にしても通常の動作に影響はない。ただしPHPの標準設定では有効になっており、サイトが使っていなくても外部からのリクエストで動かせてしまうため、設定を確認して無効にしておくとよい［1］［13］［15］。

4. 海外の対応

  • 英国：NCSCの警告を受け、自治体やロンドン警視庁のサイトが停止。NCSCは、すぐにパッチや緩和策を入れられない場合はオフラインも検討するよう呼びかけた［17］。
  • オランダ：行政ポータル［19］［20］、市民が自分の個人データを確認するポータル、下院、NCSC自身、データ保護当局のサイトなどが停止［18］。認証基盤DigiDも止まり［20］、ロッテルダム港、サッカー協会、多数の病院も停止した［19］。
  • その他の欧州：フィンランドでは国のIT機関が政府の公開ウェブサービスを停止、フランスは内務省が自治体の行政サイトを停止、ドイツでも連邦のIT機関がサイトを停止［17］。デンマークでは全国の学校連絡プラットフォームにも影響［21］。スイスのホスティング事業者が顧客ポータルやWebメールを含めて停止し、Wikipediaも一時停止した［19］。
  • 欧州以外：カナダの担当相が一部サイトの一時停止を公表し、オーストラリアではサイバーセキュリティセンター自身も影響を受けた［20］。
  • 当局の方針：EUのCERT-EUは、すぐに更新できない場合は一時的にサイトを止めるよう助言［19］。米国のNSAと欧州のサイバーセキュリティ機関は即時対応を求め［6］、CISAもすぐにパッチを当てるよう呼びかけた［16］。
  • 停止の意味：止めた組織は侵入の兆候はないと説明しており、停止の一覧は被害の数ではなく、各組織の慎重さを表している［18］。
  • 資産把握の差：PHPの所在を把握している組織は必要な部分だけを止め、把握していない組織は全部を止めた結果、ウィーンではWebメールまで止まった、という指摘がある［18］。
  • 保険：英国の保険業界は、多数の契約者が同時に影響を受ける「集積リスク」として注視し、侵害がないまま自ら止めた場合に事業中断の補償が出るかも論点になっている［17］。

5. 日本の対応

5.1 時系列（日本時間）

日時出来事
21日 日中IPAが同日23時の修正版公開を予告し、PHPの利用状況を確認して速やかに適用できるよう準備を要請。攻撃は確認しておらず予防的な発信と説明［25］
21日 14時〜19時コドモンが14時ごろに全サービスを停止。BASEが15時50分、エックスサーバーが16時に公式サイトや管理画面を停止。19時にニコニコ、pixiv、ConoHa WINGなどが続く［26］
21日 21時44分／55分国家サイバー統括室（NCO）、続いて高市首相がXで対応を呼びかけ。首相は「今夜に対応して頂きたい大至急のお願い」とし、すぐ適用できない場合はサイトの一時停止も有効策の一つとした［26］
21日 22時台PHPの修正版が公開（予定は23時）［26］
21日深夜〜22日朝pixivが23時30分、コドモンが3時22分、BASEが8時に再開［26］
22日 日中国税庁が10時20分ごろに停止し16時10分ごろに再開［26］。気象庁なども一時停止［27］。官房長官は、政府系機関や基幹インフラの被害は現段階で報告されていないと述べた［26］
22日 13時11分JPCERT/CCが注意喚起。パッチ適用に加えて侵害の有無の調査を要請し、痕跡がなくても攻撃を受けていないとは断定できないとした［26］
23日 14時アシュアードの集計で停止告知は累計502件、再開告知を確認できたのは217件［30］

5.2 停止の規模と分野

  • 件数：X上の停止告知は502件、うち285件（約6割）は再開告知が未確認。ただし再開してもXで告知していない組織や、Xで停止を告知していない組織は反映されておらず、全体を網羅した数字ではない［30］。
  • 省庁：国税庁と気象庁のほか［27］、財務省と厚労省も一部サービスを停止［28］。
  • 自治体：札幌市が公式ホームページを止めて簡易サイトに切り替え、大阪府も検索機能を制限［28］。三重県では26サイトの公開や一部機能を停止し、8市6町にも影響［29］。
  • 金融：三菱UFJ銀行がネットバンキングの一部取引を停止し、地銀も一部アプリを停止、みずほ銀行も臨時メンテナンスを実施。一方、全国銀行協会は金融機関をつなぐオンラインシステムには影響がないと説明しており、止めたのは決済ではなく周辺サービスが中心だった［31］。
  • 交通・インフラ：JALはWebサイトの一部を予防的に閉じ、予約や運航への影響はないとした。九州電力はホームページを停止し、再開予定を延期した［31］。
  • サービス終了：古い仕組みで十分な対策が取れないとして、ゲーム2本がサービスを終了した［31］。

5.3 被害の状況

22日昼、バルテックが顧客情報流出の可能性を公表し、当初は原因を「PHPの脆弱性を標的とした攻撃」としていた［26］。しかしその後、これは誤報だったと訂正し、原因は自社サービスの脆弱性だと説明している。2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった［31］。

5.4 ホスティング事業者の対応の差

対応の型例［26］
利用者のサイトを止めずに更新さくらインターネット（21日23時からのメンテナンスで数秒程度の接続断のみ）、mixhost、カラフルボックス、Value-domain系、エックスサーバー（PHP 8.2〜8.5）
一時停止して更新し、再開ロリポップ!、ヘテムル、ムームー（22日午後までに再開）
利用者に判断を委ねるKAGOYA（事業者側では止めず、利用者に公開停止やアクセス制限の検討を要請）

PHPの開発チームは、Linuxディストリビューションなどに事前に修正を渡していたとされ、この準備を日頃の運用に組み込めていたかで、止める範囲が変わったと指摘されている［26］。

古いバージョンの扱いも分かれ、さくらインターネット、mixhost、カラフルボックス、ヘテムルなどは、サポートが終わったバージョンにも独自に修正を入れた。こうした修正ではバージョン番号が変わらない場合があり、番号だけでは修正済みか判断できない［26］。

6. 日本と海外の比較

この比較は、10月23日までに公開された報道や各組織の告知に基づくものであり、各国・各組織の対応能力を網羅的に測定したものではない。報道の多い事例に偏っている可能性がある点に留意されたい。

観点日本欧州米国
トップの発信首相とNCOがXで深夜に直接呼びかけ。サイト停止も有効策と明言［26］英NCSC、CERT-EUが「更新できなければオフラインも」と助言［17］［19］CISA、NSAが即時対応を要請［6］［16］
政府機関の停止国税庁、気象庁、財務省、厚労省、自治体［27］［28］オランダの行政ポータル、フィンランドの政府サービス全停止、英仏独の行政サイト［17］［18］確認した範囲では、連邦政府サイトの大規模な停止の報道は見当たらなかった
民間の停止502件超の告知。銀行、交通、EC、ゲームなど［30］［31］病院、港湾、報道機関、ホスティング事業者、Wikipedia［19］確認できず
悪用の観測10月23日時点で、公的機関による国内の攻撃観測データの公表は、確認した範囲では見当たらなかった。民間では、独自の観測網での観測を公表した企業があるオランダのNCSCは、公開前の時点では悪用を確認していないと説明した［18］Amazonが公開4日前から、Cloudflareが公開直後から攻撃の試みを観測した［10］［11］
侵害調査の呼びかけJPCERT/CCが調査観点を提示［26］確認できずAmazonが「10月17日から遡って」と起点を明示［10］
確認された被害PHP2Shellを原因とする被害の公表は確認できず（23日時点）［31］停止組織は侵入の兆候なしと説明［18］KEV未登録（23日時点）［12］
復旧約6割はX上で再開告知が未確認（実際の停止継続件数とは一致しない可能性あり）。サービス終了も［30］［31］確認できず大規模な停止の報道が見当たらないため、比較の対象なし

比較から見えること

  • 共通点：止めた範囲には、資産の把握度が大きく影響したと考えられる。欧州でも、PHPの所在を把握していない組織は全部を止めたと指摘されている［18］。日本でも、復旧が長引く要因として、自社や委託先で使っているPHPのバージョンの特定作業とEOL対応が挙げられている［30］。
  • 日本の特徴1：「止める」は速く、「戻す」に時間がかかった。首相とNCOの呼びかけもあり予防停止は素早く広がったが、23日時点でX上の再開告知が確認できないものが約6割あった。実際に停止が続いている件数とは一致しない可能性があるものの、夜のうちに更新を終えた組織と、止めたまま長引く組織の差が大きい［26］［30］。
  • 日本の特徴2：委託先・ホスティング事業者への依存。レンタルサーバーやCMS提供元の対応で、利用企業ができることが大きく変わった。自社で直せない組織は「止める」以外の選択肢を持てなかった。
  • 日本の特徴3：国内の攻撃観測データの公表が少ない。海外では事業者が自社の観測データで「いつから、どれだけ」を示したが、確認した範囲では、日本の公的発信は「対応してください」が中心で、脅威の強さの判断を海外のデータに頼っている。

7. 3層に照らした評価

PHP2Shellは、3層のすべてを同時に試した事案だった。各層で何が試され、日本でどうだったか、今後どう変えるかを整理する。

層PHP2Shellで試されたこと日本の状況（観察）今後の変え方
第1層
基本対策		PHPがどこで、どの版で動いているかを即答できるか。PHPは他のソフトや機器に同梱され、気づかない露出が生まれやすい［16］。CybelAngelの調査では、約224万のインターネット公開PHPホストのうち、バージョンを確認できた約150万台の59%が、修正版の公開前の時点で修正提供の見込めないバージョンを使用していた［15］。今回は、PHPの開発チームによるサポート終了版（7.4〜8.1）への例外的なバックポートや、OSの配布元・ホスティング事業者による独自の修正が提供されたが［23］［26］、こうした例外的な対応が次も得られるとは限らない止めた後の再開に時間がかかり、X上で再開告知が確認できないものが約6割あった（実際の停止継続件数とは一致しない可能性あり）［30］。古い環境のサービスは終了に至った［31］。委託先・ホスティング事業者に依存資産台帳を言語処理系・ライブラリ単位（SBOM）まで下げる。EOLは「修正が届くかどうかを自分で決められない資産」として扱い、撤去期限を設ける。外部公開の重大脆弱性は、日数ベースの期限に加え、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。委託契約に緊急時の対応時間を入れる。ログを遡って調査できる期間保存する
第2層
ゼロトラスト		PHP本体に起因するため、アプリ側の防御だけでは防げない。メモリから資格情報が漏れる可能性がある［1］封じ込めの主な手段が「サイトを止める」になった。GMO Flatt Securityは、侵害時に備えた権限とデータの最小化を推奨［22］侵入される前提で、サーバ上のデータとIAM権限を最小化。シークレットを短命化しサーバに置かない。外向き通信の制限とセグメンテーションで横展開を止める。「止める範囲を小さくできる」設計にする
第3層
VulnOps・CTEM		数時間で判断し動けるか。シグネチャ前に検知できるか。CVSSや「自動化不可」の評価を鵜呑みにしないか［8］［10］JPCERT/CCが侵害調査の観点を提示［26］。夜のうちに更新を終えた事業者とそうでない組織で差。国内の攻撃観測データは乏しいCTEMで外部公開面と事業影響を常時評価し、外部ソフトの脆弱性は通知を受けたら数時間で塞ぐか止める。振る舞い検知と自動遮断。仮想パッチを即日配る経路。停止の基準と決裁者を事前合意。自社開発のコードはAIでリリース前に診断

3層の重心を、「パッチを早く当てる」（第1層）だけから、「パッチがない期間を生き延びる」（第2層・第3層）へ広げる。ただし、第2層・第3層は、パッチがない期間のリスクを低減するものであり、脆弱性の根本修正を代替するものではない。修正版が出たら速やかに適用することが前提である。また、止める範囲と戻す速さには第1層の成熟度が大きく影響したと考えられ、3層は同時に育てる必要がある。

8. 攻撃側のAIが先に見つける時代への備え

今回は防御側が約2か月半先行できた。しかし、異なる組織が、それぞれAIを使って同じ欠陥にほぼ同時期にたどり着いた事実は、攻撃側も同じものに到達しうることを示している。さらに、リークと公開前の悪用の試みで、その先行期間は想定より早く閉じた［10］。次は、攻撃側のAIが先に見つけ、パッチが存在しない期間に攻撃される前提で備える必要がある。

  1. 露出を減らす：インターネットに出ている面を棚卸しし、不要な公開、EOL、管理外のサーバを消す。攻撃側のAIは面が広いほど有利になる。
  2. ゼロデイ前提の封じ込め：最小権限、シークレットをサーバに置かない設計、外向き通信の制限。パッチがなくても「乗っ取られても被害はここまで」と言える状態にする。
  3. 振る舞いで検知し、自動で止める：シグネチャのない攻撃に備え、サーバのプロセスの異常終了や再起動の多発、メモリ上限エラーやHTTP 500の多発、予期しないシェルの起動など、ふだんと異なる振る舞いを検知して遮断する。PHP2Shellでも、PHPのワーカー（リクエストを処理するプロセス）の異常終了が兆候として挙げられた［1］［10］［26］。
  4. 仮想パッチを即日展開できる経路：WAFやCDNのルールを数時間で全体に配れるようにする。ただしWAFやIPSは本体の修正の代わりにはならない［23］。
  5. 「止める判断」を事前に決める：停止の基準、決裁者、顧客への連絡手順、サイバー保険の条件を経営として事前に合意しておく［17］。
  6. 自社のコードはAIで先に探す：自社で開発したシステムは、ソースコードを持つ防御側が有利であり、AIによる診断を開発の流れに組み込めば、リリース前に脆弱性を見つけられる可能性が高まる。一方、PHPのような外部のソフトウェアの脆弱性を自社で先に見つけることは現実的ではない。外部のソフトウェアについては、発見を待つのではなく、通知を受けたら影響範囲を即座に特定し、数時間で塞ぐか止められる状態にしておく。これが第3層の役割である。

振る舞いの検知と自動遮断を支える仕組み

上記3つ目の「振る舞いで検知し、自動で止める」は、次のような仕組みを組み合わせて実現する。

種類役割PHP2Shellとの関係
サーバ用のEDR・ランタイム保護サーバ上のプロセスの動きを常時監視し、不審な動きを検知して、プロセスの停止やサーバの隔離を自動で行う「Webサーバのプロセスからシェルが起動された」などの動きを直接捉えられる。中心となる仕組み
ログとメトリクスの監視エラーログ、アクセスログ、メモリ上限エラーなどを集め、ふだんより急に増えたら警告するワーカーの異常終了やHTTP 500の急増に気づける。自動で止めるには、次の自動対応と組み合わせる
自動対応の仕組み警告を受けて、該当サーバを切り離す、送信元を遮断するなどの対応を自動で実行する気づいてから止めるまでの時間を縮める
OSの強制アクセス制御Webサーバのプロセスがシェルを起動できないよう、あらかじめ制限する検知ではなく予防。乗っ取られても攻撃者ができることを減らす
WAF不審なリクエストの急増を検知して遮断する未知の攻撃はシグネチャがないと見逃す場合があり、本体の修正の代わりにはならない［23］

PHP2Shellは構成によってはアプリのコードが動く前に成立するため、アプリの中に組み込む防御では捉えられない場合がある。サーバやOSの単位で見張る仕組みの方が向いている。

導入にあたっては2点に注意する。第一に、レンタルサーバーやISPにサーバの管理を任せている場合、これらの多くは利用者側では導入できない。事業者がこうした監視や自動遮断を行っているかを確認するのが現実的である。第二に、自動で止める仕組みは、誤検知で正常なサービスを止めてしまうおそれがある。最初は「検知して通知」から始め、誤検知の傾向を見てから自動遮断に進めるのが一般的である。

9. 対策を経営判断にする: PHP2Shellを使った経営層への説明

7.と8.で挙げた対策の多くは、現場の判断だけでは進められない。時間単位の対応基準を設けること、サービスを止める基準と決裁者を決めること、委託契約に緊急時の対応時間を入れること、そしてVulnOps・CTEMの体制に投資することは、いずれも経営の判断を必要とする。PHP2Shellでは、国内外の多くの組織が深夜に「止めるかどうか」の判断を迫られた。こうした判断を平時に済ませておくには、経営層の理解が欠かせない。

しかし、VulnOpsやCTEMという言葉は、一般にはわかりにくい。そこで本節では、用語から入るのではなく、PHP2Shellという具体的な事案を題材に、経営層に何を問い、何を報告してもらうかという形で説明する方法を示す。

出発点は、PHP2Shellの情報がリークした10月20日から23日までの約72時間で、経営に問われた3つの質問である。

#経営に問われた質問問われた力
1うちでPHPが動いているサーバやサービスは、どこに、いくつあるのか？可視化（資産把握）
2そのうち、止まると売上や顧客に響くのはどれか？事業影響の評価（優先順位付け）
3何時間で直したのか。止める判断は誰がしたのか？修正と意思決定の速さ

CTEMは「この3つの質問に、平時から常に即答できる状態を保つ経営の仕組み」、VulnOpsは「それを毎日回す運用チームと手順」と説明できる。

言い換えの例

  • 健康診断から24時間モニタリングへ：年1回の脆弱性診断は健康診断にあたる。発見から悪用までが数時間になった今は、常時モニタリングと「即入院の判断基準」が要る。
  • 点数ではなく、自社にとっての危険度で並べる：今回は、攻撃の複雑さが「高」、自動化可能性が「No」とされた欠陥でも、AIの支援で攻撃コードが作られ、公開直後から大量の攻撃の試みが観測された［1］［8］［11］。CVSSの点数順ではなく、「公開されているか」「重要業務か」「実際に悪用可能か」で順位を付ける。
  • Amazonの発言を使う：脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した［10］。自社の規程の修正期限と並べて示し、外部公開の重大脆弱性について、露出状況・悪用情報・事業影響に基づく時間単位の基準が必要なことを伝える。
  • お金の言葉に置き換える：「数時間の計画停止のコスト」と「侵害されたときの情報漏えい・長期停止のコスト」を比べる。今回、予防的に止めた組織は前者を選んだ。

経営に報告してもらう指標（月次）

指標意味
外部公開資産のうち台帳にあるものの割合「どこに何があるか」を把握できているか（質問1）
重大脆弱性を修正・緩和するまでの時間外部公開の重大脆弱性について、時間単位の対応基準を守れているか（質問3）
EOLソフトの残存数と撤去期限修正が届くかどうかを他者の例外的な対応に頼っている資産がどれだけあるか
停止判断にかかった時間止める決断を自社で速く下せるか（質問3）
停止から再開までの時間戻す力。第1層の成熟度を反映しやすい指標

10. まとめ

PHP2Shellは、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。実際、リークと公開前の悪用の試みで、確保した時間は想定より早く失われ、国内外で大規模な予防停止が起きた。日本では、止める判断は速かったものの、戻すまでに時間がかかる組織が多く、資産把握とEOL管理という第1層の課題が表れたと考えられる。

次は攻撃側のAIが先に見つける前提で、第1層の土台を固めつつ、第2層の封じ込めと第3層のVulnOps・CTEMを同時に育てる必要がある。経営層には、「3つの質問に即答できる会社にしておく」ことを目標として示すのが有効である。

注：本書は2026年10月23日までの公開情報に基づいている。悪用状況や被害の報告は今後変わりうるため、判断の際は各機関・事業者の最新の発表を確認されたい。

参考資料

以上

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です