PHP2Shell：修正版とホスティング確認チェックリスト

PHP2Shellで何が起きたのか

2026年10月21日、PHPはCVE-2026-109618とCVE-2026-109619に対するセキュリティ更新を公開しました。いずれも条件を満たすと、認証なしでリモートコード実行につながる可能性があります。CVSS v4.0のスコアはともに9.2です。これは技術的な深刻度を示すものであり、特定の企業が既に攻撃された確率を表すものではありません。

PHP Foundationは、メモリ関連の問題の修正に遅れがあったことや、調整された情報公開に問題が生じたことを説明しています。情報が予定より早く公開されたため、リリースは1日前倒しされました。運用側がまず確認すべきなのは、どの稼働システムに修正が実際に反映されているかです。 [1] [3] [4]

修正を含むPHPのバージョンは？

下表は、10月21日に公表された2件の脆弱性を最初に修正したPHP公式リリースです。10月23日に追加で公表されたCVE-2026-115560まで解決済みという意味ではありません。その後のベンダー勧告も確認してください。

Linuxディストリビューションやマネージドホスティングのパッケージには、古いPHPのバージョン番号のまま修正がバックポートされている場合があります。その場合は、完全なパッケージバージョンとベンダーのセキュリティ情報を根拠にします。PHP 8.1以前の系統には、PHPプロジェクトによる通常の更新は提供されていません。ベンダーのバックポートや公開された最小限のソースパッチは、個別の検証が必要です。これらを適用しても、サポート対象の系統への計画的な移行は必要です。 [1] [4]

表は左右にスクロールできます。

10月23日のセッション追加勧告も確認する

PHPは、次回の通常バグ修正リリースまで、一時的にsession.upload_progress.enabled=0を設定することを推奨しています。この勧告はCVE-2026-115560に関するもので、設定とアプリケーションコードの特殊な組み合わせが条件です。修正済みの2件とは分けて扱う必要があります。

公表された条件は具体的です。session.serialize_handlerの初期値がphp_binaryまたはphp_serializeで、アプリケーションがsession_start()を呼び出す前に、ini_set()を使って実行中にphpへ変更し、かつセッションのアップロード進捗機能が有効になっている場合です。PHPによれば、実行中にハンドラーを変更しないアプリケーションでは、この機能を有効のままにできます。

実際に有効な設定を管理者に確認してください。予防措置として無効化する場合は、リクエストの解析前に反映されるサーバーまたはPHPの設定で行い、対象のワーカープロセスを再起動します。アプリケーションコード内で後から呼び出すini_set()は、その代わりにはなりません。既に設定した場合は維持してください。勧告では、通常の修正版の公開日や新たなバージョン番号はまだ示されていません。本稿の確認時点は2026年10月24日です。 [1] [2]

WordPressの更新だけでは足りない理由

CMSとPHPの実行環境は別の構成要素です。WordPress、Drupal、Joomlaを更新しても、Webサーバーが修正済みのPHPを実行している証拠にはなりません。Webサイトが正常に表示されることも、パッチ適用の確認にはなりません。

メインサイトだけでなく、オンラインストア、顧客ポータル、サブドメイン、古い構成のシステムも対象に含めます。各システムでWebリクエストを実際に処理する経路を確認してください。PHP-FPMが一律に対象外となるわけではありません。PHPはmod_php、CGI、FrankenPHP、LiteSpeedにも言及しています。コマンドラインでは、Webサーバーとは別のPHPが使われている場合があります。確認のために、誰でもアクセスできるphpinfo()ページを公開しないでください。 [1] [5]

詳しく読む：更新が公開されても既知の脆弱性が残る理由

ホスティング事業者に何を確認するか

「当社のサーバーは最新です」という一般的な回答では、重要な点が未確認のまま残ります。自社の対象システムについて、具体的な回答を求めてください。次の文面を利用できます。

当社Webサイトで使用しているPHPのWeb実行環境とパッケージバージョン、CVE-2026-109618およびCVE-2026-109619の修正状況、ならびにCVE-2026-115560に関する2026年10月23日付PHP勧告への対応状況をご確認ください。反映時刻と、根拠となるベンダーまたはディストリビューションの勧告も併せてご提示ください。

表は左右にスクロールできます。

WAFの警告と攻撃の試行から分かること

Webアプリケーションファイアウォールは、特定の攻撃経路に対する追加の防御になり得ます。ただし、PHPの更新や有効な設定の確認を置き換えるものではありません。すぐに更新できない場合は、責任を持つ管理者とアクセス制限などの措置や一時的な隔離を検討し、ベンダーの指針全体に従ってください。

AWSは、一般公開前の試行をMadPotの観測データで記録しています。一方で、これらの試行が実環境で成功したかどうかは不明としています。したがって、試行回数は侵害された企業の数ではありません。逆に、ダッシュボードに異常が見られないことも、インスタンスが無傷だった証明にはなりません。 [1] [5] [6]

対応を完了と判断するために

システムごとに、責任者、有効なパッケージ、ベンダーの根拠資料、反映時刻、機能テストの結果を記録します。パッチ適用の確認とインシデント調査は分けてください。今日修正されたという事実だけでは、更新前に何が起きたかは分かりません。

不審なファイル変更、予期しないプロセス、疑わしいアクセスなど、侵害を示す兆候があれば、利用可能なログを保全し、担当のインシデント対応チームに相談してください。外部セキュリティ評価では、外から見えるシステムや異常を調べられます。ただし、追加の証拠なしに内部のパッケージ状態や侵害の有無を確定することはできません。

• 関連するPHPのWebシステムと責任者を記録した。
• 当初の2件のCVEに対する修正を、稼働中のインスタンスで確認した。
• 10月23日のセッション勧告を別途確認し、対応を記録した。
• 変更後に業務上重要な機能を確認した。
• 未解決のシステムに、次の対応と期限を設定した。
• 疑わしい事象は別途調査し、パッチ適用だけで侵害なしとは判断していない。