これまでのシリーズでは、情報セキュリティの脅威や、それに立ち向かう組織・体制について、一般論として確認してきた。今回は番外編として、2026年10月に実際に発生した事案を題材に、脆弱性情報を受け取ってから組織がどう動くべきかを具体的に確認する。なお、本稿は事案発生から少し時間を置いて執筆・公開しているため、速報ではなく、落ち着いて整理した「学習用のケーススタディ」として読んでもらえればと思う。記載している情報は2026年10月29日時点のものであり、状況は今後も更新される可能性がある。
何が起きたのか
2026年10月21日、Webサイトの構築に広く使われているプログラミング言語「PHP」に、2件の重大な脆弱性（CVE-2026-109618、CVE-2026-109619）が公表され、緊急の修正版が公開された。通称「php2shell」と呼ばれているこの脆弱性は、攻撃者が細工したHTTPリクエストを送信するだけで、ログインなどの認証を経ずにサーバ上で任意のコードを実行できてしまう可能性があるとされている。
深刻度は、脆弱性の危険性を数値化する指標であるCVSS（後述）のバージョン4.0で、2件とも9.2（最高ランクであるCritical）と評価されている。これを受け、PHP開発チームは、通常のバージョンであるPHP 8.5系・8.4系・8.3系・8.2系について、それぞれ8.5.12・8.4.27・8.3.36・8.2.35という修正版を緊急公開した。
一方、すでにサポートが終了している古いバージョン（PHP 7.4、8.0、8.1など）では、通常のセキュリティサポートが終了しているため、修正の提供状況を個別に確認する必要がある。利用しているディストリビューションや製品ベンダーが修正済みパッケージを提供している場合もあるため、バージョン番号だけで判断せず、公式の案内を確認することが重要である。
悪用の状況も、時間とともに変化している。公表の4日前にあたる10月17日には、Amazonの脅威インテリジェンスチーム（Amazon Threat Intelligence）が、自社のハニーポット（攻撃者をおびき寄せて手口を記録するためのおとりサーバー）に対する、この脆弱性の悪用の試みを観測していたと発表している。送信元は商用の匿名化ネットワークに関連するIPアドレスで、この試みが実際の環境に対して成功したものかどうかや、攻撃者が公開前にどうやって情報を得たのかは、Amazonも不明としている。
このように、公表当初は「悪用を試みているとみられる通信（プロービング）が観測されている」という段階だった。
その後、2026年10月26日に、米国のサイバーセキュリティ機関であるCISA（Cybersecurity and Infrastructure Security Agency）が、両脆弱性を「実際に悪用が確認された脆弱性」としてKEV（Known Exploited Vulnerabilities）カタログに追加した。
これにより、脅威の段階が「悪用の疑い」から「悪用の確定」へと進んだ形になる。米連邦機関に対しては、2026年10月29日が対応期限として設定されている。
なお、すでに公開されている検証用コード（PoC）については、動作に多くの前提条件が必要で、どの環境でも確実に成功するわけではないとの見方もある。ただし、そのことは対応を後回しにしてよい理由にはならず、公式に修正版が提供されている以上、更新を最優先とするのが基本である。
CVEとCVSSとは
この事案を理解するうえで欠かせない、2つの基礎用語を確認しておこう。
CVE（Common Vulnerabilities and Exposures）
CVEとは、公表された脆弱性一つひとつに割り振られる、共通の識別番号である。「CVE-2026-109618」のように、西暦と通し番号の組み合わせで表記される。同じ脆弱性について、ベンダーやセキュリティ機関ごとに別々の呼称をしていては混乱が生じるため、CVE番号を共通の「ID」として使うことで、どの組織も同じ脆弱性を正確に指し示せるようになっている。
CVSS（Common Vulnerability Scoring System）
CVSSとは、脆弱性の深刻度を、第三者が共通の基準で定量的に評価するための仕組みである。攻撃の難易度や、悪用された場合の影響範囲といった要素をもとに、0.0〜10.0の数値でスコアが算出され、数値が高いほど深刻度が高いことを示す。一般に、9.0以上は「Critical（緊急）」に分類され、最優先での対応が求められるレベルとされる。
CVEが「どの脆弱性か」を特定するための識別子であるのに対し、CVSSは「その脆弱性がどれくらい危険か」を数値化するための指標である、という役割の違いを押さえておこう。
組織はこの種の情報をどう受け止めるべきか
こうした脆弱性情報が公表された際、組織はどのように動くべきか。
これまでに扱ってきたCSIRT（第42回）の活動の流れに沿って整理すると、次のようになる。
1. 影響範囲の特定
自組織が、該当するソフトウェア（今回であればPHP）をどこでどのバージョン使用しているかを把握する。これは、普段から情報資産を一覧化・管理できていなければ、迅速に行うことが難しい作業である。日頃の情報資産管理の重要性が、こうした緊急時にこそ問われることになる。
また、今回は自社でPHPを直接利用していなくても、導入している製品の内部でPHPが動作している場合がある点にも注意が必要である。実際に、ネットワーク機器の管理画面にPHPが使われている製品でも影響が確認され、ベンダーから修正版や緩和策が案内されている。
これは、第36回で扱ったサプライチェーン攻撃で触れた「ソフトウェアの部品を経由する脅威」と共通する視点であり、自社が利用している製品の構成部品まで把握しておくことの重要性を示している。
2. 対応の優先順位づけ
CVSSスコアなどをもとに、影響の大きさと緊急度を判断し、対応の優先順位をつける。今回のようにCVSS 9.2・認証不要のRCE（リモートコード実行）という条件がそろった脆弱性は、最優先で対応すべき事案と判断されるのが通常である。
なお、今回のように、公表直後は「悪用の疑い」の段階であったものが、数日後にCISAのKEV登録によって「悪用の確定」へと変化するように、脅威の深刻度評価は一度で終わるものではなく、新しい情報が入るたびに更新し続ける必要がある。対応の優先順位づけは一回限りの判断ではなく、継続的な見直しの対象であることを意識しておきたい。
3. パッチ適用、または代替策の実施
可能であれば、速やかに修正版への更新（パッチ適用）を行う。今回の脆弱性については、PHP側も「完全な緩和策はなく、更新が唯一の対策」という立場を示しており、パッチ適用が基本である。
使用中のバージョンがサポート終了していて正式な修正版が提供されない場合には、ディストリビューションや延長サポートを提供する事業者がバックポート（旧バージョン向けに修正を移植したもの）を出していないかを確認し、それも難しければ、外部に公開している範囲を絞る、アクセス元を限定する、WAF（Webアプリケーションファイアウォール）などで不審な通信を遮断するといった緩和策を、あくまで更新までの一時的な措置として検討する。緩和策は根本的な解決にはならない点に注意したい。
また、レンタルサーバーなどのホスティングサービスを利用している場合は、事業者側で対応が進められているかどうかも確認の対象になる。今回は、国内の複数のホスティング事業者が、旧バージョンを含めて独自に修正を適用したと案内している。ただし、事業者が対応する範囲と、利用者自身が対応しなければならない範囲（自分でインストールしたアプリケーションなど）は契約やサービス形態によって異なるため、どこまでが誰の責任なのかを把握しておく必要がある。
4. 侵害の有無の確認
今回のように、修正版の公開前から悪用を狙う通信が観測されていた脆弱性では、パッチを適用した時点で「すでに侵害されていないか」を確認することも欠かせない。
パッチ適用はこれから先の侵入を防ぐものであり、適用前に入り込まれた痕跡を消してくれるわけではないためである。PHPの異常終了やメモリ不足のエラー、不審なHTTPリクエスト、想定外のOSコマンド実行や外部への通信といったログ上の兆候がないかを調査する。
このとき、調査の対象期間を「公表日以降」に限らず、最も早く悪用の試みが確認された時点まで遡る点も重要である。
Amazonも、侵害調査は公表日ではなく最初に悪用が確認された時点から始めるべきだとしており、今回であれば少なくとも10月17日以降のログが調査の対象になる。
5. 記録と振り返り
対応の経緯を記録し、今後の対応に活かすための振り返りを行う。「なぜサポート終了バージョンを使い続けていたのか」といった根本的な課題が見つかれば、情報セキュリティポリシーや資産管理の見直しにもつなげていく。
試験対策のポイント
- CVEは「脆弱性を識別するための番号」、CVSSは「脆弱性の深刻度を数値化する指標」という役割の違いを区別できるようにしておこう
- サポート終了（EOL）したソフトウェアを使い続けることが、脆弱性対応における大きなリスク要因になる、という考え方を押さえておこう
- 脆弱性情報を受け取ってからの対応は「影響範囲の特定→優先順位づけ→対応の実施→侵害の有無の確認→記録・振り返り」という流れで進む、という実務的な感覚を持とう
- パッチ適用は「これから先の侵入を防ぐ」ものであり、適用前の侵害の有無は別途確認する必要がある点を押さえておく。その際の調査期間は、公表日ではなく、最初に悪用の試みが確認された時点まで遡ろう
- ホスティングやクラウドなどの外部サービスを利用している場合、事業者が対応する範囲と利用者が対応する範囲（責任分界）を把握しておく必要がある、という考え方を押さえておこう
- 事例文で「緊急のセキュリティパッチが公開されたが、自社システムでの利用状況がすぐに把握できなかった」といった記述があれば、日頃の情報資産管理の不備が問題の根底にある、と読み取れるようにしておこう
- 脆弱性の深刻度評価は公表時点で確定するものではなく、悪用状況などの新しい情報を受けて継続的に見直されるものである、という考え方を押さえておこう
まとめ
今回は番外編として、2026年10月に公表されたPHPの重大な脆弱性「php2shell」を題材に、CVE・CVSSという基礎用語と、脆弱性情報を受け取った際の組織の対応の流れを確認した。次回は、SOCを取り上げ、CSIRTとの関係を整理して組織・体制シリーズを締めくくる。
コメント