【緊急】PHPの重大脆弱性「PHP2Shell」企業が48時間以内に確認すべきこと
PHPに認証なしでのリモートコード実行につながるおそれのある重大な脆弱性2件（CVSS v4.0 9.2）が公表されました。影響範囲と修正版、48時間以内に実施すべきセルフチェックの手順を解説します。
2026年10月21日、PHP開発チームは、認証なしでリモートコード実行（RCE）につながるおそれのある重大な脆弱性2件を公表しました。「PHP2Shell」と呼ばれるCVE-2026-109618とCVE-2026-109619は、いずれもCVSS v4.0で9.2（Critical）と評価されています。PHP公式は、Webリクエストを処理するPHPのすべての利用者に対し、直ちにアップデートするよう強く勧告しています。
影響はWordPressなどのCMSにとどまらず、自社開発の業務システムや顧客向けWebサービスにも及ぶ可能性があります。問われているのは「PHPを更新したか」だけではありません。「公開中のシステムをすべて把握できているか」「実際に稼働している環境まで修正が反映されているか」「修正後のリスクを検証できたか」――この3点を一連の対応として確認することが重要です。
なぜ今、企業の緊急対応が必要なのか
今回の脆弱性は、PHPがリクエストを処理する際のメモリ管理に起因します。CVE-2026-109618は、メモリ不足（OOM）発生時の異常処理によって未初期化の内部状態が参照される問題、CVE-2026-109619は、リクエスト終了後も古い内部状態が残り、解放済みのメモリが参照され得る問題です。悪用の条件は実行方式や環境によって異なるものの、情報漏えいやリモートコード実行につながるおそれがあります。
PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを受け付けるPHP実行環境に広く注意を呼びかけています。特にmod_phpでは、アプリケーションのコードが実行される前の段階で攻撃が成立する経路も示されています。技術情報がすでに公開されていることを踏まえ、脆弱なシステムの特定と修正を最優先で進めてください。
なお、PHPを利用しているからといって、直ちに侵害されたと断定できるわけではありません。影響の有無は、バージョン、適用済みのセキュリティ更新、実行形態、システム構成などを総合的に踏まえて判断します。
影響を受けるPHPと修正版
| PHP系統 | PHP公式の修正版 | 対応の考え方 |
|---|---|---|
| 8.5 | 8.5.12以降 | 速やかにセキュリティ更新 |
| 8.4 | 8.4.27以降 | 速やかにセキュリティ更新 |
| 8.3 | 8.3.36以降 | 速やかにセキュリティ更新 |
| 8.2 | 8.2.35以降 | サポート期間も確認し移行計画を検討 |
| 8.1以前 | 公式上流の修正版なし | 移行を原則とし、OSベンダーなどの保守パッチも個別確認 |
注意：Linuxディストリビューションなどでは、PHPのバージョン番号を据え置いたままセキュリティ修正のみを取り込む「バックポート」が行われる場合があります。「php -v」の表示だけで修正済みかどうかを判断せず、OSベンダーのセキュリティアドバイザリ、パッケージのリビジョン、実際に稼働しているPHPをあわせて確認してください。
企業が48時間以内に実施すべき緊急セルフチェック
以下は、担当者が作業の優先順位を決めるための目安です。「48時間以内に対応すればよい」という意味ではありません。影響が疑われる公開システムは、可能な限り直ちに修正してください。
STEP 1 | 0〜2時間：公開システムとPHPの利用状況を把握
管理しているWebサイト、業務システム、API、クラウド上のサーバー、コンテナ、さらに運用を委託しているサイトについて、PHPの利用有無を確認します。過去のキャンペーンサイト、検証環境、使われなくなったサブドメインなどは特に見落とされがちです。
- 公開URL、管理者、ホスティング先、PHPの利用有無、実際に稼働しているバージョンを一覧化する。
- PHPの利用状況が不明なサイトを「安全」とみなさず、担当ベンダーや管理者に確認する。
STEP 2 | 2〜8時間：優先順位を付けて修正を適用
PHP公式、OSベンダー、利用中のサービスの案内に従い、対象システムに修正を適用します。顧客情報や認証情報を扱うインターネット公開システムを最優先とし、すぐに更新できない場合は、アクセス制限やサービスの一時停止も検討してください。WAFによる防御はあくまで補完策であり、修正の代わりにはなりません。
STEP 3 | 8〜24時間：修正後のPHPが実際に稼働しているかを確認
パッケージを更新しても、プロセスが入れ替わらなければ修正は反映されません。Apache、PHP-FPM、常駐workerの再起動、コンテナイメージの再ビルドと再デプロイ、Kubernetesで稼働中のPodの入れ替えなどを確認します。CLIのphpとWeb経由で動作するPHPが別構成になっている場合もあるため、実際にリクエストを処理している環境で修正を確認してください。更新後は、WebサイトやAPIの主要な業務機能が正常に動作することもあわせて検証します。
STEP 4 | 24〜48時間：侵害の兆候と残存リスクを点検
Webアクセスログ、PHPエラーログ、不審なプロセスや外部通信、Web公開ディレクトリへの不審なファイルの追加、認証情報やデータベース利用の異常などを確認します。ただし、これらは一般的な侵害の兆候であり、個々の事象だけでPHP2Shellによる攻撃と断定できるものではありません。また、ログに異常がないことが安全の証明になるわけでもありません。侵害が疑われる場合は、証拠を保全したうえで専門家に相談してください。
見落としやすい環境別の確認ポイント
| 運用環境 | 確認すべきこと |
|---|---|
| レンタルサーバー／WordPress | WordPress本体だけでなく、ホスティング事業者が管理するPHPの修正状況を確認。 |
| 自社Linuxサーバー | OSパッケージの更新履歴、稼働中のPHPプロセス、Webサーバーの設定を確認。 |
| Docker／Kubernetes | ベースイメージとビルド成果物に加え、稼働中のコンテナ・Pod、旧ReplicaSetの残存などを確認。 |
| 外部ベンダーの業務システム | PHPの利用有無、影響判定、修正計画、修正完了の証跡をベンダーに照会。 |
パッチを適用しただけで、本当に安全と言えるのか？
セキュリティ更新は最優先事項です。しかし「更新作業を実施した」という記録だけでは、公開中のすべてのシステムに修正が反映されたのか、更新前に不正アクセスを受けていなかったのかまでは判断できません。さらに、PHP2Shellとは別に、Webアプリケーション自体の脆弱性が残っている可能性もあります。
そこで重要になるのが、修正後のセキュリティ診断です。攻撃者の視点に立った検証と証跡に基づく評価により、見落とされがちな残存リスクを可視化できます。なお、外部からの診断だけでは、サーバー内部のパッチ適用状況や過去の侵害の有無を完全に証明することはできません。必要に応じて、内部の設定確認やログ調査と組み合わせることをおすすめします。
緊急対応から再発防止まで：STのPHPセキュリティ診断サービス
ST株式会社では、PHP2Shellへの緊急対応にとどまらず、PHPで構築されたシステムを多角的に診断するサービスを提供しています。状況に応じて、必要なメニューを組み合わせてご利用いただけます。
| フェーズ | サービス | 内容 |
|---|---|---|
| 緊急対応 | PHP2Shell緊急影響調査 | 公開システムを棚卸しし、PHPのバージョン、バックポートの適用状況、実行形態（mod_php／PHP-FPM／php-cgi等）を確認。影響の有無と対応の優先度を判定します。 |
| 緊急対応 | 外部公開資産（アタックサーフェス）調査 | 使われなくなったサブドメイン、旧キャンペーンサイト、検証環境など、把握しきれていないPHP公開資産を外部から洗い出します。 |
| 緊急対応 | 侵害痕跡調査 | Webアクセスログ・PHPエラーログの分析、Webシェルや不審ファイルの探索、不審なプロセス・外部通信の確認を行います。 |
| 修正後の検証 | 修正適用確認・再診断 | 稼働中のプロセス、コンテナ、Podまで修正が反映されているかを確認し、結果を証跡とともに報告します。 |
| 修正後の検証 | ST AI Red Team（AIエージェント型ペネトレーションテスト） | 複数のAIエージェントが攻撃者の視点でWebアプリケーション・API・公開サーバーを検証し、実際の攻撃経路を特定。修正後の再診断まで一貫して対応します。 |
| 継続的な改善 | PHP Webアプリケーション脆弱性診断 | SQLインジェクション、XSS、認証・認可の不備、ファイルアップロード、セッション管理などを診断します。 |
| 継続的な改善 | PHPソースコード診断 | eval、unserialize、動的include、型の緩い比較など、PHP特有の危険な実装をコードレベルでレビューします。 |
| 継続的な改善 | CMS・フレームワーク診断 | WordPress、EC-CUBE、Drupal、Laravel、CakePHP、Symfonyなどの設定、プラグイン・テーマ、管理画面の安全性を確認します。 |
| 継続的な改善 | 依存ライブラリ診断（SCA） | composer.lockを解析し、既知の脆弱性を含むComposerパッケージや保守が終了したライブラリを特定します。 |
| 継続的な改善 | サーバー・実行環境の設定診断 | php.ini（disable_functions、open_basedir、expose_php等）、PHP-FPM、Apache／Nginx、ファイル権限などの設定を点検します。 |
| 継続的な改善 | コンテナイメージ診断 | Dockerのベースイメージやビルド成果物に含まれるPHP・OSパッケージの脆弱性をスキャンします。 |
| 継続的な改善 | EOL版PHPの移行リスク評価 | PHP 8.1以前で稼働するシステムについて、移行時の互換性リスクと、移行完了までの暫定対策を整理します。 |
いずれのメニューでも、検出した問題の影響と改善策を整理してご報告します。修正後の再診断では、結果を「修正済み」「再現あり」「判定不能」に分類し、検証記録とともにお伝えします。
このような企業様におすすめです
- 自社の公開Webシステムに、見落としているリスクがないか確認したい。
- PHP2Shellの影響を受けるかどうか、自社だけでは判断できない。
- 緊急更新後のセキュリティ状態を、第三者の視点で検証したい。
- 診断結果だけでなく、修正の判断に使える具体的な証跡と改善提案がほしい。
- 古いPHPで稼働するシステムを抱えており、移行計画の判断材料がほしい。
各サービスの対象範囲・期間・費用は、対象環境とご要望をお伺いしたうえで個別にご提案します。PHPの更新作業やインシデント対応の支援についても、お気軽にご相談ください。
よくある質問
Q. WordPressを最新版にすれば安全ですか？
A. WordPress本体とPHPの実行環境は別物です。WordPressの更新に加え、サーバー側のPHPにセキュリティ更新が適用されているかも確認してください。
Q. WAFを導入していれば修正しなくても大丈夫ですか？
A. いいえ。WAFはリスクを低減する補完策であり、脆弱なPHPそのものの更新に代わるものではありません。
Q. PHPのバージョンがわからない場合は？
A. ホスティング事業者、システム管理者、開発・運用の委託先に確認してください。公開ページから得られる情報だけでは、正確に判断できない場合があります。
Q. 自社で脆弱性のPoCを実行して確認すべきですか？
A. 出所不明のPoCを本番システムで無断実行することは避けてください。メモリ破壊を伴う検証は、システム障害を引き起こすおそれがあります。診断は、適切な許可と安全管理のもとで実施する必要があります。
Q. PHP2Shell以外のPHPのリスクもまとめて確認できますか？
A. はい。PHPアプリケーションの脆弱性診断、ソースコード診断、Composer依存ライブラリの診断、サーバー設定診断などを組み合わせ、PHPシステム全体のリスクを確認できます。
PHP2Shellへの対応にお困りですか？ STにご相談ください
「自社のシステムが影響を受けるのか判断できない」「修正後の安全性に不安がある」「この機会に公開システムを総点検したい」――。STは、緊急の影響調査から、ST AI Red Teamによる攻撃シミュレーション、修正後の再診断、PHPアプリケーションの継続的な改善まで、一貫してご支援します。
緊急対応で終わらせず、証跡に基づく継続的なセキュリティ改善へ。まずは対象システムとご相談内容をお気軽にお知らせください。
お問い合わせは、当社ウェブサイトのお問い合わせフォームよりお気軽にご連絡ください。
※本記事は2026年10月22日時点の公開情報に基づいています。最新の情報は、PHP公式および各ベンダーの発表をご確認ください。