ロリポップ！のPHP2Shell対応は完了？WordPress利用者の確認手順【2026年10月】
「ロリポップのWordPressもPHP2Shellの対策が必要？」「PHP 7.4の表示なのに大丈夫？」「2026年10月22日の停止後、何を確認すればよい？」という疑問に答えます。ロリポップ！は2026年10月22日、提供する全PHPバージョンに今回の脆弱性対策を適用してサイト表示を再開したと発表しました。したがって、同社提供のPHPを利用するサイトで、今回の二つのCVEを直すためだけに慌ててPHPの系列を切り替える必要はありません。一方、古い系列は今後の更新が不確実です。サイトの動作を確認したうえで、サポート中のPHPへの移行を計画してください。
本記事はロリポップ！でWordPressを運用する担当者向けの実務手順です。2026年10月26日時点のロリポップ！公式の経緯報告、PHP設定マニュアル、PHP公式セキュリティ勧告を照合しました。契約プランやサーバーごとの状態はユーザー専用ページとサポートで確かめます。一般的な脆弱性の仕組みはPHP2ShellとWordPressの総合解説、複数社の比較はレンタルサーバー別対応をご覧ください。
目次
ロリポップ！のPHP2Shell対応は完了したのか
結論は「ロリポップ！が提供する全系列に今回の修正を適用済み」です。対象のCVEはCVE-2026-109618とCVE-2026-109619です。ロリポップ！は2026年10月22日13時ごろにサイト表示を再開し、PHP 8.2〜8.5へ開発元の修正版、PHP 7.4〜8.1へ開発元が公開した修正コード、PHP 5.3〜7.3へ同社が作成・検証した修正を適用したと説明しています。これは「すべての古いPHPが将来も安全」という意味ではありません。今回の二件についての対策と、長期的にサポートされるPHPへの移行は別の作業です。
| ロリポップ！の提供版 | 2026年10月22日の対応 | 利用者の次の行動 |
|---|---|---|
| PHP 8.2・8.3・8.4・8.5 | PHP開発元の修正版を適用 | 重要機能を検品し、今後の保守計画を確認 |
| PHP 7.4・8.0・8.1 | 開発元の修正コードを適用 | 今回の修正を認識したうえで、サポート中の版へ移行を計画 |
| PHP 5.3〜7.3 | ロリポップ！が修正を作成・検証し適用 | 互換性を調べ、移行の期限と担当者を決める |
ロリポップ！の発表によると、全バージョンでsession.upload_progressが無効化されています。これは2026年10月23日にPHP開発元が公表したセッションアップロード進捗に関する追加の情報とも関係します。サイトでファイルを受け付ける場合、アップロードそのものだけでなく「進捗表示」を実際に使う独自機能がないか確認してください。すべてのWordPressサイトで障害が起きるという発表ではありません。機能を使っていないサイトは通常どおり動く可能性がありますが、個別サイトのテストは省略しないでください。
「PHP 7.4」と表示されても、今回の対策が未適用とは限らない
PHP公式が発表した修正版は8.2.35、8.3.36、8.4.27、8.5.12です。ただしレンタルサーバーは、古い系列へ修正コードを戻す場合があります。画面にPHP 7.4と表示されることだけを根拠に「ロリポップの今回の修正は未適用」と断定するのは誤りです。同社の公式告知と利用中のサービス形態を合わせて判断します。反対に、修正済みという同社の一般告知だけで、自分のWordPressのプラグイン、テーマ、独自コードまで安全だと結論づけることもできません。
メンテナンス中の停止と侵害を混同しない
10月21日から22日にかけてサイトが表示されなかった場合、それだけで攻撃成功や改ざんを意味しません。ロリポップ！は修正適用までの予防措置として一部サーバーの表示を止め、サーバー単位の停止だったためPHPを使用しないサイトにも影響したと説明しています。同社は脆弱性を狙ったとみられるアクセスを確認した一方、発表時点でそれによる不正アクセス・情報漏えいは確認していないとしています。「侵害は絶対になかった」と言い換えず、自サイトの不審な変更、管理者アカウント、アクセスログ、フォーム送信結果を必要に応じて点検します。
現在も表示できないなら、古い障害情報を原因と決めつけないでください。最新の障害・メンテナンス情報と契約中サーバー、WordPressのエラーを切り分けます。サイト再開後のHTTP 500や白画面はPHP更新後の500エラー対処を参照し、発生時刻、URL、エラーの再現操作を先に記録してください。
ユーザー専用ページで自サイトのPHP設定を確認する
作業対象はWordPressの管理画面ではなく、まずロリポップ！のユーザー専用ページです。公式マニュアルでは、ログイン後に「サーバーの管理・設定」から「PHP設定」を開き、PHP設定エリアでドメインごとの版を確認すると案内しています。複数の独自ドメイン、サブドメイン、検証サイトを運用している場合、トップページのドメインだけを見て全サイトを確認済みにしないでください。
- 運用担当者が、契約中アカウントと対象ドメインの一覧を用意します。WordPress本番、ステージング、フォーム用サブドメインを分けます。
- ロリポップ！ユーザー専用ページへログインし、「サーバーの管理・設定」→「PHP設定」へ進みます。現在値、選択可能な版、CGI版かLiteSpeed版かなど画面に出る提供形態を記録します。
- WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」でWeb側のPHP版を確認し、サーバー画面の対象ドメインと突き合わせます。反映待ちや別ドメインを見ていないか確認します。
- ロリポップ！の公式修正告知の確認日を記録します。契約サービスが告知範囲と異なる、独自に実行環境を構成したなどの疑いがあればサポートへ質問します。
マニュアルでは設定変更の反映に5〜10分ほどかかるとされています。変更直後の表示値だけで失敗と判断せず、時間を置き、キャッシュを除いた公開画面と管理画面で再確認します。CLIでphp -vを実行できる環境でも、その結果はシェルのPHPで、Webリクエストに使われるPHPと異なることがあります。公開側の検証を優先してください。一時的なphpinfo()ページは設定やパスが露出し得るため、むやみに公開しないでください。
版を変えるべきか、まず動作確認すべきか
今回のCVEへの修正を受ける目的だけなら、同社提供PHPは対策済みです。そこで最初の意思決定は「今すぐ版を切り替えるか」ではなく「現在のサイトに障害がないか」です。問い合わせ、会員登録、ログイン、画像投稿、予約・決済、メール通知など、サイト固有の重要操作を短時間で検品します。そのうえで旧系列から8.3以降などへの移行を計画します。WordPressはPHP 8.3以上を推奨していますが、導入版はテーマ・プラグインの対応、ロリポップ！の選択肢、検証結果で決めます。
変更対象のドメインを間違えると、関係ないサイトへ影響します。変更前後でドメイン名、現在値、変更先、時刻、担当者を記録し、作業を一件ずつ実施します。特に複数サイトを同じアカウントで動かす場合、管理画面の「すべてのドメイン」を一括設定する操作は慎重に扱います。事前に影響範囲を把握できないなら、一括変更を避けます。
古いPHPから移行する前に行うバックアップと互換性テスト
ロリポップ！はPHP 8.1以下への今回の修正を応急的な対応と説明し、開発元のサポートが続く版へ切り替えるよう求めています。ただし、旧版から新しい版へ変更するとアプリの仕様差で表示や処理が壊れる場合があります。修正済みの現環境を検品してから、計画的に移行するのが実務的です。古い版だからと焦って本番を直変更し、フォームが動かなくなると別の損失を生みます。
バックアップは「取った」だけで終わらせない
本番のファイルとデータベースを同じ時点で取得し、復元先と手順を確認します。WordPressのファイルにはテーマ、プラグイン、アップロード画像、wp-config.phpなどが含まれます。DBには投稿や設定、フォーム・注文データが含まれる場合があります。DBだけ、またはファイルだけのバックアップでは復旧できないことがあります。決済サイトでは作業前後に新規注文が入る可能性があるため、復元すると消える注文をどう照合するかも決めます。
復元テストでは、別環境に取り込んだあとサイトが起動し、管理者ログインと重要データを確認します。バックアップファイルを取得できたこと、復元に必要な認証情報が担当者に安全に渡ること、復旧に要する時間の見込みまで記録します。バックアップを公開ディレクトリへ置きっぱなしにせず、保管権限と期限を決めます。ロリポップ！の公式マニュアルは、本番変更前にステージングで表示・動作を確かめる案内も掲載しています。
プラグイン、テーマ、独自コードを棚卸しする
WordPress本体だけ更新しても、古いテーマや停止済みプラグイン、独自カスタマイズが新しいPHPに対応するとは限りません。管理者はプラグイン一覧で名称・版・更新日・提供元の対応PHP版を記録します。決済、フォーム、会員管理、キャッシュ、バックアップなど停止すると事業へ影響するものから優先して検証します。子テーマのfunctions.php、独自のショートコード、外部API連携も対象に含めます。
ステージングを作る場合、個人情報を含む本番DBを無制限にコピーしないでください。検証担当のアクセス権、検索エンジンに公開しない設定、通知メールや決済の送信先を整えます。テスト注文・テストフォームは本番顧客へ送られない状態にします。検証用サイトのPHPを本番で予定する系列に合わせ、WordPressと拡張の版も一致させます。見た目だけ似た環境では、PHPの互換性問題を見落とします。
| テスト箇所 | 期待する結果 | 失敗時の記録 |
|---|---|---|
| 公開トップ・代表記事 | 200応答、画像とメニューが表示 | URL、時刻、画面、ログ |
| 管理者ログイン・投稿保存 | ログインでき、編集内容が保存 | 操作と権限、再現条件 |
| フォーム・メール通知 | 受付記録と通知が一致 | 受付ID、受信時刻、匿名化したエラー |
| ファイルアップロード | 保存・表示・進捗UIが正常 | ファイル種別・容量、進捗機能の挙動 |
| 決済・予約 | テスト環境で結果が一件だけ確定 | 重複・欠落、決済ゲートウェイのテストログ |
今回のロリポップ！側の変更でsession.upload_progressが無効になっているため、独自の進捗バーがその設定に依存する場合は特に確認します。通常のメディアアップロードと独自の進捗バーは別の機能です。「画像を選んで保存できた」だけでは進捗UIの検品完了になりません。反対に進捗バーの不具合だけで、今回の脆弱性対策を戻すよう求めるべきでもありません。アプリ側で別実装を検討します。
PHP設定を変えるときの手順と不具合時の戻し方
変更するなら担当者、作業時刻、停止条件、復元条件を先に決めます。公式マニュアルでは、ロリポップ！ユーザー専用ページの「サーバーの管理・設定」→「PHP設定」で対象ドメインの版を選択し、「変更」をクリックします。反映まで5〜10分ほどかかります。利用できる版や実行形態はプラン・サーバーで異なり得るため、画面の選択肢と公式マニュアルをその時点で照合します。2026年5月にロリポップ！は全プランでPHP 8.5の提供を告知しましたが、自動で切り替わるわけではありません。
- 開始前にバックアップの時点と復元方法、重要機能の正常時の結果を記録します。運用責任者と検品担当が作業時間帯を共有します。
- 対象ドメインを確認し、変更先のPHPを選びます。操作は原則一件ずつ行い、別サイトを巻き込まないようにします。
- 5〜10分ほど反映を待ち、公開画面とサイトヘルスでWeb側PHPを確認します。キャッシュがある場合、未ログイン・ログイン済み双方の画面を比較します。
- ステージングで実施した操作を本番でも確認します。投稿保存、問い合わせ通知、画像アップロード、ログイン、必要なら決済・予約を安全なテスト手段で点検します。
- HTTP 500やエラー、データ欠落が出たら追加変更を止め、変更時刻とログを保存します。復旧方針を責任者が判断し、サポートや開発元へ必要情報を渡します。
重要なのは、版の巻き戻しを万能策としないことです。公式マニュアルには、PHP 7.1未満からアップグレードした場合、元の版に戻せないとあります。旧版への巻き戻しが可能な場合でも、将来の未修正リスクを残します。今回の二つのCVEに対してはロリポップ！が旧系列へ修正を適用済みですが、その状態を他社や自前環境へ一般化しないでください。障害時はまず互換性のあるプラグイン更新、独自コード修正、機能の一時停止、ステージングでの再検証を比較します。
データベース接続エラーはPHP2Shell攻撃とは限らない
ロリポップ！のPHP設定マニュアルは、変更後に「データベース接続確立エラー」が出る場合、DBパスワード形式が影響する可能性に触れています。これはサイト個別の互換性問題であり、脆弱性悪用の証拠とは限りません。ただし安易にDBパスワードを書き換えると、wp-config.phpと一致せず停止が長引きます。現在の設定とDBをバックアップし、公式手順を読み、担当者が復元できる状態で作業します。パスワードをメールやチャットへ平文で貼らず、適切な秘密管理方法を使います。
サポートへ伝える情報をまとめる
ロリポップ！公式マニュアルは、PHP変更に伴う問題の問い合わせに、対象サイト・プログラムURL、エラー内容、PHP変更日時、DBパスワード変更日時を添えるよう案内しています。これに利用中のドメイン、選択中のPHP系列、発生操作、再現時刻、匿名化したログ、直前の更新、重要機能への影響を足すと、切り分けが速くなります。エラーログ全文や顧客情報をそのまま送らず、サポートが指定する安全な経路を利用します。
公開後の監視とよくある質問
PHP設定の変更やロリポップ！側の保守が終わった後は、画面の見た目だけで完了にしません。最低でも変更直後、数時間後、翌営業日に、公開ページと管理画面、問い合わせ・購入・予約など自社の重要導線を確認します。5xx応答率、フォームの受付数と通知数、注文の保存件数、エラーログの増加量、アップロード失敗率を変更前の通常値と比較します。指標の閾値はサイトの通常規模に合わせて決めます。
異常があるときは、発生時刻と対象URLをサーバーの障害情報と照合します。キャッシュの古い表示、WordPressのプラグイン更新、ホスト側メンテナンスが重なることもあるため、一つの出来事へ全件を帰属させないでください。不審な管理者追加、未知のファイル、意図しないリダイレクトなどが見つかれば、単なる互換性トラブルではなくWordPress侵害時の初動へ進みます。証拠を消すような一括削除より、ログとファイルの保全を先に行います。
停止期間に届いた問い合わせ・注文を照合する
10月21日から22日のメンテナンスでは一部のサイト表示が停止しました。再開後に画面が見えるだけでは、停止中に試みられた問い合わせ、予約、購入が正しく処理されたか分かりません。フォームの管理画面に保存された受付、通知メール、外部CRMへの連携、顧客からの再送連絡を同じ時刻帯で照合します。決済では、注文が存在しないのにカード側だけ与信された、逆に注文だけ保存され決済が失敗した、といった不一致がないか、決済事業者の管理画面と照合します。個人情報を照合票へコピーせず、受付IDや注文IDなど必要最小限の識別子で突き合わせてください。
再送を依頼するときは先に既存の保存結果を確認します。「送信失敗に見えたから同じ注文をもう一度作成」とすると重複注文になることがあります。未達が見つかった場合は、利用者への案内、返金や予約枠の補正、社内担当の割り当て、完了確認まで一件ごとに記録します。ホスト側の停止の時刻と、個別サイトのプラグイン障害は一致するとは限らず、発生時刻と操作ログの根拠を残して判断してください。
旧PHPからの移行を30日で進める小さな工程表
今週は対象ドメイン、PHP系列、WordPress本体、テーマ・プラグインの版を一覧化し、更新が止まった拡張を洗い出します。次の週はファイルとDBのバックアップを取得して復元を試し、ステージングで予定版のPHPを検証します。三週目は失敗した機能の提供元へ問い合わせ、プラグイン更新または代替の判断をします。四週目に変更日を確定し、本番で一ドメインずつ切り替え、24時間の監視結果を残します。30日は例であり、決済や会員サイトは検証にもっと時間が必要です。責任者が事業停止の許容時間と受け入れ基準を決めてください。
各週の完了条件も具体的にします。一覧化は「全サイトの版が埋まり担当者が承認」、バックアップは「別環境へ復元しログイン可能」、ステージングは「重要導線の結果が現行サイトと一致」、本番は「問い合わせや注文の実データが失われず、5xxが通常水準」、監視終了は「翌日のログと利用者問い合わせに新しい異常がない」とします。停止条件に達したら変更を重ねず、検証した直前の構成へ戻すか、影響する機能だけを一時停止するかを選びます。
自社向け記録表に残す項目
一つの行に、サイト名、対象ドメイン、契約プラン、ロリポップ！のサーバー番号、PHP版・実行形態、更新前後のWordPress版、バックアップ時刻、検品担当、重要機能、変更予定日時、検品結果、残課題、次回確認日を記録します。パスワードやトークンは表へ入れません。複数社で管理しているなら、誰がホストの管理権限を持ち、誰がWordPressの更新権限を持ち、誰がユーザー影響を判断するかも明記します。責任分担が曖昧だと、警告を見つけても誰も更新を進められません。
取引先へ完了報告を出す際は「PHP2Shellの今回の修正適用をロリポップ！公式告知で確認」「サイトの重要機能を検品」「旧PHPの移行は別日程で実施予定」の三点を分けて書きます。今回の対策済みという事実を、すべてのWordPress脆弱性や侵害可能性がなくなったという表現へ拡張しないでください。サイト管理者が後日読んでも、何を確認し何が未完了か分かる記録を残します。
ロリポップ！が対策済みなら、PHPを更新しなくてよいですか？
今回の二つのCVEについては、同社提供PHPへ対策が適用済みと発表されています。しかし、PHP 8.1以下は開発元のサポートが終了し、将来の脆弱性に同じような修正が提供される保証はありません。PHPの更新計画は必要です。いま直ちに本番の版を変えて障害を起こすのではなく、プラグイン・テーマの互換性確認、バックアップ、ステージングのテストを済ませて移行します。
PHP 7.4と表示されるサイトは危険ですか？
版の表示だけでは今回の対策状況を判定できません。ロリポップ！はPHP 7.4に今回の修正コードを適用したと説明しています。ただし開発元のサポートは終了しているため、長期運用には適しません。今回のCVEへの適用済みか、将来の保守対象かを分けて評価します。別の事業者のPHP 7.4にも同じ修正があるとは限りません。
アップロード進捗が動かないのはサイト全体の障害ですか？
ロリポップ！がsession.upload_progressを全提供版で無効化したため、この設定へ依存する独自の進捗機能には影響し得ます。ただしファイル保存まで必ず失敗するとは限りません。試験ファイルでアップロード、保存後表示、進捗表示を分けて確認します。外部プラグインの問題なら提供元へ互換性を問い合わせ、安全性を下げずに別実装を検討します。
現時点で侵害がないと断言できますか？
できません。ロリポップ！は発表時点で脆弱性を狙ったとみられるアクセスを確認した一方、それに起因する不正アクセスや漏えいは確認していないと述べています。これは各契約者のサイトを個別調査した「全件無害の証明」ではありません。管理者アカウント、ファイル変更、アクセスログ、通知メール、外部リンクを、自サイトの状況に応じて確認します。
確認に用いた一次資料
- ロリポップ！：PHPの脆弱性への対応に伴うメンテナンス完了と経緯（2026年10月26日確認）
- ロリポップ！：PHP設定の公式マニュアル（同日確認）
- PHP公式：二件の重大な脆弱性に関する勧告（同日確認）
- PHP公式：セッションアップロード進捗の追加情報（同日確認）
- WordPress公式：推奨実行環境（同日確認）
提供状況や管理画面の文言は変更され得ます。自分の契約で見える設定と最新の公式情報を確認し、作業記録に確認日を残してください。公式告知が更新された場合は、先にその内容へ合わせて判断を改めます。
WithAIで更新後の運用知識を学ぶ
PHPの緊急対応では、公式情報と自分の環境の切り分け、バックアップ、検品記録を繰り返す力が大切です。WithAIでは、AIを業務で安全に使うための学習コンテンツを提供しています。サイトの保守担当者が、情報整理やチェックリスト作成の方法を学びたい場合はWithAIの無料案内をご覧ください。WithAIはロリポップ！の修正適用や事故対応を代行する窓口ではありません。緊急の技術的問題は契約先サポートと保守担当へ連絡してください。
