PHP2Shell 企業サーバーのセキュリティ対策

PHP2Shellへの対応は、PHPの使用状況の確認と修正版の適用から始めます。更新後は、実行サービスを再起動してください。侵害が疑われる場合は、再起動前に証拠を保全する必要があります。パッチ適用後もログの点検と認証情報の変更が必要です。

バージョンと設定は、2026年10月22日のKISAの告知と10月23日のPHPの追加告知に基づきます。

PHP2Shellはどのような脆弱性ですか？

PHP2Shellは、認証なしでサーバー上のコードを実行できるPHPの脆弱性です。Webサーバーがリクエストを処理する過程でのメモリ管理の問題です。攻撃が成功するかどうかは、実行環境と設定によって異なります。

KISAは、2つの脆弱性の深刻度をCVSS 9.2点と案内しています。攻撃が成功すると、Webシェルの設置や顧客情報の流出が可能になります。Webシェルは、サーバーの遠隔操作に悪用されるファイルです。Webサイトの改ざんや内部ネットワークへの侵入につながる可能性もあります。

KISAは、パッチ配布前の情報流出と攻撃の試みについて案内しました。研究チームは、AIを活用した脆弱性の発見過程を公開しました。問題はPHP自体にあり、特定のWebサイト製品だけに限られません。KISAの企業向け対応指針、研究チームによるPHP2Shellの説明

×

PHP実行サービスの再起動後、実際のWebサービスにパッチが反映されていることを確認してください。

条件別の対応順序

侵害が疑われるかどうかによって、更新と証拠保全の順序が変わります。通常のパッチ作業では、テスト後に更新と再起動を進めます。侵害が疑われるサーバーは、まず隔離してください。

更新後の再起動は、修正コードを実行するための手順です。インシデント対応中に再起動を見送る理由は、証拠保全です。同じサーバーでも、侵害が疑われる状態なら後者の順序に従ってください。

PHPの使用状況を確認する方法

資産一覧と実際に稼働しているサーバーを併せて確認してください。代表的なWebサイトだけを点検すると、管理対象から漏れたサーバーを見逃す可能性があります。PHPを含む機器やコンテナも確認対象です。

1. インターネットに公開しているWebサイトとシステムを一覧にしてください。
2. 外注で制作したサイトと古いサイトを確認してください。
3. イベント用・テスト用サーバーと管理者ページを確認してください。
4. 機器の管理画面やソリューションにPHPが含まれているか確認してください。
5. コンテナイメージと実行中のコンテナを確認してください。
6. 各環境のPHPバージョンと管理担当者を記録してください。

ホスティングを利用している場合は、業者にパッチが適用されているか確認を依頼してください。機器に含まれるPHPについては、メーカーの更新情報を確認してください。内部システムも点検しつつ、インターネット公開サーバーから対処してください。

PHPの修正版とサポート終了の基準

PHPの公式告知に記載された8.5系の修正版は、8.5.12です。KISAの原文でも同じバージョンを案内しています。8.5.13を待たなければパッチを適用できないという意味ではありません。

表は、2026年10月21日に発表された修正版を基準にしています。ディストリビューションのパッケージでは、表示バージョンが変わらない場合があります。この場合は、変更履歴で2つのCVEが修正されているか確認してください。PHPのセキュリティリリース告知

PHP 8.2のセキュリティサポート終了日は、2026年12月31日です。KISAは、PHP 8.3以上への移行を推奨しています。移行前にアプリケーションの互換性をテストしてください。PHPのサポートスケジュール

PHP 8.1以下は、通常のセキュリティサポートが終了しています。ディストリビューションや長期サポート業者のパッチは、別途確認する必要があります。今回公開された旧バージョン向けのソースパッチも、通常のサポート再開を意味するものではありません。

更新と再起動の方法

インストールファイルを置き換えた後は、PHP実行サービスの再起動が必要です。既存のプロセスが、メモリに残ったコードを実行し続ける可能性があります。侵害が疑われる場合は、以下の作業より先に証拠保全を進めてください。

1. パッチが既存の機能に与える影響を検討してください。
2. テスト環境でサービスの互換性を確認してください。
3. インターネット公開サーバーから修正パッケージを適用してください。
4. PHPを実行するすべてのサービスを再起動してください。
5. コンテナ環境では、修正済みのイメージで再デプロイしてください。
6. 実際のWebリクエストを処理するPHPに修正が反映されているか確認してください。

再起動の対象には、PHP-FPMとApache mod_phpが含まれます。php-cgi、FrankenPHP、LiteSpeedも確認してください。サーバーに複数のPHP環境がある場合は、それぞれ点検する必要があります。

php -vは、コマンドラインで実行されるPHPのバージョンを表示します。Webサービスが使用するPHPとは異なる場合があります。コマンドラインの出力だけで更新完了と判断しないでください。

更新前の暫定設定の基準

暫定措置は、一部の攻撃経路を減らす手段です。脆弱性全体を解消するものではありません。設定の適用が難しい場合は、外部接続の遮断を検討してください。

memory_limitの設定はどのように適用しますか？

今回の脆弱性に対する公式の暫定推奨設定は、memory_limit=-1です。この値は、PHP自体のメモリ使用量の上限を解除します。通常の運用設定として受け取らないでください。

上限を解除すると、メモリ不足を引き起こす特定の経路が減ります。実際のメモリ割り当ての失敗まで防ぐ設定ではありません。リクエストサイズの制限とリソース管理対策を併せて検討する必要があります。PHPのメモリ不足に関する脆弱性の勧告

表の設定値は、2026年10月の公式対応告知に基づいています。8Mは、アップロードが不要なサービス向けに示された例です。すべてのサービスに同じサイズを適用する基準ではありません。

1. Webアプリケーションファイアウォール・Webサーバー・プロキシでリクエストサイズを制限してください。
2. サイズ情報がないリクエストにも制限が適用されるか確認してください。
3. アップロードが不要な場合は、multipartリクエストを前段で遮断してください。
4. Webアプリケーションファイアウォールの最新の遮断ルールを確認してください。
5. php.iniやPHP-FPM poolなどで設定を適用してください。
6. 証拠保全が必要か確認したうえで、PHPプロセスを再起動してください。

ini_set()だけで暫定設定を適用しないでください。リクエスト処理前に必要な設定の適用が遅れる可能性があります。PHP-FPMの.user.iniにも、同じ役割を期待しないでください。PHPの公式暫定措置

10月23日の追加告知で確認する内容

PHPは追加告知で、アップロード進捗機能を無効にするよう推奨しました。一部の設定の組み合わせに残る、別の実行経路についての案内です。すでに機能を無効にしている場合は、次回の定期修正リリースまで維持するよう案内しています。

該当する条件には、実行中のセッションのシリアライズ方式の変更が含まれます。すべてのPHP環境で同じ条件が成立するわけではありません。パッチ適用後に設定を戻すかどうかは、追加告知を確認して決めてください。（確認値 session.upload_progress.enabled=0を次回の定期バグ修正リリースまで維持するよう推奨 · 出典 php.net · 2026-10-23確認）PHP Session upload progressの追加告知

ログの点検と認証情報の変更方法

KISAは、少なくとも2026年10月20日以降の記録を点検するよう推奨しています。可能であれば、それ以前の記録も確認してください。パッチを適用しても、すでに発生した侵害や情報流出を元に戻すことはできません。

エラーがあるという事実だけでは、侵害を断定できません。逆に、異常な記録がないからといって、安全を断定することもできません。KISAは次のように案内しています。

記録上の異常がなくても安全は保証されないため、更新と認証情報の変更を併せて進めてください。

KISA「PHPのセキュリティ脆弱性(PHP2Shell)に関する企業向けセキュリティ対応指針」

パッチ適用前にインターネットに公開されていたサーバーでは、認証情報の変更が推奨されます。侵害の痕跡が見つかったサーバーでは、必ず変更してください。対象には、DBパスワードと管理者パスワードが含まれます。APIキーとアクセストークンも、漏えいの可能性を点検してください。

個人情報DBに接続するサービスでは、DBの記録も確認してください。大量照会や持ち出しの痕跡を点検する必要があります。phpMyAdminへのインターネットからの直接アクセスも制限してください。Webサービス用アカウントのDB権限は、必要な範囲に絞ってください。개인정보보호위원회の予防措置の案内

侵害が疑われる場合の対応順序

侵害が疑われる場合は、サーバーの電源を切ったり、すぐに再起動したりしないでください。再起動によって、メモリに残る攻撃の痕跡が消える可能性があります。ネットワークから隔離した後、証拠の確保を進めてください。

1. サーバーの外部接続をネットワークで遮断してください。
2. 韓国国内の企業は、보호나라の侵害インシデント通報メニューから通報してください。
3. ログと実行中のプログラム一覧を保全してください。
4. 現在のネットワーク接続情報も保全してください。
5. 証拠を確保した後、更新と再起動を進めてください。
6. Webシェルの除去と認証情報の変更を進めてください。

韓国国内の相談窓口は、KISA 118です。通報メニューは、보호나라 > 侵害インシデントの通報 > 通報する、です。海外で運用している場合は、その地域の通報窓口を確認してください。

よくある誤りの比較

パッチの適用状況は、実行状態と変更履歴まで確認する必要があります。インストール完了メッセージだけでは、確認は終わりません。次の判断をチェックリストに入れておいてください。

インターネットで見つけた検証コードを、本番サーバーで実行しないでください。KISAは、マルウェアを含む偽のPoCについて警告しています。PoCは、脆弱性を悪用できることを示す検証コードです。脆弱性の影響を受けるかどうかは、まずバージョンとパッチ履歴から確認してください。

外注・ホスティング環境の対応完了確認表

対応完了報告には、サービスごとに確認の根拠を残すとよいです。以下の表は、KISAの対応指針を業務上の確認項目としてまとめたものです。別途定められた公式の提出様式ではありません。

例えば、業者からパッケージのインストール完了だけが報告されたとします。この場合は、再起動とWeb実行環境の確認結果を依頼してください。ログの点検と認証情報の変更は、別項目として確認すればよいです。