2026年10月21日、PHPの深刻な脆弱性として「PHP2Shell」が公表されました。対象となる脆弱性は、CVE-2026-109618およびCVE-2026-109619です。悪用された場合、攻撃者が認証なしでサーバー上のコードを実行できる可能性があり、情報漏えいやデータ改ざん、システム停止などの被害につながるおそれがあります。修正パッチを適用するだけでなく、すでに侵害されていないかを確認することも重要です。

本記事では、PHP2Shellによる侵害が疑われる場合に、企業の担当者が取るべき初動対応から安全な復旧までの手順を解説します。

1. PHP2Shellによる侵害が疑われるサイン

PHP2Shellは、PHPの実行環境に関係する深刻な脆弱性です。通常のWebアプリケーションの入力チェックだけでは防げないケースがあるため、PHPのバージョンや実行環境を含めた確認が必要です。

次のような兆候がある場合は、侵害の可能性を考慮して調査を開始しましょう。

ただし、これらの兆候がないからといって、安全だとは限りません。また、異常なアクセスが確認されても、それだけでPHP2Shellによる侵害と断定することはできません。

まずは関連するログやサーバーの状態を確認し、影響範囲を把握することが重要です。

2. 初動対応①：サーバーを隔離する

侵害が疑われる場合、最優先で検討すべきなのがサーバーの隔離です。

攻撃者がサーバー上でコードを実行できる状態が続くと、情報の持ち出しや不正ファイルの設置、他のシステムへの侵入など、被害が拡大する可能性があります。

具体的な対応

1. 外部からのアクセスを制限する
   ファイアウォールやクラウドのセキュリティ設定を利用し、対象サーバーへの不要な通信を遮断します。

2. 必要に応じてサーバーをネットワークから切り離す
   被害の拡大が懸念される場合は、インターネット接続や他の社内システムへの通信を制限します。

3. 関連システムへの影響を確認する
   データベース、ファイルサーバー、認証基盤など、対象サーバーと接続しているシステムへの影響を調査します。

4. 関係者へ速やかに連絡する
   システム管理者、情報セキュリティ担当者、経営層、必要に応じて外部の専門家へ状況を共有します。

隔離によって業務が停止する可能性もあるため、業務への影響とセキュリティリスクを考慮して判断します。ただし、侵害が継続している可能性が高い場合は、被害拡大の防止を優先してください。

なお、証拠を残す必要があるため、専門家の指示なくサーバーを再起動したり、ログやファイルを削除したりすることは避けましょう。

3. 初動対応②：ログと証拠を保全する

サーバーを隔離したら、次に行うのが証拠の保全です。

侵害の原因や攻撃者の操作、情報漏えいの有無を調査するためには、発生時の記録をできるだけ正確に残す必要があります。

保全すべき主な情報

• Webサーバーのアクセスログ、エラーログ

• PHPおよびPHP-FPMのログ

• OSの認証ログ、システムログ

• ファイアウォールやWAFの通信記録

• 不審なプロセス、実行コマンド、通信先の情報

• 変更・追加されたファイルやアカウントの情報

• クラウド環境の監査ログや操作履歴

証拠は可能な限り、侵害されたサーバーとは別の安全な保管先に保存します。保存日時、取得者、取得元も記録しておくと、後の調査に役立ちます。

また、ログの保存期間が短い環境では、古い記録が自動削除される前に確保することが重要です。

4. 初動対応③：侵害範囲と原因を調査する

証拠を保全したら、どこまで侵害が広がっているのかを調査します。

4-1. PHPのバージョンを確認する

まず、対象サーバーで稼働しているPHPのバージョンと実行方式を確認します。PHP-FPM、Apacheのmod_php、php-cgiなど、実行環境によっても確認すべき構成が異なります。

2026年10月21日時点で公表されている修正版は、次のとおりです。

PHP 8.1以前は、PHPプロジェクトによる通常のセキュリティサポートが終了しています。ディストリビューションやベンダーが修正をバックポートしている場合もあるため、パッケージの提供元の情報を確認してください。

4-2. 不審なファイルや操作を調べる

Web公開ディレクトリ内の見慣れないPHPファイル、最近変更された設定ファイル、不審なスクリプトなどを確認します。

また、次の項目も調査対象です。

• 新規作成された管理者アカウントやSSH認証鍵

• 不審なcronジョブや自動起動設定

• PHPプロセスから起動されたシェルや外部コマンド

• データベースへの不審なアクセス

• サーバーからの不自然な外部通信

不審なファイルが見つかった場合、すぐに削除するのではなく、必要な証拠を保全したうえで、専門家と対応方針を決定します。

4-3. 情報漏えいの可能性を確認する

顧客情報、個人情報、認証情報、APIキー、業務データなどへのアクセス履歴を調査します。

漏えいの可能性がある認証情報については、安全な端末からパスワードやAPIキーを変更し、必要に応じてセッションを無効化します。変更作業は、攻撃者が引き続きアクセスできる状態を解消したうえで実施してください。

5. 初動対応④：脆弱性を修正する

侵害範囲の調査と並行して、脆弱性を解消するための作業計画を立てます。

PHP2Shellへの対応では、修正済みのPHPへ更新することが基本です。

パッチ適用の手順

1. 対象となるPHP環境と関連システムを一覧化する。

2. 利用中のPHPバージョンと修正済みバージョンを比較する。

3. 公式パッケージや信頼できるベンダー提供の修正版を準備する。

4. ステージング環境などで互換性と動作を確認する。

5. 本番環境へ修正版を適用し、必要なプロセスやコンテナを再起動・再デプロイする。

6. 更新後のバージョンとアプリケーションの動作を確認する。

コンテナやクラウドサービスを利用している場合は、ホストOSだけでなく、コンテナイメージ、カスタムランタイム、マネージドサービスの実行環境も確認します。ホスト側のPHPを更新しただけでは、アプリケーションが利用するPHPまで修正されない場合があります。

すぐに更新できない場合は、公開範囲の制限や一時停止などを検討します。設定変更による緩和策は完全な修正ではないため、恒久対策として扱わないようにしましょう。

6. 初動対応⑤：安全性を確認してシステムを復旧する

脆弱性を修正しただけでは、復旧が完了したとはいえません。攻撃者が設置した不正ファイルやアカウントが残っている可能性があるためです。

復旧前のチェックリスト

侵害が確認された場合は、信頼できるバックアップやクリーンな環境から再構築する方法も検討します。バックアップ自体に不正なファイルが含まれていないかを確認し、必要なデータのみを安全に移行してください。

復旧後は、アクセスログやプロセス、外部通信を重点的に監視します。異常が再発していないことを確認してから、段階的にサービスを再開することが望ましい対応です。

7. 企業が事前に整備すべきセキュリティ体制

PHP2Shellのような重大な脆弱性への対応では、技術的な対策だけでなく、社内の運用体制も重要です。

平常時から次の仕組みを整備しておきましょう。

• PHPやミドルウェアのバージョンを定期的に棚卸しする

• セキュリティ情報を収集し、パッチ適用の優先順位を決める

• バックアップと復旧訓練を定期的に実施する

• インシデント発生時の連絡先と判断責任者を明確にする

• 外部の開発会社や保守会社との対応範囲を契約で明確にする

• ログ監視、脆弱性診断、アクセス制御を継続的に見直す

特に、長期間運用しているレガシーシステムでは、PHPの更新によって既存機能が動作しなくなる懸念から、パッチ適用が遅れることがあります。その場合も、リスクを放置するのではなく、検証環境の整備や段階的な移行を進めることが大切です。

まとめ

PHP2Shellによる侵害が疑われる場合、重要なのは、サーバーの隔離、証拠の保全、侵害範囲の調査、脆弱性の修正、安全性の確認、段階的な復旧という流れで対応することです。

修正パッチの適用は不可欠ですが、すでに侵害されている場合、不正なファイルやアカウントが自動的に削除されるわけではありません。原因と影響範囲を調査し、必要に応じて専門家の支援を受けながら復旧を進めましょう。

Hatonetでは、PHPを含む既存システムの保守・改善や、AIモダナイゼーションを通じたシステム刷新について、企業の課題に応じた技術支援を検討できます。脆弱性への対応やレガシーシステムの今後の運用にお悩みの場合は、現状の課題整理からご相談ください。