ゼロデイ攻撃にどう備えるか？ | PHP2shell脆弱性のメカニズムと、その後の被害事例まで徹底解説
はじめに
「セキュリティ対策をしているのに、なぜサイバー攻撃を受けるのか？」
その理由の一つが、ソフトウェアに潜む脆弱性です。2026年10月、Webサイトなどで広く利用されているPHPに、重大な脆弱性「PHP2Shell（PHP2shell）」が公表されました。一定の条件下では、攻撃者がログインせずにサーバ上で不正なコードを実行できる可能性があります。
しかも問題が存在したのは、Webアプリケーションのプログラムではなく、その土台となるPHP自体。2026年10月26日には、米国CISAが実際に悪用が確認された脆弱性として登録しました。
ここで考えたいのが、「まだ修正パッチがないゼロデイ攻撃には、どう対処すればよいのか？」という問題です。
本記事ではPHP2Shellを事例に、脆弱性・CVE・CVSSの基本から、実際に観測された攻撃、パッチのない期間の暫定対策、パッチ公開後の対応までを図解とともに整理します。基本情報技術者・応用情報技術者・情報処理安全確保支援士の試験対策にも活用できる内容です。
※本記事の事例・修正状況は2026年10月30日時点の公開情報に基づきます。
1. そもそもソフトウェアの脆弱性とは？
脆弱性とは、ソフトウェアやシステムに存在するセキュリティ上の弱点のことです。
代表例には、次のようなものがあります。
入力データの検証が不十分で、不正な処理を実行できてしまう。
認証・アクセス制御に問題があり、本来見られない情報を閲覧できてしまう。
メモリの取り扱いに問題があり、意図しない処理を実行できてしまう。
暗号処理の実装に不備があり、重要な情報が漏えいしてしまう。
脆弱性を攻撃者に悪用されると、情報漏えい、改ざん、サービス停止などにつながることがあります。
「脆弱性がある」と「攻撃が成功した」は別
脆弱性が存在するだけで、被害が発生したと決まるわけではありません。
例えば、攻撃が成立するには特定の設定や実行環境が必要な場合があります。また、インターネットから接続できるサーバか、社内ネットワークに限定されたサーバかによってもリスクは変わります。脆弱性の危険性は、深刻度だけでなく、攻撃できる条件・公開範囲・実際の悪用状況・業務への影響を合わせて考えることが重要です。
2. PHP2Shellとは？ 2026年に発覚した重大な脆弱性
PHP2Shellは、PHPのリクエスト処理や異常終了処理に存在する、主に次の2つの脆弱性を指す名称です。
CVE-2026-109618：メモリ不足（OOM）時の処理によって内部データが不正な状態になり、メモリ破壊などにつながる問題。
CVE-2026-109619：リクエスト処理に関連する内部状態が残存し、解放済みメモリへの参照などにつながる問題。
PHP公式の2026年10月21日のアドバイザリでは、両者について、認証なしのリモートコード実行（RCE）を引き起こす可能性があると説明されています。CVSS v4.0の基本値はいずれも9.2（Critical）です。
なぜ、WordPressなどにも関係するのか？
PHPはWordPress、Drupal、Joomlaなど、多くのWebアプリケーションの実行基盤として使われています。PHP2Shellは、個々のWebアプリケーションが独自に実装した機能のバグではなく、PHPの内部処理そのものに存在する問題です。そのため、アプリケーションのログイン機能や入力チェックを適切に実装していても、下位の実行基盤に弱点が残っていれば、攻撃を防げないことがあります。
脆弱性を発見したWiz Researchは、WordPress・Drupalなどを利用した検証環境で、認証なしのコード実行を実証しました。ただし、これは各CMSの利用者が実際に侵害されたという意味ではありません。アプリだけでなく、OS・ミドルウェア・ライブラリ・実行環境まで管理する必要がある。 これが重要な教訓です。
3. PHP2Shellのメカニズムを理解する
通常、PHPはWebサーバからリクエストを受け取り、必要なデータをメモリに確保して処理を実行し、最後に内部状態を整理します。ところが、異常終了などによって後片付けが想定どおりに行われなければ、内部データの不整合が発生する場合があります。
① CVE-2026-109618：メモリ不足時の不完全な内部状態
この脆弱性では、リクエストの解析中にメモリ確保が失敗すると、PHPの内部データが十分に初期化されないまま残ることがあります。その後の終了処理が不完全なデータを正しいものとして扱うと、メモリの不正な参照・破壊が生じ、条件によってはコード実行につながります。
単なる「メモリ不足によるサーバ停止」ではなく、異常時に内部状態を正しく元に戻せないことが本質です。
② CVE-2026-109619：解放済みメモリへの参照
もう一つは、過去のリクエストで使用した内部状態が残り、後続の処理で古い参照を利用してしまう問題です。
本来、不要になったメモリを解放した後は、その領域を参照してはいけません。しかし、参照情報が残っていると、既に解放されたメモリを使う「Use After Free（UAF：解放後使用）」などが起こり得ます。攻撃者がメモリの状態をうまく操作すると、情報の読み出しや意図しないコード実行につながる危険があります。
なぜ認証なしで攻撃できるのか？
特にApacheの`mod_php`を利用した構成では、アプリケーションのコードが開始される前に攻撃が成立することが実証されています。つまり、ログイン画面や認証機能が適切に動作していても、それだけでは防げない場合があります。
PHP公式は`mod_php`構成のリスクを特に高く評価していますが、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedも影響調査の対象としています。どの環境でも攻撃が同じ容易さで成立する、とまでは言えません。
4. 実際に起きた攻撃・影響の事例
「重大な脆弱性がある」という発表と、「現実の攻撃が成功した」という事実は区別して確認する必要があります。
事例① 修正パッチ公開前から探索通信が発生
Fastlyが2026年10月21日に公表した分析では、公式パッチ公開の9時間以上前から、PHP2Shellを名前に含むツールによる通信が観測されていました。同社の観測範囲では、10月22日昼ごろまでに、約25万件の関連リクエストと、約3,200の送信元パブリックIPアドレスが確認されています。
ただし、これはFastlyの観測した「PHP2Shellを名乗るツール」の通信量です。防御目的の診断を自称する通信も含まれ、25万件すべてが悪意ある攻撃、あるいは侵害成功という意味ではありません。この事例が示すのは、脆弱性の情報が広がると、修正プログラムが十分に行き渡る前から探索行為が始まる、という現実です。
事例② ハニーポットでリモートコード実行に成功
2026年10月26日のBleepingComputerの報道では、研究者のハニーポットに対するPHP2Shellの悪用成功が紹介されました。ハニーポットとは、攻撃者の動作を調べるために意図的に用意する監視・検証用のシステムです。
この事例では、PHP 8.4.26を`mod_php`で実行する、攻撃が成立しやすい条件に調整された環境で、メモリ情報の読み出しとリモートコード実行が確認されています。ただし、これも一般企業の本番システムでの被害件数を示すものではありません。他のPHPバージョンや構成でも同じ確率で攻撃が成功するかは不確かです。
事例③ CISAが悪用確認済み脆弱性に登録
2026年10月26日、米国CISAは、CVE-2026-109618とCVE-2026-109619をKEV（Known Exploited Vulnerabilities）カタログに追加しました。KEVは、実際に悪用が確認された脆弱性をまとめたリストです。CVSSが「技術的な深刻度」を評価するのに対し、KEVは「実際に悪用されたか」という重要な判断材料になります。
なお、IPAの2026年10月27日更新の注意喚起では、日本国内での攻撃被害事例は把握していないと記載されています。調査した公開情報からは、PHP2Shellを原因とする特定企業の情報漏えいやランサムウェア被害について、詳細が検証できる確定事例は確認できませんでした。ただし、技術的に想定される影響には、機密情報の窃取、Webサイトの改ざん、不正プログラムの設置、他システムへの侵入などがあります。これらの想定被害を、既に確認された実被害と混同しないことが大切です。
5. ゼロデイ攻撃とは？ なぜ対策が難しいのか
ここからが本記事の中心テーマです。
ゼロデイ攻撃とは、一般に、修正パッチがまだ用意されていない脆弱性を悪用する攻撃を指します。開発元も脆弱性を把握していない場合や、発見されていても修正が公開される前に攻撃される場合があります。
理由① パッチ適用という基本対策が使えない
通常、脆弱性が見つかったら修正プログラムを適用するのが原則です。しかし、まだパッチがない場合には、設定変更やアクセス制限などの暫定対策で対応しなければなりません。
理由② 既知の攻撃パターンだけでは検知しにくい
既知の攻撃パターンをもとに検知する製品では、新たな手口を見逃す可能性があります。一方、WAF、EDR、IDS／IPSなどを組み合わせれば、未知の攻撃でも不審な通信や動作を検知できる場合があります。ただし、どの製品もゼロデイ攻撃を完全には防げません。
理由③ 発見から攻撃開始までの猶予が短い
脆弱性の名前や一部の技術情報が広まるだけでも、攻撃者は探索を始められます。防御側が影響を調査している間にも攻撃が進む可能性があるため、事前の準備が欠かせません。
PHP2Shellは「ゼロデイ攻撃」だったのか？
PHP2Shellでは、修正パッチの正式公開前から探索・悪用を試みる通信が報告されています。しかし、パッチ公開前に侵害が成功したと断定できる公開証拠は限定的です。一方、パッチ公開後にはハニーポットで攻撃成功が確認され、CISAのKEVにも追加されました。
ここでは、修正前に悪用の試みが発生した事例として、ゼロデイ攻撃への備えを考えます。パッチ公開後も未適用のシステムが狙われ続ける問題は、ゼロデイ攻撃と区別して理解しましょう。
6. ゼロデイ攻撃にどう対処する？ 6つの定石
ゼロデイ対策は「修正パッチが出たら対応する」だけでは不十分です。
平時に被害を抑える環境を作り、発覚時には攻撃経路を減らし、修正公開後にはパッチ適用と侵害調査を進める。 この3段階で考えます。
定石① IT資産管理とSBOMで影響範囲を素早く特定する
まずは、自社のどのシステムが影響を受けるかを把握できるようにします。
OS、ミドルウェア、ライブラリの製品名とバージョンを管理する。
インターネット公開の有無や重要度を紐づける。
コンテナイメージや組み込み製品の構成も把握する。
必要に応じて、ソフトウェア構成要素を一覧化するSBOM（Software Bill of Materials）を活用する。
PHP2Shellが公表されても、PHPを使っているサーバが分からなければ、対策を始めることすらできません。
定石② 最小権限の原則を徹底する
Webサーバやアプリケーションには、必要最小限の権限だけを与えます。もしWebサーバの実行アカウントが広範なファイルにアクセスできるなら、コード実行に成功した攻撃者も大きな権限を利用できる可能性があります。最小権限により、攻撃の成功そのものを防げなくても、被害範囲を小さくできる場合があります。
定石③ WAF・EDRなどによる多層防御を実施する
対策を一つに依存しないことが重要です。
WAF：不審なWebリクエストを検査・遮断する。
IDS／IPS：ネットワーク上の不審な通信を検知・防御する。
EDR：サーバ上の不審なプロセスや操作を検知・調査する。
ネットワーク分離：侵害後に他のシステムへ移動できる範囲を限定する。
ただし、WAFによる「仮想パッチ」は、本体のプログラムを修正するものではありません。WAFを入れたから更新不要、とは考えないことが重要です。
定石④ アタックサーフェスを減らす
アタックサーフェス（攻撃対象領域）とは、攻撃者がシステムに接触できる箇所のことです。不要なサービスを停止する、管理画面へのアクセスを制限する、業務上必要のないインターネット公開をやめるといった対策は、未知の脆弱性にも有効です。
暫定的に安全な運用ができない場合は、サービスの一時停止や外部接続の遮断も選択肢になります。
定石⑤ ログ監視と異常検知を強化する
未知の攻撃を完全に防げないなら、早期発見が重要です。
例えば、次のような変化を監視します。
PHPワーカーの異常終了が増えていないか。
Webサーバから通常とは異なる外部通信が発生していないか。
Webサーバのプロセスが不自然なコマンドを起動していないか。
不審なリクエストが短時間に大量発生していないか。
重要な設定ファイルや認証情報へのアクセスが増えていないか。
ただし、異常な通信を見つけたことと、侵害が成功したことは別です。Web側のログだけでなく、PHP、OS、プロセス、ネットワークの情報を突き合わせて判断します。
定石⑥ パッチがない段階では、公式の暫定対策を検討する
開発元やJPCERT/CCなどの信頼できる情報源から、緩和策の適用条件を確認します。PHP2Shellでは、`session.upload_progress.enabled=0`などの設定変更が一部の攻撃経路に対する緩和策として案内されました。
ただし、この設定だけでPHP2Shellの2つの脆弱性を完全に防げるわけではありません。 メモリ制限などの変更も、負荷や可用性に影響する可能性があるため、公式資料を確認して慎重に判断します。パッチがない間は、必要に応じてアクセス制限、機能停止、WAFの緊急ルール、監視強化などを組み合わせます。
補足：パッチがない脆弱性はPHP2Shell以外にも残っていた
PHP公式は2026年10月23日、PHP2Shellの2件とは別の問題であるCVE-2026-115560についても情報を公開しました。
この脆弱性は、特定のセッション設定とアプリケーション動作が組み合わさった場合に発生するもので、PHP公式は2026年10月30日時点で、次の通常リリースで修正する方針を案内しています。
それまでの暫定対策として示されたのが、`session.upload_progress.enabled=0`です。
これは、「パッチがまだない段階で、影響条件を把握し、代替的な設定変更を行う」というゼロデイ対応の考え方を理解するのに適した事例です。
7. CVE・CVSS・KEV・EPSSの違い
脆弱性対応では、複数の指標を組み合わせます。
CVE：どの脆弱性かを特定する番号
CVE（Common Vulnerabilities and Exposures）は、脆弱性を共通の識別番号で管理する仕組みです。今回の`CVE-2026-109618`などが該当します。
番号自体が深刻度を示すわけではありません。
CVSS：技術的にどれくらい深刻か
CVSS（Common Vulnerability Scoring System）は、攻撃の成立条件や、機密性・完全性・可用性への影響などを評価する共通指標です。PHP2Shellの2件は、PHP公式によるCVSS v4.0の基本評価で9.2です。ただし、CVSSの点数は実際の攻撃件数そのものを表しません。
KEV：実際に悪用が確認されたか
KEV（Known Exploited Vulnerabilities）は、CISAが公開する悪用確認済み脆弱性のカタログです。KEVに掲載されているかは、対応の優先順位を決める際の重要な情報になります。
EPSS：今後悪用される可能性を推定する
EPSS（Exploit Prediction Scoring System）は、一定期間内に脆弱性が悪用される可能性を統計的に推定する指標です。
実務上の優先順位は、CVSS・KEV・EPSSに加え、インターネット公開状況や業務重要度を総合的に考えて決めます。
8. パッチ適用の正しい進め方
2026年10月21日にPHP公式が公開した、PHP2Shellの2件に対応する修正バージョンは次のとおりです。
PHP 8.2系：8.2.35
PHP 8.3系：8.3.36
PHP 8.4系：8.4.27
PHP 8.5系：8.5.12
PHP 8.1以前は、PHP本家の通常サポートが終了しています。ただし、ディストリビューションや製品ベンダが独自に修正をバックポートすることがあります。見かけのバージョン番号だけではなく、提供元の修正情報とパッケージのビルド情報を確認することが重要です。
STEP 1：影響するシステムを特定する
自社でPHPを使うシステム、実際の稼働バージョン、実行方式（`mod_php`、PHP-FPMなど）、ネットワークからの到達可能性を調べます。
STEP 2：公式アドバイザリで影響条件を確認する
脆弱性の概要だけでなく、影響する設定、修正方法、緩和策、副作用を確認します。
STEP 3：パッチ適用の優先順位を決める
インターネットに公開されたシステムや機密情報を扱うシステム、悪用が確認されている脆弱性を優先します。
STEP 4：動作確認と緊急変更手続きを実施する
パッチの互換性やサービス影響を確認し、必要に応じて緊急の変更管理手続きを利用します。リスクが高い場合は、通常の更新サイクルまで待つべきではありません。
STEP 5：本番適用後、プロセスを再起動して確認する
ファイルを更新しただけでは、古いコードを読み込んだワーカーが残っていることがあります。PHPのプロセスや関連サービスを適切に再起動し、実際に動作しているコードが修正済みであることを確認します。
STEP 6：侵害されていないかを調査する
これが見落とされがちなポイントです。パッチを適用しても、既に侵入した攻撃者や設置済みの不正プログラムが自動的に消えるわけではありません。
過去のログやプロセス履歴を調査し、不審なアクセス、外部通信、ファイルの変更、認証情報の流出がなかったかを確認します。侵害が疑われる場合は、証拠保全、影響範囲の調査、認証情報の失効・変更、必要に応じたクリーンな環境への再構築を進めます。
9. IPA試験ではどう問われる？
基本情報・応用情報：用語と基本的な対応を理解する
次のキーワードをセットで覚えておきましょう。
脆弱性・ゼロデイ攻撃・リモートコード実行（RCE）
CVE・CVSS・KEV・EPSS
パッチ管理・最小権限・多層防御
WAF・IDS・IPS・EDR
SBOM・アタックサーフェス
情報処理安全確保支援士：状況に応じて対策を判断する
例えば、次のような設問です。
自社のインターネット公開サーバで重大な脆弱性が発見された。しかし、修正パッチはまだ提供されていない。どのような対策を行うべきか。
この場合、「パッチを適用する」だけでは問いに答えられません。修正パッチがまだ存在しないという条件を踏まえて、公式緩和策の確認、アクセス制限、不要なサービスの停止、ログ監視の強化などを検討します。
さらに、パッチ公開後には更新作業だけでなく、公開前後に攻撃を受けていなかったかの調査が必要です。ポイントは、予防・検知・封じ込め・復旧を一連のプロセスとして理解することです。
10. まとめ：ゼロデイ攻撃は、パッチ適用だけでは防げない
PHP2Shellは、PHP自体の内部処理の問題によって、認証不要のリモートコード実行につながる可能性がある重大な脆弱性です。修正公開前から探索・悪用の試みが観測され、公開後には実際のコード実行も確認されました。
今回の事例から学べるのは、脆弱性対策は「最新バージョンに更新する」だけでは完結しないということです。重要なのは、次の3点です。
① 平時から、攻撃が成立しにくく、被害が広がりにくい環境を作る。
資産管理、最小権限、多層防御、ログ監視を整備する。
② パッチがない段階でも、何もしないまま待たない。
影響条件を把握し、アクセス制限、設定変更、必要に応じた機能停止などでリスクを減らす。
③ パッチ公開後は、更新と侵害調査の両方を実施する。
修正を適用しただけで安心せず、既に被害が生じていないかを確認する。ゼロデイ攻撃を完全に防ぐことは困難でも、攻撃の成立可能性と成功後の被害を小さくすることはできます。
「脆弱性を完全になくす」だけではなく、「脆弱性があっても被害を最小限に抑える」ことまで考える。 これが、実践的なセキュリティ対策の定石です。
関連記事
参考資料
※情報は2026年10月30日時点です。
