保守担当者のいない PHP サイトの PHP2Shell 対策

01

変更前に管理権と担当者を回復

ドメイン、ホスティング、サーバー/パネル、コード、DB 資格情報、請求先を確認します。保守承認と復元担当を決め、ローカルファイルで正確なアプリ版を特定します。不足するアカウントやソースを回収してから本番 PHP を変更します。

02

証拠保全と復元演習

侵害が疑われる場合は清掃前にログを保全します。コード、DB、添付、設定、定期処理を同時点の暗号化・アクセス制限したセットで保存し、文字コードと外部ストレージも記録します。私有環境へ復元し内容とログインを確認してください。バックアップ成功表示だけでは不十分です。

03

PHP 世代の差を調べる

PHP 5.3/5.6 は削除済み API に依存し得ます。PHP 7 は ext/mysql、PHP 8 は each()/create_function() を削除し型とシグネチャを厳格化、PHP 8.2 は動的プロパティを非推奨化します。跨ぐ各移行資料を読みます。古い最低条件は運用推奨でも独自コード試験でもありません。

04

修理・移行・静的保存を選ぶ

確認済みベンダーパッチで時間を確保する場合は両 CVE と保守を確認します。保守終了 PHP には継続保守される移行先が必要です。管理可能なら修理、依存が放置されていれば再構築、内容だけなら静的保存を検討し、ログイン・検索・フォームも処理します。

05

本番に近い非公開演習を用意

Web PHP、拡張、INI、DB、ルートを移行先に合わせます。匿名化コピーのアクセスを制限し、実メール、課金、本番 webhook を停止します。本体・プラグイン・独自コードを一緒に試験し、業務検証とログを保存します。運営者はホストへ結果提出を依頼できます。

06

書き込みとスキーマを含む切り戻し

対応するファイルと DB を保管します。PHP を戻しても DB 構造は戻りません。書き込み停止か検証済み同期、失敗条件、担当、期限を決めます。スナップショット後の注文を考慮し、復元と照合を演習します。新規取引を捨てる切り戻しは避けます。

07

切替後の実プロセスを検証

Web PHP、全 FPM、キュー、定期処理、コンテナー、複製を調べ旧プロセスを交換します。両 CVE の修正を上流版かベンダー告知で確認し、深いリンク、認証、添付、業務を試験します。ログと切り戻し期間を確保します。CLI とトップページだけでは不十分です。

PHP2Shell 修正後の業務機能テスト

PHP2Shell修正の確認

アプリ互換性、保守状況、PHPの安全性は別々に確認します。両CVEを修正したサポート中のPHPを選び、Webワーカー、定期処理、全レプリカを確認してください。プラグイン更新だけではPHPは更新されません。