PHP2Shell対応、PHPを上げたら終わり？「更新」と「復旧」は別の話

Posted at 2026-10-23

PHP2Shellの対応を進めている皆さん、お疲れさまです。環境の洗い出しから更新、動作確認、関係者への連絡まで、普段の仕事を止めて対応している方も多いと思います。

PHP開発チームは2026年10月20日に緊急リリースを予告し、翌21日に2件の重大な脆弱性、CVE-2026-109618とCVE-2026-109619（通称PHP2Shell） の詳細と修正版を公開しました。どちらもCritical（緊急）、CVSS v4.0は9.2です。PHP公式の告知でも、速やかな更新が強く呼びかけられています。

高市総理も10月21日のX投稿で、修正パッチをすぐ適用できるよう準備することや、適用が難しい場合のサイトの一時停止を呼びかけています。いつもの技術系のタイムラインを越えて、この話を目にした方もいそうです。

そんな中で、「PHPを上げたら、もう対応完了でいいんだっけ？」と気になったので、整理してみます。この記事で分けて考えたいのは、「脆弱性を直すこと」と「すでに侵入された環境を復旧すること」 です。特定のクラウドや製品に限定せず、一般的な対応を説明します。

PHP2Shellは何が問題で、いつ公表されたのか

まず、PHP2ShellはWebシェルという不正スクリプトの総称ではありません。PHP本体にある2件の脆弱性の通称 です。オランダNCSCの情報集約リポジトリも、この名称で2件を扱っています。

CVE	PHP公式での名称	問題の概要
CVE-2026-109618	RCE via OOM corruption	メモリ不足時の処理で内部状態が壊れ、遠隔コード実行につながる可能性がある
CVE-2026-109619	RCE via stale global state	前のリクエストの無効な内部状態を、後のリクエストが使ってしまう可能性がある

ここでいうRCEは、遠隔からコードを実行されることです。認証なしでWebワーカーの権限によるコード実行につながり得るため、単なるエラーや表示崩れの話ではありません。

公表日時は、事前告知と修正版公開を分けると分かりやすくなります。

出来事	日時	確認元
Amazonが後から確認した攻撃試行	2026年10月17日（報告記事に記載の日付）	Amazon Threat Intelligenceの報告
緊急セキュリティリリースの事前告知	2026年10月20日。公式記事に時刻の記載なし	PHP公式の事前告知
修正版の公開	2026年10月21日22時30分（日本時間）／13:30 UTC	CERT-EUの記録
CVE-2026-109619のGitHubアドバイザリ公開	2026年10月21日22時34分13秒（日本時間）／13:34:13 UTC	PHP公式リポジトリの公開メタデータ
CVE-2026-109618のGitHubアドバイザリ公開	2026年10月21日22時34分25秒（日本時間）／13:34:25 UTC	PHP公式リポジトリの公開メタデータ

秒単位の日時はGitHub APIのpublished_atを日本時間へ換算したものです。PHP.netの記事掲載時刻そのものとは区別しています。当初のリリース予定は日本時間23時でしたが、実際の公開時刻は上表のCERT-EUの記録を採用しました。

Amazonは、公表前の10月17日の攻撃試行を報告している

ここで、もう一つ見逃せない話があります。Amazon Threat Intelligenceの公式報告によると、ハニーポット網のMadPotに残っていた観測データから、2026年10月17日のPHP2Shell攻撃試行 が確認されています。詳細公開・修正版リリースの4日前で、10月20日の事前告知よりも前です。

さらにAmazonは、10月21日02:00〜08:00 UTC（日本時間11〜17時）にも、複数の匿名化基盤からMadPotを狙う攻撃試行を確認したとしています。いずれも同日の公開予定時刻より前です。

ただし、ここは言葉を分けておきたいところです。Amazonが報告しているのは 攻撃の「試行」 であり、記事では、これらが実環境で成功したかは不明としています。「公表前から攻撃試行があった」は確認できますが、「公表前に一般の利用者環境で侵害が成功した」とまでは、この報告だけで断定できません。攻撃者が公表前に情報を得た経緯も不明です。

運用側へのメッセージはシンプルです。「公表後すぐに更新したから、それ以前は安全だった」とは考えない。 Amazonも、PHP2Shellの調査は少なくとも10月17日から始めるよう呼びかけています。ただし、17日はこの報告で確認された日付であって、それより前に攻撃がなかったと保証する境界ではありません。

ログの保存期間や外部公開の履歴を確認し、公表前も含めて調べる範囲を決めましょう。Amazonは、不審なPOSTリクエストに加え、想定外のプロセス実行やWebアプリのファイル変更を確認することも勧めています。リクエスト情報を取得している場合は、フォーム内のPHP_SESSION_UPLOAD_PROGRESSも確認対象ですが、この文字列だけで悪意のある通信とは断定できません。通常のアクセスログにはリクエスト本文が残らないことにも注意します。

なお、これはAmazonの観測報告を紹介しているのであって、AWS固有の脆弱性という話ではありません。PHPをWeb向けに使う環境全般で、更新とあわせて考えたい点です。

対象と前提

PHP2Shellの脆弱性対策と、悪用された可能性がある場合の一般的な対応を扱います。
特定事故を分析した記事ではありません。この記事で攻撃コードの実行や実サーバーでの復旧検証を行ったわけでもありません。
オンプレミス、仮想マシン、コンテナー、レンタルサーバー、マネージド環境に共通する考え方を扱います。実際の作業範囲は、管理権限と事業者との責任分担によって異なります。
採用するPHP・アプリ・プラグインの対応関係は、実施時の公式情報で確認してください。

資料確認日: 2026-10-23。この記事は判断の整理であり、環境別の実行手順書ではありません。

結論：修正版への更新は必須。でも、侵入後の後片付けまではしてくれない

PHP2Shellそのものを直すには、修正を含むPHPへの更新が基本です。公式アドバイザリも、完全な対策は修正版への更新だとしています。設定変更やWAFだけで、同じことができるわけではありません。

ただし、すでに悪用されていたら話は別です。不正なPHPファイルを置かれたり、認証情報を盗まれたりしても、PHPを更新しただけでそれらが元に戻るわけではありません。

状況	対応の考え方
影響するPHPを使っているが、侵害は確認されていない	速やかに修正を適用し、全実行系への反映、露出期間、侵害の兆候を確認する
不正操作や侵害の兆候がある、またはその可能性が高い	脆弱性修正に加え、封じ込め・証拠保全・調査・復旧を行う

影響するPHPを使っていた全環境で、一律にOSを入れ直せという話ではありません。 一方で、「更新したから、それまでの侵害もなかったことになる」と考えるのも危険です。

まずは、修正版が実際に動いているところまで確認する

PHP公式が示す、今回の2件の修正を含む各系列の最初のリリースは次のとおりです。

PHPの系列	修正を含むリリース
8.2系	8.2.35
8.3系	8.3.36
8.4系	8.4.27
8.5系	8.5.12

以降の修正を含む対応リリースでも構いません。LinuxディストリビューションやLTSベンダーのパッケージでは、版番号を大きく変えずに修正をバックポートすることもあります。表示される番号だけで判定せず、提供元のアドバイザリで2件への対応を確認しましょう。

PHP 8.1以前はPHPプロジェクトの通常サポート対象外です。今回提供された一部旧版向けの最小限のソース修正を、通常サポートの再開と取り違えないようにします。ベンダーの対応版を確認するか、サポート中の環境への移行を計画します。

ここで見落としやすいのが、「コマンドで見たPHP」と「Webから使われるPHP」が違うケースです。

CLI版だけ更新して、PHP-FPMやApacheのモジュールは古いまま。
一部のノードやFPMプール、コンテナーだけ更新が漏れている。
パッケージは更新したが、古いワーカーが動き続けている。
別の製品や管理画面に、独立したPHPが組み込まれている。

更新の完了条件は、パッケージのインストール成功ではなく、対象となる実行系すべてで修正が有効になっていること です。必要な再起動・再デプロイ、Web実行系の版、アプリの動作まで確認します。版確認のためにphpinfo()を外部へ公開したままにするのも避けましょう。

PHP公式は、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理する幅広い構成へ注意を呼びかけています。攻撃条件は構成によって違いますが、「mod_phpではないから対象外」とは判断しないでください。

すぐに更新できない場合は、公開経路の制限や停止を含めて判断し、公式の暫定緩和策を確認します。設定値を一つコピーすれば完全に防げる、という状況ではありません。とくにメモリ制限の変更は可用性にも影響するため、前提や副作用を読まずに適用しないようにします。

なお、10月23日にはSession upload progressに関する追加の公式案内も出ています。この機能に関係する経路はCVE-2026-109619にもありますが、追加案内は別件のCVE-2026-115560に関するものです。実行中にセッションのシリアライズ方式を切り替えるなど、特定の設定・アプリの組み合わせが対象です。今回の2件の修正と混同せず、該当条件と推奨設定も確認してください。

PHPを更新しても、すでに置かれたWebシェルは別問題

Webシェルは、攻撃者がWeb経由で操作するための不正なスクリプトなどです。PHP2Shellそのものではなく、悪用後に設置されるものの一例です。

こうした不正コードでも、PHPから見れば実行可能なコードです。新しいPHPと互換性があれば、脆弱性を直した後も動く可能性があります。Webシェル以外にも、不正アカウント、起動設定、盗まれたAPIトークンなどが残るかもしれません。

作業	主に解決すること	自動的には解決しないこと
PHPの更新	該当するPHP自体の脆弱性	アプリの脆弱性、不正ファイル、盗まれた認証情報
アプリ・プラグインの更新	該当するアプリ側の脆弱性	すでに設置された別のバックドアや不正アカウント
不正ファイルの除去	発見済みの操作経路	侵入原因、未発見の操作経路、持ち出された情報
認証情報の失効・更新	盗まれた認証情報によるアクセス	不正コードや改ざんされたデータ
クリーン環境への復旧	汚染された実行環境への依存	移行データの安全性や、未修正の侵入口

また、調査の結果、今回の2件とは別に、アプリの脆弱性や管理者認証情報の漏えいが見つかることもあります。その場合は、そちらも直す必要があります。PHP2Shellを修正したことと、システム全体の安全性を確認したことは別です。

侵入されていそうなら、ここからはインシデント対応

不正なファイルやアカウント、想定外の通信などが見つかったら、ここからは単なる更新作業ではありません。ログがない、あるいはエラーが出ていないだけでは「侵害なし」とは言い切れません。

やっておきたいことを、順にまとめます。停止・データ復元・公開再開は責任者やセキュリティ担当者と判断し、被害防止を優先しながら証拠を確保します。

1. 攻撃者からの操作を止める

公開経路を制限し、必要ならサービスを停止します。Webアクセスだけでなく、不審な外向き通信、バックグラウンド処理、他システムへの接続も対象です。

アプリのメンテナンスモードだけでは、独立したWebシェルや既存プロセスを止められません。ロードバランサーやネットワーク側での制御も検討します。

漏えいした認証情報の悪用が続いている場合は、後の復旧を待たず、初動で失効・利用制限を行います。管理権限が足りなければ、ホスティング事業者やシステム管理者へ連絡します。

2. 削除・更新の前に証拠を確保する

不審ファイル、アクセスログ、認証ログ、設定、DB、ディスクの状態などを保全します。取得時刻・対象・取得者を記録し、侵害ホストとは別のアクセス制限した保管先で管理します。

再起動や上書き更新を先に行うと、プロセスや接続情報、改ざんの痕跡を失う可能性があります。ただし、証拠取得のために進行中の情報流出を放置してよいわけではありません。

不審ファイルを動作確認のために実行しないでください。また、侵害ホスト上の正規名の管理スクリプトも、読み込む設定やライブラリが改ざんされていれば危険です。

ログや設定には個人情報・認証情報が含まれ得ます。公開の解析サービスなどへ無断で送信せず、組織の証拠管理方針に従って扱います。

3. 侵入口と侵害範囲を調べる

アプリ・プラグイン・設定・管理者アカウントを調べ、信頼できる配布物や構成管理の記録と比較します。

確認するのは、発見したPHPファイルだけではありません。不正なアカウント、追加のWebシェル、cronや起動設定による再実行、DBの改ざん、外部サービスへのアクセスも調査対象になります。

OS全体の侵害が疑われるなら、Web公開ディレクトリだけを置き換えても不十分です。専門家による調査と、信頼できるOSイメージからの再構築を検討します。

4. 信頼できる資材から別環境を構築する

クリーンなOS・コンテナーイメージと、確認できるアプリ配布物から復旧先を用意します。必要なプラグインも、対応する修正済みの版から導入します。

旧環境のコードに新しいコードを重ねるだけでは、配布物にない不正ファイルが残る可能性があります。設定ファイルにも不正コードが入り得るため、旧設定をそのままコピーするのではなく、必要な設定値を確認して再設定します。

5. データと認証情報を整理する

DB・アップロードファイル・バックアップも調査対象です。「コードを入れ替えたので、データは全部そのままでよい」とは判断しません。

侵害前と評価できるバックアップや、検査した移行データを使います。DBとファイルの整合性、失われる更新や提出物の範囲も確認します。

同時に、漏えいした可能性のあるパスワード・鍵・APIトークンなどを評価し、必要な失効・更新を行います。ブラウザーのセッションを切っても、APIトークンや外部認証のセッションまで無効になるとは限りません。

更新は正常な管理端末と隔離した復旧先から行い、新しい秘密情報を侵害ホストへ渡さないようにします。データ暗号化鍵まで一律に削除・変更すると復号できなくなるため、鍵の用途と移行方法は別途確認します。

6. 最終データ反映後に検証して公開する

動作確認に加え、不正アカウントの除外、セッション・トークンの失効、コードの書き込み権限、監視を確認します。

最後のDB復元で、古いトークンや不正アカウントが戻る場合があります。 データを追加反映したら、必要なDBアップグレード、是正、認証情報の確認、セッション失効をやり直します。公開可否は、その最終状態で判断します。

原因が特定できない場合は、未解明の範囲・代替策・残余リスクを明示し、責任者の承認を得ます。正常に画面が開くことと、安全に公開できることは別です。

この流れは、侵害が疑われる場合の一般的な対応を整理したものです。検知・対応・復旧を継続的に扱う考え方は、NIST SP 800-61 Rev. 3でも示されています。

サーバーやコンテナーを替えれば解決するのか

サーバーを再構築したり、コンテナーを新しいイメージから起動したりすることは、有力な復旧方法です。ただし、実行環境の交換と、データ・権限の整理は別の作業 です。

同じ外部DBや共有ストレージ、永続ボリュームを接続するなら、そこにあるデータは別に評価します。新しいコンテナーを起動しても、汚染されたボリュームを接続すれば不正ファイルを引き継ぐ可能性があります。再起動だけで、永続領域にある不正ファイルが消えるわけでもありません。

復旧で確認する層は、コード、設定、データ、認証情報、それらを動かす基盤です。ホスティングの形態が変わっても、いずれかを確認しなくてよくなるわけではありません。

環境	復旧で確認する範囲の例
自分で管理するLinux・仮想マシン	OS、アカウント、起動設定、Webサーバー、PHP、アプリ、データ
コンテナー	イメージ、起動設定、実行権限、永続ボリューム、外部サービス。必要に応じてホスト側への影響
レンタルサーバー・マネージド環境	自分の管理範囲にあるアプリ・設定・データ・認証情報と、事業者に調査・対処を依頼する基盤側の範囲

基盤の調査権限がなければ、事業者へ依頼して確認します。「自分で調べられない」と「影響していない」は同じではありません。

「対応済み環境へ切り替えるだけ」ではだめなのか

切り替え先が本当にクリーンで、侵入口と移行データへの対処が済んでいれば、切り替える方法は妥当です。 問題は、「対応済み」が何を意味するかです。

PHPだけを新しくした環境と、侵害を考慮して再構築した環境は同じではありません。

切り替え先の状態	残る問題
PHPだけ新しくして、旧コードをコピーした	不正PHPや未修正のプラグインを持ち込む可能性がある
コードは正常だが、旧ストレージを無検査で接続した	不正ファイルや改ざんデータを引き継ぐ可能性がある
コード・データは検査したが、認証情報はそのまま	盗まれた認証情報で再侵入される可能性がある
原因への対処・データ検査・必要な失効まで完了した	機能・権限・監視を検証し、承認後に切り替える段階へ進める

切り替え操作そのものは短くても、そこに至るまでの準備は省略できません。旧環境は切り替え後も隔離し、障害時に侵害済みの環境へ切り戻さないようにします。

再発防止もPHPの更新だけに頼らない

復旧と並行して、侵入や不正コードの実行を許した構成を見直します。

対策	見直す点
アプリ全体の更新	本体、プラグイン、依存ライブラリを対応する修正版にそろえ、不要なものを撤去する
アップロードの制御	必要な形式・容量・権限を制限し、保存先をWeb公開領域から分離する
書き込み権限の分離	Web実行ユーザーがコードや重要な設定を書き換えられないようにする
管理権限の保護	最小権限、多要素認証、管理経路の制限、認証情報の適切な管理を行う
監視とバックアップ	改ざん・不審な通信・権限変更を監視し、独立した保管先でログと復元可能なバックアップを管理する

アップロード機能の保護は、拡張子を一つ禁止するだけでは足りません。保存場所、ファイルの検証、認可、実行の制限を組み合わせます。OWASP File Upload Cheat Sheetでも、多層防御とWeb公開領域外への保存が推奨されています。

秘密情報の管理も、アプリの再起動とは別です。盗まれた資格情報は、接続先で失効・期限切れになるまで使える場合があります。OWASP Secrets Management Cheat Sheetも、失効・ローテーション・権限管理を扱っています。

最後に、「PHPを上げた」の次まで確認しておきたい

まずは、影響するPHPを洗い出し、修正を適用します。全実行系に修正が反映されたかを確認し、公表前も含む露出期間と侵害の兆候も調べます。侵害が疑われる場合は、さらに次の点を確認します。

PHP2Shellの修正に加え、調査で見つかったアプリ・設定・認証の問題にも対処した。
不正コード、別のバックドア、不正アカウントの有無を調べた。
信頼できる資材から復旧し、DB・ファイル・設定の安全性と整合性を評価した。
必要な認証情報の更新と、セッション・トークンの失効を行った。
最終データ反映後にも、失効や是正が取り消されていないことを確認した。
旧環境の隔離、監視、再侵入時の対応、正常な切り戻し先を用意した。
漏えいの可能性、未確認事項、業務影響、法令・契約上の報告義務を評価した。
残余リスクを含め、責任者が公開再開を承認した。

チェックが埋まったこと自体が、無侵害の証明になるわけではありません。調査できない範囲は、そのまま残して判断に使います。WAFやマルウェアスキャンも有用ですが、検査を通過したことだけで安全とは断定しません。

PHP2Shellの修正には、修正版PHPへの更新が必要です。ただし、すでに侵入された環境では、「入口を閉じること」と「中に残されたものを片付けること」は別 です。

更新を終えた方も、これから対応する方も、まずは無理のない体制で。最後の反映確認と、必要な調査まで含めて対応を終えられるようにしておきたいですね。

参考資料

以下は本文で参照した公開資料です。環境別の設定や対応版は、作業時点の公式資料を確認してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

PHP2Shell対応、PHPを上げたら終わり？ 「更新」と「復旧」は別の話