2026年10月21日の夜、国内の多くのWebサービスが緊急メンテナンスに入りました。原因は、PHP本体に見つかった2件の重大な脆弱性、通称「PHP2Shell」です。首相がWebサイトの一時停止まで呼びかけ、社会的にも大きな話題になりました。
大手SIerで20年超、大規模な業務システムの基盤構築や運用に携わってきた私が、今回の騒ぎを見て感じたのは、CVSS 9点台の重大な脆弱性が見つかり、緊急対応を迫られる事態は、私が携わってきたシステムでは想定内だったということです。
PHP2Shellという個別の脆弱性を予測していたわけではありません。通常SIerでは、重大な脆弱性が発見されることを前提に、対応基準や正常性確認の手順を平時から整備しています。
本記事では、PHP2Shellが大きな問題になった背景を整理し、運用の現場が重大な脆弱性をどう判断し、どう対策しているのかを解説します。
本記事は2026年10月30日時点の公開情報に基づいています。仮想事例と明記した部分は説明用に構成したものです。
PHP2Shellの重大性と社会的な影響
PHP本体に見つかった2件の重大な脆弱性
PHP2Shellは、PHPの実行基盤に見つかった2件の脆弱性の総称です。CVE-2026-109618はメモリ不足（OOM）時のエラー処理に、CVE-2026-109619はリクエスト処理に関わる内部状態の管理に起因します。いずれも認証なしで遠隔からサーバー上の任意のコードを実行されるおそれがあり、PHPのセキュリティチームは2件ともCVSS v4.0で9.2と評価しています。修正版は10月21日に公開されました。
| PHPのバージョン系統 | 修正版 | サポート状況 |
|---|---|---|
| PHP 8.2 | 8.2.35 | 2026年12月31日でサポート終了 |
| PHP 8.3 | 8.3.36 | セキュリティ修正のみ |
| PHP 8.4 / 8.5 | 8.4.27 / 8.5.12 | サポート中 |
注意したいのは、サポート切れの古いPHPだけが対象ではなかったことです。サポート中の8.2〜8.5系も、修正版より前はすべて影響を受けます。8.1以前には公式の修正版がなく、7.4・8.0・8.1向けに最小限の修正コードが出たのみです。IPAは、調査に関わったWiz社の情報として、PHP 5.4以降は少なくともいずれかの影響を受けると紹介しています。
悪用の状況について、IPAは10月27日の更新で、米国CISAが2件を「悪用が確認された脆弱性」の一覧（KEVカタログ）に追加したことを紹介し、国内での攻撃被害は把握していないとしています。攻撃が観測されたことと、実際に侵害された被害が確認されたことは、分けて受け止める必要があります。なお、JPCERT/CCは10月29日の更新で、あるファイアウォール製品の特定バージョンについて、侵害成功を示唆する痕跡が確認されたとの報告を紹介しています。
CVSSとは何か
CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を0.0〜10.0で評価する共通指標です。CVSS v4.0では7.0〜8.9が「High（重要）」、9.0〜10.0が「Critical（緊急）」で、PHP2Shellの9.2は最も深刻な区分に当たります。ただし、公表される基本評価値は、個々のシステムで実際に攻撃が成立するか、どの順に対処すべきかまでは示しません。
首相による注意喚起とWebサイトの一時停止
高市首相は21日21時55分ごろ、Xで「今夜に対応して頂きたい大至急のお願い」としてパッチの適用準備を呼びかけ、適用が難しい場合は「ウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つ」と述べました。同じ夜、BASE、pixiv、niconico、DMM.comなどが予防的にメンテナンスに入ったと報じられています。
一般の利用者には前例のない非常事態に映ったかもしれません。しかし、OS、Webサーバー、Javaランタイム、RDBMSでも、重大な脆弱性は繰り返し報告されてきました。CVSS 9点台の脆弱性を調べ、緊急対応の要否を判断すること自体は、企業システムの運用では特別なことではありません。
PHPの普及範囲と管理体制の多様さ
では、なぜ今回はこれほど大きな問題になったのか。背景の一つは普及範囲の広さです。W3Techsの調査（2026年10月29日時点）では、サーバー側の言語を判別できるWebサイトの69.2%がPHPを使っています。
もう一つは、管理体制の違いです。専門の運用組織が管理するシステムもあれば、ホスティング事業者や制作会社に任せたサイトもあります。W3Techsの10月下旬の集計では、PHPを使うサイトの約27%が7系、約8%が5系で、いずれもPHP本家の公式サポートが終了し、通常の修正版リリースが提供されない系統でした。利用率が高いことは、すべてのサイトが攻撃可能という意味ではありません。それでも、広く普及した実行基盤に重大な脆弱性が見つかれば、更新のしやすさが異なる多様な運用主体が一斉に対応を迫られます。今回の社会的な反応には、この事情も影響したと私は考えています。
重大な脆弱性への対応は、平時から設計している
CVSSに応じた対応基準を準備する
ここからは、私が実際に携わってきたシステムの運用を紹介します。すべてのSIerや企業システムが同じ水準にあるという意味ではなく、あくまで私の経験の範囲です。
私が関わったシステムでは、ベンダーのセキュリティアドバイザリ、IPAやJPCERT/CCの注意喚起、OSやミドルウェアの更新情報を継続的に監視し、管理対象の製品に関係する脆弱性を抽出していました。そのうえで、CVSSの重大度に応じた対応基準に照らし、対象サーバーの範囲、対応期限、緊急対応の要否を判断します。CVSS 9点台で緊急対応になることも、運用上の想定に含めて手順を整えていました。
ただし、CVSSは初期判断の材料です。9点台でも、攻撃に必要な機能を使っておらず成立条件がない場合があります。逆に8点台でも、インターネットから直接攻撃でき、すでに悪用が確認されているなら優先すべきです。脆弱性の重大度と、自分たちのシステムでの実際のリスクは、分けて評価する必要があります。
業務重要度によって対応方法を変える
もう一つの軸が業務重要度です。私が関わったシステムでは、業務への影響に応じて区分していました。以下に簡略化したイメージを示します。
| 区分 | 特徴 | 緊急対応で重視すること |
|---|---|---|
| 超クリティカルな基幹系 | 停止が業務や顧客に大きな影響を及ぼす | 継続性、安全な切替方法、代替手段 |
| 中間的な業務システム | 短時間の計画停止であれば調整可能 | 停止時間の調整、影響範囲の確認 |
| バックオフィス系 | 一時的な停止を許容できる | 必要に応じた迅速な停止と確実な復旧 |
この区分に脆弱性の攻撃可能性を組み合わせて判断します。停止できるシステムにCritical級の脆弱性があり、外部からの攻撃を防げないなら、止めて修正します。停止の影響が大きい基幹系では、冗長構成や代替手段で業務への影響を抑える方法を検討します。
ただし、冗長構成があるからといって、未修正のサーバーを攻撃可能なまま公開し続けてよいわけではありません。片系ずつ適用する場合も、未修正側の攻撃経路を遮断できることが前提です。安全な暫定策がなければ、基幹系でも緊急停止を選ぶ場合があります。
正常性確認まで事前に準備しておく
特に重要だと考えているのが、パッチ適用後の正常性確認です。携わってきたシステムでは、業務重要度の区分ごとに正常性確認スクリプトとテスト項目一覧を整備していました。確認するのは、プロセスの稼働、Web/APサーバーからのDB接続、主要な業務画面やトランザクション、外部システムとの連携、ログ出力と監視、冗長構成での切替や負荷分散です。範囲と深さは、重要度と変更内容に応じて変えます。
緊急時の深夜に確認項目を一から洗い出せば、時間がかかり確認漏れも起きます。手順が手元にあれば、再開の判断を速く下せます。想定内とは、対応が楽に済むという意味ではありません。徹夜になっても、何をどの順に確認し、誰が再開を判断するかが決まっていることです。何から手を付けるか分からず、手探りで朝を迎える徹夜とは違います。
このような準備は運用設計の一部です。NISTのパッチ管理ガイド（SP 800-40 Rev.4）も、定期適用、緊急適用、緊急の緩和策、パッチを適用できない資産といった場面ごとに、対応を事前に計画することを推奨しています。パッチ・脆弱性管理に加え、起動停止や開局・閉塞などの具体的な設計項目は、運用設計書の目次サンプルを解説した次の記事で整理しています。
CVSSが高くても、必ずパッチを適用するわけではない
仮想事例：未使用の管理サービスにCVSS 8点台の脆弱性
ここでは、パッチを当てるかどうかを判断する技術を、説明用の仮想事例で考えます。
あるミドルウェアの管理用サービスに、CVSS 8点台の脆弱性が公表されたとします。特定のTCPポートで待ち受ける管理サービスを通じて攻撃が成立しますが、このサービスは業務では使っていません。この場合、全サーバーへの即時適用の前に、成立条件を確認します。
- 影響条件の確認：対象製品、バージョン、機能、攻撃経路を確認する。
- 対象サーバーの特定：管理台帳から、該当製品を使うサーバーを洗い出す。
- 利用状況の確認：管理サービスを業務で使っていないことを、設計書と実機の設定で確認する。
- 稼働状態の確認：管理サービスが起動していないことを確認する。
- 不要サービスの停止：起動していれば停止し、自動起動も無効化する。
- 有効性の確認：該当ポートが待ち受けていないこと、別の経路から同じ脆弱性を悪用できないことを確認する。
- 記録と判断：実施内容と残存リスクを記録し、承認を経て緊急パッチの適用を見送る。
パッチを適用しないことは、放置することではない
この例で伝えたいのは、パッチを見送る判断にも技術的な根拠が必要だということです。攻撃経路が特定のサービスに限られ、そのサービスを確実に無効化できるなら、緊急のリスク低減策として成立する場合があります。
ただし、攻撃経路が実際に遮断されていることを確認できなければなりません。ポートを閉じただけでは、別のインターフェースから攻撃が成立する可能性も残ります。脆弱性そのものは残っているため、構成変更やサービスの再有効化でリスクは戻ります。緊急適用を見送っても、定期メンテナンスでの更新計画は別途必要です。すでに侵害されている疑いがあれば、停止とは別に調査も欠かせません。
「脆弱性のある製品を使っている」ことと「その脆弱性を悪用できる状態にある」ことは、必ずしも同じではありません。この違いを実際のシステム構成や設定から調べ、対応方針を決めることも、システム基盤エンジニアの仕事の一つです。次の記事で詳しく解説しています。
対策を実施するか、代替策を選ぶか、どのリスクを残すかという判断の考え方は、次のセキュリティ要件定義とリスクアセスメントの進め方でも詳しく解説しています。
PHP2Shellなら、現場ではどう対応するか
PHPの採用領域と運用体制の違い
まず、PHPがどのようなシステムで使われているかを整理します。
| 領域 | 主な特徴 |
|---|---|
| 従来型エンタープライズ基幹系 | Java、.NET、COBOLなどの技術資産が多く、長期的な運用管理が重視される |
| 一般Webサイト・CMS | WordPressなどを通じてPHPが普及し、管理主体や保守体制が多様 |
| SaaS・EC・Webサービス | PHPが注文、在庫、契約など、事業の中核となる処理を担う場合がある |
たとえばBASEは、PHPによる大規模な商用ECを継続的にリアーキテクチャしてきた経緯を技術ブログで公開しています。システムの種類だけで管理水準が決まるわけではなく、SIerが管理するシステムにも古い環境は残り、一般のWebサイトにも高度な管理をしている例はあります。今回問われたのは、実行環境を誰が管理し、どれだけ迅速に更新できるかでした。
影響対象はアプリケーションではなくPHPランタイム
PHP2Shellは、PHP本体の脆弱性です。WordPressやLaravelを更新しても解消しません。確認すべきなのは、実際にWebリクエストを処理しているPHPのバージョンと実行方式です。
PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどを影響対象に挙げています。mod_phpではアプリケーションのコードが動く前に攻撃が成立することが実証され、最もリスクが高いとされました。PHP-FPMでも、CVE-2026-109619で条件付きの攻撃成立が確認されています。設定変更で一部の経路は減らせますが、PHP公式は完全な緩和策はないとし、更新を強く求めています。
仮想事例：LB配下の公開Webシステム
ここからは説明用の仮想事例です。インターネットに公開されたWebシステムで、ロードバランサー（LB）の配下に複数台のWeb/APサーバーがあり、それぞれでPHPが動いているとします。DBや外部APIと接続しており、一時的なサービス停止は業務上許容できます。私なら、次の流れを基本に検討します。
| 段階 | 対応内容 | 主な確認事項 |
|---|---|---|
| ① 影響調査 | PHPのバージョン、実行方式、公開経路、対象サーバーを確認 | 実際に稼働するPHPが影響対象か |
| ② 停止判断 | 攻撃リスクと停止による業務影響を評価 | 公開の継続を許容できるか |
| ③ 公開の閉塞 | LBをSorry画面に切り替える | バックエンドへの迂回経路がないか |
| ④ 修正適用 | 全対象ノードへ修正版を適用 | 修正済みのランタイムが稼働しているか |
| ⑤ 安全性・正常性確認 | 侵害調査と業務動作の確認 | セキュリティ上・業務上の問題がないか |
| ⑥ 再公開 | LB配下へ段階的に戻す | エラーや性能劣化が発生していないか |
①〜③ 影響を調査し、必要なら公開を止める
構成管理台帳だけでなく実際の稼働環境と照合して、どのサーバーでPHPが動いているかを確認します。攻撃可能で修正まで安全を確保できなければ、LBでSorry画面に切り替えます。Sorry画面はPHPに依存しないLBの固定応答や静的コンテンツで返し、Web/APサーバーへの直接アクセス、管理用の別ポート、公開API、IPv6など、LBを迂回する経路も確認します。
④ パッチを適用し、実際の稼働状態を確認する
見落としやすいのがこの段階です。パッケージを更新しても、PHP-FPMやApacheを再起動しなければ古いランタイムが動き続けます。Webサーバーが使うPHPとコマンドラインのPHPで、バージョンが異なることもあります。コンテナは修正版のイメージで置き換え、オートスケールの起動テンプレートも更新しなければ、後から増えたサーバーが修正前の状態で立ち上がります。ディストリビューションが修正をバックポートしている場合は、表示バージョンではなくベンダーのアドバイザリやパッケージの修正履歴で判断します。
⑤ セキュリティ確認と正常性確認を行う
修正前に侵害を受けていなかったかも調べます。JPCERT/CCは、不自然に長い、または異常な形式のPHPSESSID Cookie、不審なmultipart/form-data形式のリクエストとその前後のメモリ上限エラーやHTTP 500、PHPワーカーの異常終了や頻繁な再起動の3点の確認を推奨しています。痕跡がないことは侵害がなかった証明にはならず、疑わしい兆候があれば証拠保全や再構築も検討します。
パッチ適用後は、既存機能に不具合が生じていないかを確認するデグレード確認（無影響確認）が必要です。私が携わったシステムでは、この確認のために正常性確認スクリプトとテスト項目一覧を平時から作成・整備していました。今回のようなケースでも、それらを使ってDB接続、主要業務画面、外部連携、ログ出力や監視の動作を確認する想定です。ただし、すべてのケースで正常性確認スクリプトで対応できわけるではなく、事象事に適用可否を検討します。
⑥ LB配下へ段階的に再公開する
修正済みのノードを1台ずつLB配下に戻し、エラー率、応答時間、CPU使用率、DB接続数を見ながら範囲を広げます。これは全対象ノードの安全を確保したうえでの段階的な復旧であり、未修正のサーバーを公開したまま順番にパッチを当てるという意味ではありません。
PHPだけに特別な対処をしているわけではない
この流れはPHPに固有のものではありません。Javaのランタイムでも、Webサーバーでも、OSやRDBMSでも、影響を確認し、リスクを評価して対策を選び、安全と業務の両面を確かめて再開する考え方は共通です。差を生むのは、判断基準と確認手順を平時から持っているかどうかです。
脆弱性対応で本当に重要なのは、更新できる状態を維持すること
緊急時に「すぐ更新できない」理由
今回は、サポート終了バージョンへの対応も課題になりました。8.1以前は公式の修正版がなく、サポート中の版への移行にはアプリケーションやプラグインの互換性確認と改修が必要です。長く更新されていないシステムでは、設計資料が不足していたり、当時の担当者がいなかったり、保守契約が終わっていたりもします。IPAも今回の注意喚起で、こうした理由で更新が難しくなる場合があると指摘しています。パッチが出ても、安全に適用できるとは限らないのです。
更新できる状態を維持することも運用設計
迅速に動くには、平時から次の状態を保つ必要があります。使っているOSやミドルウェアの製品とバージョン、サポート期限を把握していること。パッチ適用時の影響範囲を確認でき、正常性確認手順が整っていること。サービスの停止と再開の判断基準と責任者が決まっていること。そして、更新後の監視と復旧の手順を用意していることです。
これらは脆弱性が見つかってから短期間で整えられるものではありません。正常性確認の手順も、機能追加や構成変更に合わせて更新し続けて初めて、緊急時に使えるものになります。
脆弱性対応とは、パッチを当てる作業ではない
重大な脆弱性への緊急対応を「想定内」にできるのは、重大な脆弱性が見つかることを前提に、情報収集から対応基準、対象の特定、適用の要否、正常性確認、再開までを平時に準備しているからです。成立条件を確実に排除できるなら緊急パッチを見送る判断もあり、PHP2Shellのように攻撃リスクが高く修正まで安全を確保できなければ、一時停止も合理的な選択です。どちらも、脆弱性の特徴と実際のシステム構成を確かめたうえで下す判断です。
PHP2Shellが社会問題になった背景には、普及範囲の広さに加え、管理体制や更新のしやすさがシステムごとに異なるという事情がありました。これはPHPに限った話ではありません。
脆弱性対応とは、単にパッチを当てる作業ではありません。影響を調査し、対策を選択し、安全に業務を継続・再開するための運用設計なのです。
参考文献
- IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日公開、10月27日更新） https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
- IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日） https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
- PHP公式「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
- PHP公式「Supported Versions」 https://www.php.net/supported-versions.php
- JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日公開、10月29日更新） https://www.jpcert.or.jp/at/2026/at260033.html
- FIRST「Common Vulnerability Scoring System Version 4.0」 https://www.first.org/cvss/v4.0/
- NIST「Guide to Enterprise Patch Management Planning, SP 800-40 Rev.4」 https://csrc.nist.gov/pubs/sp/800/40/r4/final
- W3Techs「Usage statistics of PHP」 https://w3techs.com/technologies/details/pl-php
- BASEプロダクトチームブログ「事業継続のためにPHPを使ったサービスを継続的に進化させていくこと」 https://devblog.thebase.in/entry/leverage_php
- ITmedia NEWS「高市総理『大至急、PHPパッチ適用を』Xで異例の要請」（2026年10月22日） https://www.itmedia.co.jp/news/article/2610/22/2000002483/
- Impress Watch「国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策」（2026年10月21日） https://watch.impress.co.jp/docs/news/2150159.html
コメント