「php2shellという重大な脆弱性が出た」「今すぐPHPを直さないと危険」と聞き、
共有レンタルサーバーで何をすればよいのか不安になっていませんか？
今回の問題はWordPressの設定ミスではなく、Webサイトを動かすPHP本体の問題です。
ただし、共有サーバーのPHP本体は通常、利用者ではなくサーバー会社が管理します。
結論は、契約しているサーバーの種類によって対応者が異なります。
共有サーバーは提供会社が対応しますが、AWS・VPS・専用サーバーなどの自己管理環境は利用者側の更新が必要です。
よこやま良平ITエンジニアとして20年以上、WordPressとPHPのトラブル対応に携わってきたよこやま良平です。今回はphp2shellの仕組みと、共有サーバー利用者が「しなくてよいこと」まで初心者向けに整理します。
- php2shellがどのような脆弱性なのか
- 共有サーバー利用者が慌てて作業しなくてよい理由
- AWS・VPS・専用サーバー・Dockerで必要な対応
- 国内レンタルサーバー会社の対応状況
- 顧客や社内へ送れる安心案内メールの例文
- 被害の兆候がある時だけ確認するポイント
php2shellは深刻度の高い問題ですが、「脆弱性がある」と「自分のサイトが侵害された」は別です。
まず契約形態を確認し、PHPを管理している人・会社が修正版を適用してください。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
php2shellとはPHP本体で起きる重大な脆弱性
php2shellは、PHP本体に見つかった2件の脆弱性の通称です。
CVE-2026-109618とCVE-2026-109619として公表され、いずれも深刻度はCVSS 9.2です。
悪用されると、ログインしていない第三者が細工した通信を送り、
サーバー上で命令を実行するリモートコード実行につながるおそれがあります。
PHPを建物の設備にたとえると理解しやすい
WordPressをお店、レンタルサーバーを建物、PHPを建物内の共通設備にたとえてみましょう。
今回は、お店の商品ではなく建物の設備に重大な欠陥が見つかった状態です。
共有ビルの配管や電気設備を各テナントが勝手に交換できないのと同じで、
共有サーバーのPHP本体も、通常はサーバー会社が修正します。
WordPressやプラグインだけの問題ではない
php2shellはPHPがWebから受け取った通信を処理する途中で起きる問題です。
そのため、WordPressだけでなく、PHPで動くWebシステム全般が確認対象になります。
WordPress本体やプラグインを最新版にすることは日常の対策として重要ですが、
今回の根本対策はPHP側の修正版を適用することです。
- PHP本体に見つかった2件の重大な脆弱性
- ログイン前の通信から悪用されるおそれがある
- WordPressの更新だけでは根本対策にならない
- 完全な対策は修正版PHPの適用
PHP公式は、Webリクエストを処理するPHP環境が確認対象であり、
修正版へすぐ更新するよう案内しています。
php2shellの修正版と影響を受けるPHP
PHP公式は2026年10月21日、php2shellを修正したPHPを公開しました。
公式に示された修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。
PHP 8.1以前はPHPプロジェクトの通常サポートが終了しています。
ただし、サーバー会社やOS提供元が修正だけを古い版へ戻す「バックポート」を行う場合があります。
表示された番号だけで未対策と断定しない
管理画面に古いPHPの番号が表示されていても、サーバー会社が独自修正を適用していることがあります。
バージョン番号だけを見て「未対策」と断定せず、公式告知を確認してください。
反対に、PHP 8.2や8.3という大きな番号だけでは修正版か判断できません。
サーバー会社が適用完了を案内しているか、細かなパッチ番号まで確認する必要があります。
WAFは補助でありPHP更新の代わりではない
Cloudflareなどはphp2shellを狙う通信を遮断するWAF対策を展開しています。
しかし、WAFは攻撃を入口で減らす多層防御であり、PHP本体の欠陥を消すものではありません。
Cloudflare自身も、WAFを利用していてもPHPを修正版へ更新するよう案内しています。
共有サーバーでは、その更新作業をサーバー会社が実施します。
php2shellの対応者はサーバーの契約形態で異なる
php2shellで最初に確認するのはPHPの番号よりも、誰がPHPを管理しているかです。
同じ「レンタルサーバー」「クラウド」という名称でも、契約内容によって責任範囲が変わります。
| 利用環境 | 主な対応者 | 利用者が行うこと |
|---|---|---|
| 共有レンタルサーバー | サーバー会社 | 公式告知と適用完了を確認する |
| マネージドWordPress | サービス提供会社 | 提供会社の案内と対象範囲を確認する |
| 保守付きVPS・専用サーバー | 契約した保守会社 | PHP更新・再起動・侵害確認の実施状況を問い合わせる |
| 自己管理VPS・専用サーバー | 利用者・管理者 | OS提供元の修正パッケージを適用してサービスを再起動する |
| AWS EC2・Lightsail | 原則として利用者 | ゲストOSとPHPを更新し、実際の稼働版を確認する |
| Docker・ECS・EKS等 | コンテナイメージ管理者 | 修正版PHPを含むイメージへ再ビルド・再デプロイする |
判断基準は「root権限やsudo権限を持ち、OSやPHPを自分で更新する契約か」です。
管理権限を持つだけでなく、保守契約で更新作業を委託している場合は、委託先へ対応状況を確認します。
- 共有型・VPS・専用・クラウドのどの契約か
- OSとPHPの更新責任が利用者・提供会社・保守会社の誰にあるか
- Webサイトが実際に使用しているPHPと実行方式は何か
共有サーバーのphp2shell対応は利用者が何もしないのが基本
共有レンタルサーバーでは、php2shellの修正を利用者が直接行う必要はありません。
OS、Webサーバー、PHP本体はサーバー会社の管理範囲だからです。
サーバー会社は修正版の検証、全利用者への適用、PHPプロセスの再起動、
必要に応じたWAFやアクセス制限までまとめて実施します。
利用者がしなくてよいこと
不安でも、インターネット上で見つけた暫定設定をそのまま入れたり、
非公式のPHPファイルをWordPressへ置いたりしないでください。
- 非公式サイトから修正ファイルや検査ツールを入れる
- 意味を理解せずphp.iniや.htaccessを書き換える
- メンテナンス中に何度も管理画面へログインする
- WordPressやサイトデータを慌てて削除する
- 緊急更新を装うメールのリンクからログインする
利用者が確認するのは公式告知と異常の有無だけ
サーバー会社の公式サイト、契約者向け管理画面、登録メールに届く案内を確認します。
管理画面が予防措置で停止している場合は、再開するまで待ってください。
サーバー会社から「対応済み」「利用者の作業不要」と案内されたら、それ以上の操作は不要です。
PHPの切り替えを個別に求められた場合だけ、バックアップと動作確認を行って指示に従います。
AWS・VPS・専用サーバーのphp2shell対応は利用者側で行う
AWS EC2、Amazon Lightsail、自己管理VPS、専用サーバーでは、
原則として利用者または契約した管理会社がOSとPHPを更新します。
AWSは物理設備や仮想化基盤を保護しますが、EC2内のゲストOS、PHP、Webサーバー、
利用者が導入したアプリケーションの更新はAWSが自動で行うわけではありません。
AWS EC2と自己管理VPSはOSの修正パッケージを適用する
最初にスナップショットや復元可能なバックアップを確保し、OSとPHPの提供元を確認します。
そのうえで、Ubuntu・Debian・Amazon Linux・AlmaLinuxなど各OSの公式更新を適用してください。
# 稼働中のOSとPHPを確認する例
cat /etc/os-release
php -v
php-fpm -v
# Debian・Ubuntu系の更新例
sudo apt update
sudo apt upgrade
# RHEL・AlmaLinux・Rocky Linux・Amazon Linux 2023系の更新例
sudo dnf update表示されるPHP番号だけでなく、OSベンダーが修正をバックポートしているかも確認します。
古い番号のまま修正だけが適用される場合があるため、公式セキュリティ情報との照合が必要です。
PHP-FPM・Apache・コンテナを再起動して稼働版を切り替える
パッケージを更新しただけでは、古いPHPプロセスがメモリ上に残る場合があります。
PHP-FPM、Apache、コンテナなど実際にPHPを実行するサービスを再起動してください。
# サービス名はOSとPHPの版によって異なります
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
# 再起動後に状態と稼働版を確認する例
sudo systemctl status php8.3-fpm
php-fpm8.3 -vApacheのmod_php、Nginx＋PHP-FPM、LiteSpeedなど構成によって再起動対象は異なります。
サービス名が分からない場合は推測で停止せず、構築担当者や保守会社へ確認してください。
Amazon Lightsailも作成後のOSとPHPは利用者が更新する
LightsailのWordPressやLAMP環境も、インスタンス作成後のOSやアプリケーションを、
AWSが継続的に自動更新するサービスではありません。
Bitnamiイメージなどは独自の構成を使用する場合があるため、通常のOSパッケージだけでなく、
イメージ提供元の更新方法、移行手順、サポート対象も確認してください。
Docker・ECS・EKSでphp2shellを直す時はイメージを作り直す
Docker、Amazon ECS、Amazon EKS、Kubernetesでは、稼働中コンテナの中だけを更新して終わらせません。
修正版PHPを含むベースイメージへ更新し、新しいイメージを再ビルドして再デプロイします。
タグだけでなく実際のイメージを更新する
php:8.3-fpmのようなタグは、同じ名前でも中身が更新される場合があります。
新しいベースイメージを明示的に取得し、キャッシュだけで古いレイヤーを再利用していないか確認します。
# 例：ベースイメージを取得してキャッシュなしで再ビルド
docker pull php:8.3-fpm
docker build --pull --no-cache -t example-app:patched .
# 新しいコンテナ内のPHPを確認
docker run --rm example-app:patched php -v再デプロイ後に古いタスクやPodを残さない
ECSのタスク定義、EKSのDeployment、Kubernetesのマニフェストを新しいイメージへ更新し、
古いタスク・Pod・コンテナがすべて置き換わったことを確認します。
ロードバランサー配下に旧コンテナが1台でも残ると、その経路だけ脆弱な状態が続きます。
イメージのダイジェスト、稼働タスク数、各コンテナのPHP版を照合してください。
php2shell更新後も侵害の有無を確認する
PHPを修正版へ更新すると今後の悪用を防げますが、更新前に侵入されていなかった証明にはなりません。
インターネットへ公開していた自己管理サーバーでは、更新と侵害確認を分けて実施します。
- Webで実際に動いているPHPが修正版またはベンダー修正版か
- PHPやWebサーバーの全プロセスが再起動後のものか
- Webサーバープロセスから不審なシェルや外部通信が起動していないか
- 不審なPHP、Cron、SSH鍵、ユーザー、コンテナが追加されていないか
- 更新前後のアクセスログ・WAF・認証ログに異常がないか
侵害の兆候がある場合は、ログや不審ファイルを削除する前に証拠を保全してください。
パッチ適用、侵入経路の調査、マルウェア駆除、認証情報の交換までが復旧作業です。
php2shellに対する国内サーバー会社の対応状況
国内の主要サーバー会社は、修正版の適用、緊急メンテナンス、予防的な機能停止などを進めています。
以下は2026年10月22日8時ごろに公式告知を確認した内容です。
メンテナンスの理由にPHPと明記していない会社もあります。
同時期の作業というだけでphp2shell対応と断定せず、各社が公表した範囲を記載しています。
PHPへの対応を明記した会社
- KAGOYA：PHP 8.2〜8.5系は修正版確認後に順次更新予定。ほかのプランや版は対応方針を調整中
- ロリポップ！：予防措置として管理機能などを停止し、一部サーバーでは修正版適用までサイトを一時停止
- WebARENA SuiteX：海外アクセス制限とPHPのファイルアップロード進捗機能の停止を実施
緊急メンテナンスや予防停止を告知した会社
エックスサーバーは公式サイトや管理画面などを予防的に停止し、
利用者サーバーへ緩和策と修正を順次適用すると案内しました。サイト表示とメールは継続しています。
さくらのレンタルサーバは10月21日13時から22日8時ごろまで、
ConoHa WINGは21日19時から22日10時まで一部サーバーの緊急メンテナンスを告知しました。
お名前.comレンタルサーバー、カラフルボックス、mixhostも保守作業や予防的な停止を告知しています。
ただし、公式本文でphp2shellとの関係を明記していない告知は、関連を断定できません。
内リンクではなく公式サイトを直接開くと安全です。
php2shellで個別調査が必要になる症状
公式対応を待つだけでよいのは、サイトに異常が見つかっていない場合です。
改ざんや不正利用の兆候がある時は、php2shellとの関係を決めつけず個別調査を始めます。
不審な変化があれば証拠を消さない
- 見覚えのない管理者ユーザーが追加されている
- 検索結果やスマホだけ別サイトへ転送される
- 知らないPHPファイルやCronが作成されている
- 大量メール送信や身に覚えのないログイン通知がある
- サーバー会社から不正プログラム検知の連絡が届いた
異常を見つけたら、すぐにファイルを削除する前に、時刻、URL、画面、更新ファイル、ログを保存します。
削除だけでは侵入経路や残存バックドアを見落とし、証拠も失う可能性があります。
php2shellについてよくある質問
php2shellは契約形態ごとの管理者がPHPを更新する
php2shellの根本対策は、修正版またはベンダーが修正したPHPを適用し、
古いPHPプロセスやコンテナを再起動・再デプロイすることです。
共有サーバーは提供会社の公式対応を待ち、AWS・VPS・専用サーバー・コンテナは管理者が更新します。
更新前に公開されていた環境では、パッチ適用後も侵害の兆候を確認してください。
- 共有サーバー・マネージドWordPressは提供会社の告知を確認する
- AWS EC2・Lightsail・自己管理VPS・専用サーバーは利用者側で更新する
- Docker・ECS・EKSは修正版PHPを含むイメージへ再デプロイする
- 保守委託中は更新・再起動・侵害確認の完了を委託先へ確認する
- どの環境でもパッチ適用と侵害調査を同じものと考えない
php2shellの影響や不審な症状が判断できない時は
サーバー会社やAWS・VPSの対応状況が分からない、サイトに不審な変化がある、
侵害の有無を自分で判断できない場合は、クイックレスキューへご相談ください。
- php2shellの影響を受ける環境か分からない
- サイトに見覚えのない変更や転送がある
- サーバー会社から不正プログラム検知の連絡が届いた
- 更新後のWordPressやPHPの動作確認を任せたい
