PHP2Shellはレンタルサーバーでどう対応する？4社の確認・更新手順【2026年10月】

2026年10月21日、PHP本体に未認証の遠隔コード実行につながる重大な脆弱性が2件公表されました。WordPressをレンタルサーバーで運用している人が最初にすべきことは、WordPressの「更新」ボタンを押すことではありません。契約先の公式告知を確認し、自サイトが実際に使うPHP系列と事業者側の修正適用状況を照合することです。そのうえで必要な場合のみ、バックアップを取り、対応済みのPHPへ切り替え、公開画面と管理画面を検証します。

本記事はエックスサーバー、ConoHa WING、ロリポップ！、さくらのレンタルサーバを使うWordPressサイトを対象に、管理画面のどこを見るか、切り替える前に何を残すか、表示が壊れたときどこまで戻すかを具体的にまとめました。確認日は2026年10月22日です。脆弱性対応と管理画面の表示は刻々と変わります。操作直前に各社の公式告知も再確認してください。

なお、この記事で「PHP2Shell」と呼ぶのは今回のCVE-2026-109618／CVE-2026-109619です。WordPressコアの別の問題や、過去の同じような通称の案件と混同しないため、問い合わせや社内報告では必ずCVE番号も添えてください。

PHP2Shellでレンタルサーバー利用者が最初に判断すること

結論から言うと、レンタルサーバーでは「PHPの表示バージョンだけで安全・危険を断定しない」ことが重要です。PHP公式は修正済みバージョンを8.5.12、8.4.27、8.3.36、8.2.35としています。一方、レンタルサーバー事業者は利用者が選ぶバージョン表記を変えずに修正を適用する場合があります。古い小数点以下が見えても直ちに未修正とは限らず、逆に「8.4」という系列名だけを見ても修正済みとは言えません。PHP公式の2026年10月21日セキュリティ勧告と契約先の告知をセットで読みます。

PHP公式が説明する問題は、メモリー不足時の処理に関わるCVE-2026-109618と、前のリクエストの内部状態が残るCVE-2026-109619です。Web経由のリクエストを処理するPHP環境が対象で、特定のWordPressプラグインを使う人だけの問題ではありません。WordPress.orgの注意喚起も「WordPressに固有の脆弱性ではない」「この問題のためのWordPress本体更新は予定していない」と明記しています。WordPressやプラグインの通常更新は引き続き必要ですが、それだけで今回のPHP脆弱性への対応を終えたことにはなりません。

3分で行う一次判定

1. 契約サービスを特定します。同じ会社でも「エックスサーバー」「XServer for WordPress」「VPS」では管理画面と事業者が受け持つ範囲が異なります。請求画面や契約メールのサービス名を確かめ、WordPressが動くサーバーと一致させます。
2. WordPressの実行PHPを見ます。管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」に進み、PHPバージョンを記録します。複数ドメインやステージングがあるなら、それぞれ別に確認します。コントロールパネルの選択値とサイトヘルスの表示が異なる場合は、ドメイン別設定や反映待ちを疑います。
3. 事業者の公式告知を見ます。今回のCVE番号、対象サービス、対象サーバー、PHP系列、適用日時を探します。事業者が「対応済み」と言っていても、別サービスや一部サーバーのみなら自サイトに適用されたとは言えません。
4. 判断を記録します。「契約サービス／対象ドメイン／PHP表示値／事業者告知URL／確認日時／担当者／次の確認時刻」を1行にまとめます。単に「PHP8.4なのでOK」と記録するのは不十分です。

表示がPHP 8.1以前でも、事業者が修正をバックポートしている可能性はあります。ただしPHPプロジェクト自身は8.1以前をサポートしていません。今回だけ修正されていても、長期運用の安全性とは別の話です。事業者の対応範囲を確認したうえで、WordPress、テーマ、プラグインを検証し、サポート中のPHP系列へ移行する計画を立ててください。

「今すぐ切り替える」「確認して待つ」「サイトを止める」の境界

確認結果	取る行動	避ける判断
事業者が自サービス・自サーバーの対象PHPを修正済みと明示	告知と確認時刻を保存し、WordPressの表示・ログを点検します。長期的なPHP移行は別工程で進めます。	告知を読まずに「PHP 8.1だから未対策」と決めつけ、急いで切り替えること。
対象であるが対応状況が不明、あるいは段階適用中	事業者に対象サーバーの適用状況と予定を問い合わせます。作業可能な修正版が提示されていれば、バックアップ後に切り替えます。	WAFがあるから完全に安全、という判断。
未修正と明示され、更新もできない	事業者の緊急案内に従い、必要なら公開停止やアクセス制限を検討します。復旧できる別環境への移行も検討します。	本番で手探りの設定を重ね、復旧手段を失うこと。
侵害を疑う痕跡がある	作業記録とログを保全し、別端末から資格情報を保護し、事業者・専門家へ連絡します。単純な「最新版にしたから終了」としません。	証拠を消す全面リストアや、感染した可能性のあるバックアップの無検証復元。

PHP公式は緩和設定も示していますが、更新だけが完全な解決策としています。共用レンタルサーバーでPHP-FPMやApacheの設定を勝手に変えられないことも多く、個別サイトの .user.ini に設定を足せば済むという話ではありません。たとえば公式が挙げるsession.upload_progress.enabled=0も、リクエスト解析前に適用し、ワーカー再起動が必要な条件があります。安易なコピー＆ペーストはせず、事業者が管理する領域は事業者へ確認してください。

修正バージョンと「系列表示」を混同しないための読み方

PHPのバージョンは通常「8.4.27」のように、主・副・パッチの数字で表します。今回PHPプロジェクトが配布した修正は8.2、8.3、8.4、8.5の各系列に別々にあります。例えば「8.4.26」はPHP公式が今回の修正済みとして示す「8.4.27」より前の版です。ただし、これはPHP公式の配布物をそのまま使う環境の見方です。ホスティング事業者が8.4.26相当の表記のまま修正コードを入れている可能性があるため、利用者が見た数字だけで事業者の適用を否定することもできません。反対に「PHP 8.4」としか表示されない画面ではパッチ番号が不明です。契約先の発表を確認する必要があります。

「PHP 8.5へ上げればよい」と決め打ちするのも避けます。8.5にはPHP 8.5.12という今回の修正版がありますが、サイトのテーマやプラグインが8.5で動くかは別問題です。事業者が8.3や8.4に修正を適用済みなら、現行系列の安全な修正版を維持する方が、互換性の影響を小さくできる場合があります。いま必要なのは最も大きい数字への競争ではなく、修正済みで運用可能な構成を確認することです。

自分でOSとPHPを管理するVPSの場合は、レンタルサーバーのサーバーパネルだけを見ても不十分です。OSベンダーが修正をバックポートすることがあり、パッケージのリリース番号やセキュリティアドバイザリを管理者が照合します。本記事の4社別手順は主に共用レンタルサーバー向けです。VPS利用者は「同じ会社だから自動で対策済み」と考えず、サーバー保守担当へ管理責任を確認してください。

架空ケース：同じ「PHP 8.3」表示でも判断が分かれる

ケースAは、対象契約の公式告知に「PHP 8.3系へ今回の修正を適用済み」とあり、サーバーIDも対象に含まれています。この場合、管理画面の表示が「8.3.x」だけでも、告知の適用範囲と日時を保存し、サイトが正常か点検する判断になります。すぐ別系列へ切り替える必要があるとは限りません。

ケースBは、同じ「8.3.x」と表示されていますが、告知は「順次適用」だけで対象サーバーの完了日時が示されていません。この場合、ケースAと同じ結論にはできません。サーバーIDとドメインを添えて事業者に問い合わせ、回答までの公開継続リスクを業務責任者と判断します。ケースCは、事業者が未適用と明示する一方で修正済みの8.3系を選択できる状態です。この場合はバックアップと互換性確認をして切り替える候補になります。3ケースともWordPressサイトヘルスの表示は同じでも、次の行動は異なります。

切り替え前に必ず行う共通準備とバックアップ

PHPの切り替えは、WordPressの投稿本文を書き換える操作ではありません。それでも、PHPの互換性が合わないテーマやプラグインがあると、表示不能、管理画面のエラー、購入・問い合わせの失敗につながります。急いでいても「元の値を記録する」「戻す方法を確保する」「重要導線を決める」の3点は省かないでください。

作業台帳を先に作る

表計算でもメモでも構いません。1サイトにつき、対象ドメイン、ホスト名・サーバーID、プラン名、WordPressのサイトURL、現在のPHP、切替候補、作業者、開始予定時刻、復旧担当、事業者の告知URLを記録します。サーバーの管理画面に複数サイトが並ぶ場合、誤って別ドメインのPHPを切り替える事故を防ぐため、対象サイトのURLを音読してから保存する運用も有効です。公開サイトと検証サイトが同じドメイン設定を共有する場合もあるため、設定範囲を事前に確かめます。

特にEC、会員登録、予約、採用応募など「失敗しても画面は表示される」導線を洗い出します。トップページだけの表示確認では、決済コールバックやメール送信が壊れたことに気づけません。テスト用の注文・問い合わせを許可する運用なら、関係者に事前連絡したうえで試験番号を付けます。実顧客へ誤メールを送らないよう、テストデータの扱いも決めてください。

バックアップは「あるはず」ではなく復元可能性を確認する

最低でもWebファイルとデータベースの両方を対象にします。WordPressのテーマ・プラグイン・アップロード済み画像はファイル側、投稿や設定は主にデータベース側です。片方だけでは完全に戻せないことがあります。サーバー提供の自動バックアップは便利ですが、保持期間、対象、取得時刻、リストア方式、作業後の投稿差分を確認してください。必要なら手動のバックアップも別の安全な場所に保管します。バックアップ自体に個人情報が含まれる可能性があるため、公開URLで置かないでください。

前日のバックアップから復旧する場合、前日から障害発生までの新規注文・会員登録・記事更新は戻らない可能性があります。ECサイトなら、復元よりもPHPバージョンを元に戻し、互換性のないプラグインを修正する方がデータ損失を抑えられることがあります。逆に侵害が疑われる場合は元のPHPへ戻すことが安全とは限りません。「表示不具合」と「侵害疑い」を分けて判断します。

切替直後に見る画面を先に決める

• 公開トップと、アクセスの多い記事・固定ページ。
• WordPress管理画面、編集画面、メディアのアップロード。
• 検索、問い合わせフォーム、送信後メール。
• ログイン・ログアウト、会員ページ、注文・予約など事業上の主要操作。
• サーバーのエラーログ、WordPressのサイトヘルス、監視・問い合わせ件数。

テスト対象は「そのサイトで実際に使っている機能」に置き換えてください。存在しない決済を検証する必要はありません。一方、フォームのあるサイトでフォーム送信を省くのは危険です。重要導線ごとに「操作した」「期待した結果が出た」「メールや管理側にも届いた」を確認し、時刻と担当者を残します。

切替の完了条件を曖昧にしない

作業完了は「保存ボタンを押したとき」ではありません。対象ドメインの選択値が変わり、WordPressのサイトヘルスにも新しい値が反映され、公開・管理・主要業務機能が正常に動き、エラーログの新規異常がない状態です。事業者のパッチ適用方式によっては表示バージョンが変わらないため、その場合は公式告知と対象サーバー照合を完了条件にします。作業後1時間と翌営業日にも再点検する担当を決めておくと、遅れて起きるバッチや通知の問題を拾えます。

PHPが変わるとOPcacheやキャッシュで古い表示が一時的に見える場合があります。ただし「キャッシュだから大丈夫」と推測して終了しないでください。シークレットウィンドウや別端末で確認し、管理画面の設定・サイトヘルスと照合します。反映時間は事業者によって違い、ロリポップ！の公式ヘルプは5～10分ほどと案内しています。すぐに連打して設定を往復させると状況が分かりにくくなります。

公開前後でデータが変わるサイトの保全計画

ニュースサイトのように編集者が常時投稿する、あるいはECサイトで注文が続く場合、バックアップを取った直後からデータに差分が生じます。作業責任者は「最終バックアップ時刻」と「変更開始時刻」を別に記録してください。作業時間に投稿を止められるなら、編集担当へ開始と終了を通知します。注文や問い合わせを止められないサイトでは、万一のDB復元で失われるデータをどう抽出・再登録するかを事前に決めます。

例えば10時にDBバックアップを取得し、10時30分にPHPを切り替え、11時にフォームエラーが分かったとします。この間にフォーム送信が1件あったか、送信は成功したがメールだけ失敗したかで復旧方法が変わります。単に10時のDBへ戻す前に、11時時点のDBとメール送信記録も保全します。注文がある場合は決済側の取引記録と照合し、二重処理や消失を避けます。表示だけの問題ならPHP設定の切り戻しやコード修正で復旧でき、データの全面復元を避けられることもあります。

逆に、侵害を疑う痕跡がある場合、同じサーバー上へ新しいバックアップを上書きして保存するだけでは証拠や安全な復旧元を確保できません。サーバー事業者が利用者に許可する方法でログとファイルを保全し、第三者に公開しない場所へ置きます。どのバックアップが侵害前か分からないなら、慌てて最古のものへ戻すのではなく、時系列を作って専門家の判断を仰ぎます。

作業を止める条件も決めておく

事前確認でバックアップが取れない、復元方法が分からない、PHPの修正状況が確認できない、重要プラグインの互換性情報がない、作業後のテスト担当が不在といった場合は、運任せの切替を避けます。ただし「準備不足だから何もしない」で放置するのも危険です。事業者の公式指示を確認し、サイト停止や閲覧制限などの選択肢を検討しながら、欠けている情報を埋めます。緊急の公開停止が必要かどうかはサイトの性質と事業影響で変わるため、運用責任者と合意します。

作業を開始した後も、予定した反映時間を超えて実行値が変わらない、主要な導線が失敗する、エラーログが急増する、第三者の操作と競合するといった場合は、次の変更を重ねる前に停止します。「一つ変更して一つ検証する」という順序を守ると、どの操作が不具合を起こしたか追跡しやすくなります。復旧するために何を元へ戻すか分からない状態で操作を続けないでください。

エックスサーバーでPHPの対応状況を確認する方法

まず契約名を見ます。一般的な「エックスサーバー」のサーバーパネルと「XServer for WordPress」のWPパネルは別です。検索で見つかった手順が自分の画面と違う場合、無理に同じボタンを探さずサービス名を確認してください。VPSや専用サーバーでは、OSパッケージの更新・Webサーバー再起動など利用者側の責任範囲が変わります。本節は共用のエックスサーバーとXServer for WordPressを対象にします。

一般的なエックスサーバー：サーバーパネルを開く

1. XServerアカウントから対象契約のサーバーパネルに進みます。複数契約がある場合はサーバーIDを作業台帳と照合します。
2. 「PHP Ver.切り替え」を開き、対象ドメインを選びます。管理画面に表示される現在の系列・選択候補を控えます。
3. 公式のPHP切替マニュアルと、今回の障害・メンテナンス・セキュリティ告知を別タブで照合します。メニューが一時的に開けない場合は、サーバー側メンテナンスや機能制限の有無を告知で確認します。
4. 事業者の告知が「対象サーバーにパッチ適用済み」と明示している場合は、表示バージョンだけを理由に慌てて系列を変えません。未適用で修正版の選択が案内されている場合は、事前バックアップ後に対象ドメインを変更します。
5. 保存後はWordPress「サイトヘルス」のPHP情報、公開ページ、フォーム、ログを確認します。ドメインごとに設定が違う場合は、サブドメインや検証環境も漏らさず確認します。

2026年10月22日時点で、この記事の制作環境からエックスサーバーの指定された当日告知ページを直接取得できませんでした。そのため、すべての契約環境でパッチ適用が完了したとは本記事では断定しません。契約者はエックスサーバーの告知とサーバーパネル内のお知らせを、実際のサーバーIDに合わせて確認してください。アクセスできない場合はサポートに「CVE-2026-109618／109619のパッチ適用済みか、対象サーバーID」を質問します。

XServer for WordPress：WPパネルは別の導線

XServer for WordPressの公式マニュアルでは、WPパネルで「サイト」を開き、対象サイトの設定画面の「サイト情報」から「サーバー情報」内の「PHPバージョン」に進む流れが案内されています。一般的なエックスサーバーの「PHP Ver.切り替え」と混同しないでください。専用サービスのPHP設定マニュアルを開き、自分のWPパネルの表示に合わせて操作します。

対象サイトを選ぶときは、公開URLだけでなくステージングや複製サイトの名称にも注意します。保存前に現在値をスクリーンショットまたは台帳へ残し、変更後に同じ場所へ戻って選択値を確認します。WordPress本体側のサイトヘルスと一致しなければ、反映待ち・キャッシュ・サイト取り違えを点検します。PHPの設定とセキュリティパッチ適用は同義ではないため、専用サービス側の当日告知も確認します。

切替メニューが停止中・表示されないとき

PHP切替機能が一時停止している場合、ボタンがないことだけで未対策とも対策済みとも判断できません。サーバー側で適用作業をしている可能性もあります。次の文面をサポート窓口に送ると、調査に必要な情報を整理できます。

件名：CVE-2026-109618／CVE-2026-109619の当契約への適用状況確認
契約サービス：［エックスサーバー／XServer for WordPress］
サーバーID：［管理画面で確認したID］
対象ドメイン：［URL］
現在のPHP表示：［例：8.3.x］
確認日時：［年月日・時刻・JST］
質問：このサーバーで今回2件への修正は適用済みでしょうか。未適用なら予定時刻と、その間に利用者が取るべき公式の措置を教えてください。切替メニューが停止している場合は再開予定も教えてください。

ログイン情報やパスワードを問い合わせ文に書く必要はありません。障害画面の画像を添付するときも、URLの管理トークン、顧客情報、注文番号などが写っていないか確認します。回答を受けたら、担当者と時刻、回答の適用範囲を記録します。

ConoHa WINGでPHP設定・バックアップ・復元を確認する方法

ConoHa WINGではPHPのバージョン設定とバックアップの確認場所が異なります。先に「自動バックアップ」で復元候補を確認し、その後「サイト管理」のPHP設定へ進む順番が安全です。ConoHa WING公式のPHP設定ガイドは操作方法を説明していますが、このガイドだけで今回のCVE対応完了を意味しません。2026年10月22日時点で、当記事が確認できた公式資料からは今回の2件に対する全サーバーの修正完了を断定できません。利用中のサーバーのセキュリティ告知またはサポート回答を別に確認してください。

先に復元可能なバックアップを確認する

1. ConoHaコントロールパネルへログインし、上部の「WING」を選びます。複数サーバーを契約している場合は対象サイトが存在するサーバーへ切り替えます。
2. 「サーバー管理」→「自動バックアップ」を開きます。公式ガイドは過去14日間分の自動バックアップを案内しています。ただし、対象日時と「リストア可」の表示を実際の管理画面で確認してください。
3. 「Web」「Mail」「DB」の各項目を見ます。PHP変更だけの不具合なら必ずしも全面復元は要りませんが、失敗時に何が戻せるか把握します。
4. 最後の正常動作を確認した日時を台帳へ書きます。前日夜に更新した記事や注文があるなら、その時点より古いバックアップへ戻す影響を見積もります。

自動バックアップの公式ガイドは「復元できる日時と対象を確認する」用途です。単にバックアップ一覧が見えた段階で安心せず、WebとDBの両方が対象か、復元後の扱いはどうなるかを読みます。自前のバックアップがあるなら、取得日時と保存場所を別記します。復元操作は本番データを変える可能性があるため、この段階では実行しません。

PHPバージョンの画面へ進む

1. コントロールパネル上部で「WING」を選択します。
2. 左の「サイト管理」→「サイト設定」→「応用設定」→「PHP設定」と進みます。
3. 「PHPバージョン」に出ている現在値を記録します。ドメインごとの設定が有効か、サーバー共通設定を継承しているかも確認します。
4. 変更が必要だと判断した場合だけ、右側の編集アイコンを押し、プルダウンから事業者が推奨する選択肢を選び「保存」します。表示の系列名がPHP公式の修正版番号と同一であるとは限らないため、事業者側パッチの有無を別途確認します。
5. 保存後に対象ドメインの公開ページとWordPressサイトヘルスを見ます。複数ドメインがある場合、設定が共通か個別かを確認して、影響範囲内のサイトをすべて検証します。

ConoHaの公式ガイドによると、ドメイン別のPHPバージョン設定はサーバー共通設定より優先されます。ドメインごとに変更した際、.htaccessに「AddHandler」から始まる記述が追加されることがあります。これを「不要な行」とみなして手動削除すると設定に不整合が生じるおそれがあると公式ガイドは注意しています。PHP切替の前後で、.htaccessを独自に編集する必要はありません。別の作業者が同じファイルを触っていないかも確認します。

表示が壊れたときの戻し方

まずPHP設定画面で「変更前の選択値」に戻し、公開画面と管理画面を再検証します。これはPHP互換性による表示不具合への一次復旧であり、今回の脆弱性への安全策ではありません。事業者が変更前の系列は未修正と明示しているなら、公開をそのまま続けず、サイト停止・アクセス制限・代替環境などを検討します。フォームだけ失敗する、特定プラグインだけ異常などの場合は、PHPエラーログとプラグインの互換性情報を確認します。

ファイルやデータベースの破損も疑う場合に、ConoHaのリストア手順を参照します。「WING」→「サーバー管理」→「自動バックアップ」で、対象日時とWeb・Mail・DBを選ぶ流れです。ただし、同社の説明ではリストア後に指定日時のデータが設置され、必要なデータを取り出して復旧する形です。「ボタンを押せば現在のサイトが自動で完全復旧する」と思い込まないでください。WebとMailの復元ファイルには24時間の保持期限があり、再度リストアすると以前の復元ファイルは削除されます。1週間に5回以上のリストアで制限がかかる可能性も案内されています。作業前に復元先、取り出すファイル、既存データの扱いを確認します。

もし切替後に注文・問い合わせが入っているなら、古いDBへの全面復元はデータ損失を起こします。まず現在のDBもバックアップし、復元対象を限定できるか制作会社や事業者へ相談してください。脆弱性悪用の疑いがある場合は証拠保全を優先し、感染時期より後のバックアップを「正常」と決めつけないようにします。

ConoHa WINGへの問い合わせ文例

件名：PHPのCVE-2026-109618／109619への対応状況について
契約：ConoHa WING、対象サーバー［管理画面の識別情報］、対象ドメイン［URL］
PHP設定画面の表示：［系列・設定値］
確認した公式告知：［URLまたは未発見］
質問：当サーバーで上記2件への修正またはバックポートは適用済みでしょうか。未適用の場合、推奨する切替先・適用予定・利用者が行うべき措置を教えてください。ドメイン別設定と共通設定のどちらが実行値かも確認したいです。

「PHP 8.4が選択可能ですか」だけでは、今回の修正が入っているか回答しづらくなります。CVE番号とサーバー識別情報を添え、「適用済みか」を直接尋ねます。ただし、パスワードや認証トークンは送らないでください。

ロリポップ！でPHPバージョンを確認・変更する方法

ロリポップ！の公式ヘルプは「ユーザー専用ページ」→「サーバーの管理・設定」→「PHP設定」でバージョンを変更すると案内しています。設定の反映には5～10分ほどかかるとされています。この手順はPHPの選択方法であって、今回のCVE修正をどのサーバーへ適用したかを示す告知ではありません。修正状況は別途、ロリポップ！のお知らせまたはサポートで確認してください。

設定前：対象ドメインと運用形態を確認する

まずユーザー専用ページへログインし、サーバー契約とドメインを確認します。複数のWordPressを一つの契約に置いている場合、どのドメインの設定が変わるのかを事前に把握してください。プランやサーバー仕様で選べるPHP系列が異なる可能性があるため、インターネット上の他人のスクリーンショットより、現在の自分の管理画面に表示される選択肢を優先します。WordPressサイトヘルスの実行PHPと照合し、現在値を記録します。

切替作業前に、WebファイルとDBのバックアップ取得日時を確認します。ロリポップ！のバックアップ機能の有無や範囲は契約プラン・オプションで異なる場合があります。「ロリポップなら自動バックアップが必ずある」と決めつけず、自分の契約画面とバックアップの公式案内を確認してください。自前のバックアップを取る場合も、サイトのファイルとDBを対にして保管します。

ユーザー専用ページでの操作順

1. ロリポップ！のユーザー専用ページにログインします。ブックマークや公式サイトから進み、不審なメール内リンクからログインしないようにします。
2. 「サーバーの管理・設定」メニューから「PHP設定」を開きます。対象ドメインの行と現在のPHP表示を確認します。
3. 事業者告知で修正済みの系列または推奨する切替先を確認できた場合、バックアップと作業台帳を整えてから変更します。修正の有無を確認できない場合は、系列名だけで安全を推測せずサポートへ問い合わせます。
4. 設定変更を保存し、反映の目安である5～10分を待ってから対象サイトのサイトヘルスを再確認します。反映途中に何度も切り替えを往復させないようにします。
5. 公開ページ、管理画面、フォーム、その他主要機能を確認し、エラーログやサーバー側障害情報も見ます。終了時に新しい表示値と確認時刻を台帳へ記録します。

「保存したのにWordPressでは旧バージョン」となる場合は、対象ドメインを間違えていないか、反映時間が過ぎたか、別のサーバーやキャッシュを見ていないかを確認します。公式の反映目安を超えても変わらない場合は、設定画面・サイトヘルス・確認時刻のスクリーンショットを用意してサポートへ連絡します。phpinfo()の公開ファイルを本番に放置して情報漏えいを招くより、管理画面の情報を先に使う方が安全です。

変更後に500エラーや白画面になった場合

まず変更時刻を確認し、障害がPHP切替直後に始まったかを切り分けます。管理画面が開けるなら、PHP設定を元の値へ戻すと互換性による表示不具合が収まることがあります。ただし元の値が今回の問題に未対応なら、それは一時的な表示復旧であり、安全な最終状態ではありません。公開継続の可否を事業者に確認してください。WordPress管理画面だけ開けない場合でも、レンタルサーバー側のユーザー専用ページからPHP設定に入れるか確かめます。

PHPを戻しても直らなければ、プラグイン・テーマの更新、キャッシュ、サーバー障害など別要因を疑います。ログにあるファイル名・時刻・エラー分類を確認し、機密情報を隠したうえで制作会社や開発者へ渡します。原因が特定できないままプラグインを全停止・全削除したり、古いバックアップでDB全体を巻き戻したりすると、復旧までの原因追跡が難しくなります。

ロリポップ！への問い合わせ文例

件名：PHP重大脆弱性2件への当契約の対応確認
対象CVE：CVE-2026-109618、CVE-2026-109619
契約プラン・サーバー識別情報：［管理画面で確認］
対象ドメイン／現在のPHP設定：［URL、表示値］
質問：今回の修正は当サーバー・当PHP設定に適用済みでしょうか。未適用の場合は、利用者が選択すべきバージョンと適用予定を教えてください。PHP設定が反映しない場合の調査方法も教えてください。

回答で「WAFルールを追加した」と案内されても、それとPHP本体の修正適用は別です。WAFは攻撃の一部を減らす可能性がありますが、PHP公式は更新以外を完全な解決とはしていません。事業者の今後のパッチ計画まで確認してください。

さくらのレンタルサーバでは緊急切替が必要か

さくらインターネットは2026年10月22日の公式告知で、コントロールパネルから選択できるすべてのPHPバージョンについて今回の脆弱性への対応を完了し、利用者に緊急の対応はないと説明しています。したがって、さくらのレンタルサーバで対象環境にいる人は、この2件への対応だけを目的に慌ててPHP系列を切り替える必要はありません。ただし、公式告知の対象サービスと自分の契約名が一致するかは確認してください。VPSや自主管理サーバーを同じ扱いにしないでください。

ここでいう「緊急切替不要」は「古いPHPをずっと使ってよい」という意味ではありません。さくらもサポート期間中の最新版PHPへの移行を勧めています。選択可能な旧PHPに今回の修正が入ったことと、今後の新たな脆弱性やテーマ・プラグインの互換性に対応できることは別です。今回の緊急対応と、中期的なバージョン移行を別の作業として管理します。

まず公式告知と契約サービスを照合する

1. 契約画面で「さくらのレンタルサーバ」「マネージドサーバ」などのサービス名を確認します。VPS、クラウド、専用サーバーは運用責任が違うため、共用レンタルサーバー向け告知だけで判断しません。
2. 上記告知の公開日と対象範囲を確認し、CVE-2026-109618／109619の両方が対象であることを見ます。
3. WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」で現在のPHPを記録します。今回のパッチ適用後もバージョン表示がPHP公式の修正版番号と一致しない可能性があります。事業者の対応済み告知と合わせて判断します。
4. 公開画面と管理画面に不審な変更やエラーがないか確認します。告知は今回の脆弱性対策を示すもので、過去の侵害やWordPress側の別の問題まで「ない」と証明するものではありません。

さくらの告知には、phpMyAdminとウェブメールの一部については対応を進めている旨も記載されています。WordPressを表示するPHPと、周辺管理ツールの対応状況を混同しないでください。業務でそれらを使う場合、別途メンテナンス・障害情報を確認します。もし管理画面で一部機能が使えないなら、PHP切替で直そうとする前に事業者のメンテナンス案内を見ます。

今後のPHP移行を行う場合の画面操作

サポート期間中のPHPへ移行する計画を立てる場合は、WordPress・テーマ・プラグインの互換性を先に確認し、バックアップと検証時間を用意します。さくら公式のPHP変更手順は、サーバーコントロールパネルへログインし、「スクリプト設定」から「言語バージョン設定」を開き、PHPのバージョンを選んで保存する流れです。

ログイン方式にも注意点があります。さくらのマニュアルでは、メールアドレスとパスワードでログインした場合にメール設定しか表示されないことがあり、ドメイン設定項目を見るには初期ドメインまたは追加ドメインとパスワードでログインするよう案内しています。言語バージョン設定が見当たらないとき、誤った管理画面にいる可能性を確認します。

保存後は選択値、WordPressサイトヘルス、主要導線を確認します。さくらのマニュアルは、PHP変更により古いアプリが動かなくなる可能性、問題が起きたときは古いバージョンを選び直せることを説明しています。ただし、戻すこととセキュリティ上の最終対策は区別します。今回についてはさくらが選択可能な全バージョンを修正済みと公表しているため、単なる互換性検証として元へ戻す選択肢があります。将来の別の脆弱性では同じ判断にならない可能性があります。

企業サイトでの実務的な報告例

社内に「さくらのサーバーを使っているが、何もしなくて大丈夫か」と質問されたら、次のように範囲を明示して答えます。

当社サイトは［対象のさくらレンタルサーバー契約名］で稼働しています。2026年10月22日のさくら公式告知では、コントロールパネルから選択可能なPHP全バージョンに今回のCVE-2026-109618／109619への対応が完了し、利用者の緊急作業は不要とされています。対象ドメイン［URL］の表示と管理画面を［確認日時］に確認し、現時点で異常は見つかっていません。旧PHPからサポート中系列への移行は別途、互換性検証とバックアップを行って計画します。

この報告は「侵害がない」と断言する文章ではありません。ログやファイルを調査していないなら「確認した範囲で異常なし」と記します。事業者の告知更新があれば内容を追記します。

切替後の検証・不具合の復旧・よくある質問

4社に共通するゴールは「バージョンを変更した」という事実ではなく、今回の修正が適用された状態で、サイトの必要な機能が動き続けることです。事業者がパッチを配った場合、利用者が管理画面で何も変更しなくても脆弱性対応は進むことがあります。一方、PHPを別系列へ切り替えた場合は動作の検証が必要です。次の表を作業チェックリストとして使ってください。

確認対象	実際に行う操作	正常と判定する条件	異常時の最初の行動
事業者の適用状況	告知またはサポート回答を対象契約・サーバーIDと照合	対象PHP・適用日時が特定できる	適用範囲をCVE番号付きで再質問
WordPressのPHP情報	ツール→サイトヘルス→情報→サーバー	設定値と実行値が整合する	反映待ち、対象ドメイン、個別設定を確認
公開ページ	トップ・人気記事・固定ページを別端末で閲覧	HTTPエラーや白画面、崩れがない	エラーログと変更時刻を照合
管理画面	ログイン、記事編集、メディア表示を試す	画面が開き保存が成功する	テーマ・プラグイン互換性を点検
売上・問い合わせ導線	テスト送信・注文・予約を実施	完了画面、通知メール、管理側記録が一致	一時停止の要否を業務責任者と判断
監視・ログ	作業前後の時刻でログを比較	新しい致命的エラーや異常アクセスがない	ログを保全し事業者・専門家へ相談

「画面が壊れた」と「侵害を疑う」を分ける

PHP切替の直後に500エラー、白画面、特定プラグインのエラーが出た場合は互換性の問題が第一候補です。対象ドメイン・変更時刻・選択前後の値を確認し、事業者の案内に従って安全性を損なわない範囲で元の値に戻せるか判断します。すぐに戻せない場合は一時的なメンテナンス表示を検討します。テーマ・プラグインの開発元にPHP対応状況を確認し、検証環境で修正してから再切替します。

一方、覚えのない管理者アカウント、改ざんページ、外部サイトへの転送、不審なPHPファイル、予期しない大量送信などがあるなら、互換性不具合だけでは説明できません。アクセスログとエラーログ、問題のファイル、最初に気づいた時刻を保存し、感染の疑いを事業者へ伝えます。証拠を消す前に専門家へ相談し、別の安全な端末から管理者・SFTP・データベース等の認証情報を見直します。ログの保存期間は事業者によって違うため、早めに保全します。

よくある質問：WordPress本体を更新すれば今回の脆弱性は直りますか？

直りません。今回の2件はPHPの問題で、WordPress.orgはWordPress本体の更新をこの問題の修正方法としていません。WordPress本体やプラグインに別の未修正問題があれば、それらの更新は別途必要です。作業を一度に重ねると不具合の原因を特定しにくいため、PHPの適用確認・WordPressの通常更新・プラグインの互換性修正を作業記録で分けてください。

よくある質問：PHPの管理画面に「8.4」とあるだけで安全ですか？

言えません。PHP公式の修正済み8.4系列は8.4.27です。管理画面が系列だけ表示する事業者、バックポートで修正を適用する事業者などがあるため、実際の適用状況は事業者の告知またはサポート回答で確認します。「8.4.x」の一文字列だけを安全判定の証拠にはしません。

よくある質問：PHP 8.1や7.4を使っているサイトは必ず侵害されていますか？

「古い」ことと「侵害された」ことは違います。古いPHPを使っているだけで侵害を断定できません。またPHP本家のサポート外でも、ホスティング事業者が今回の修正をバックポートする場合があります。ただし長期的な更新計画は必要です。現在の事業者対応を確認し、ログとサイトの異常を点検し、サポート中系列へ安全に移行する工程を作ってください。

よくある質問：WAFを有効にしたらPHP更新をしなくてよいですか？

いいえ。WAFは攻撃の一部を遮断する可能性がありますが、PHP公式は緩和策を完全な代替とはしていません。事業者が緊急のWAFルールを適用した場合でも、PHP修正の適用状況と予定を確認してください。WAFの誤検知でログインやフォームが止まることもあるため、設定を変えた場合は主要導線もテストします。

よくある質問：PHP切替ボタンが使えないときは何をすればよいですか？

メンテナンス・障害情報を確認し、対象サービスとサーバーIDを示してサポートへ連絡します。「画面がないから未対応」「画面がないから自動で対応済み」のどちらも推測です。事業者の回答までに公開を続けるリスクが高いと判断した場合は、業務責任者と相談して公開停止やアクセス制限を検討します。自主管理サーバーであれば、OS・PHPパッケージの更新状況を管理者へ確認します。

よくある質問：PHPを戻すと安全ですか？

戻すことは互換性不具合の復旧策であり、安全性を保証しません。戻し先の系列にも修正が入っているか事業者告知で確認します。さくらのように選択可能な全系列へ対応済みと公表するケースと、修正対象が限定されるケースでは判断が違います。戻し先が未修正なら、公開を停止して互換性修正を進めるなど別の対応が必要です。

よくある質問：フォームだけ動かないときはどこから調べますか？

フォームの画面表示、入力後の確認画面、送信処理、管理側への保存、通知メールを別々に試します。どの段階で失敗したかを特定すると、PHPの実行エラー、メール設定、外部サービス接続、入力制限のどれを調べるべきか絞れます。送信ボタンを連打して実顧客の通知を増やさず、テストデータには明確な識別子を付けてください。サーバーのエラーログとフォームプラグインのログがあれば、同じ時刻で照合します。フォームが業務上不可欠なら、復旧まで代替連絡先をサイト上に案内するか、公開停止を責任者と決めます。

よくある質問：複数ドメインが同じサーバーにあるときは一括で確認できますか？

契約や管理画面によって設定の適用単位が違います。事業者がサーバー全体へパッチを配る場合でも、利用者が選ぶPHP系列はドメインごとに異なることがあります。代表サイトが正常でも、別ドメインの旧テーマが新しいPHPで失敗する可能性があります。まず管理画面の設定範囲を確認し、ドメインごとに実行PHPと主要機能を台帳へ記録します。ConoHa WINGはドメイン別設定がサーバー共通設定より優先されるため、共通設定だけを見て判断しないでください。

よくある質問：PHP更新と同時にプラグインも全部更新すべきですか？

脆弱性があるプラグインの更新は別途必要ですが、原因を追いやすくするため、可能なら操作を分けて記録します。緊急にPHPの修正適用が必要な場面で、検証なしのテーマ・プラグイン一括更新を重ねると、どの変更で画面が壊れたか分かりにくくなります。まず事業者側の修正状況を確認し、必要なPHP切替をバックアップとテスト付きで行い、その後ほかの更新を優先度順に進めます。複数の重大問題が同時にある場合は、公開停止も含めた全体のリスクを担当者で判断します。

よくある質問：バックアップがあるなら感染の疑いがあってもすぐ復元できますか？

すぐの全面復元は避けてください。感染後のバックアップなら問題を戻すだけで、感染前のバックアップならその後の注文や投稿を失う可能性があります。先にログ・不審ファイル・管理者一覧・異常発生時刻を保全し、専門家と復元ポイントを決めます。復元後も侵入口と認証情報を修正しなければ再発します。

問い合わせの回答待ち中に担当者が変わる場合

状況を口頭だけで引き継がず、1ページの記録を残します。「何が分かったか」「まだ分からないか」「公開中か停止中か」「公式告知のURLと確認時刻」「サポートチケット番号」「次に確認する日時」「操作してよい人」「操作してはいけない設定」を書きます。相談先が複数ある場合、サーバー側パッチの質問はホスティング事業者、テーマやプラグインの互換性は開発元、侵害調査はセキュリティ担当というように役割を分けます。

今回のような時事的なセキュリティ情報は、公開日の記載だけでは足りません。運用者は公式告知の更新日時を確認し、事業者ごとの情報が変われば作業台帳とこの記事の判断も更新してください。本文にある「対応済み」は2026年10月22日に確認した範囲です。各社の最新情報は、PHP公式、WordPress.org、エックスサーバー、ConoHa WING、ロリポップ！、さくらの一次情報で確認できます。

30分で行う小規模サイトの初動例

これは架空の運用例です。対象は企業の情報サイト1件、WordPressの問い合わせフォーム1件、更新担当1人とします。最初の5分で契約サービスを特定し、サイトヘルスに出ているPHP、事業者告知、サイトの表示を記録します。次の10分でサーバーの管理画面に入り、対象ドメインとバックアップの取得日時を確認します。ここで事業者が修正済みと明示していれば、無理な切替はせず、フォームの送信試験とログの確認へ進みます。

修正状況が不明なら、次の5分でサーバーID・PHP表示値・CVE番号を添えて問い合わせます。残り10分で、必要なら一時的な問い合わせフォームの停止案内やサイト全体の公開停止を検討する責任者に状況を共有します。30分で「必ず修正完了」にするという意味ではありません。期限内に何が判明し、何が未確認かを明確にして、次の判断を可能にするのが目標です。

複数サイトを管理する制作会社の台帳例

制作会社が10サイトを預かっているなら、1サイトずつ記憶に頼って対応すると見落としが起きます。クライアント名、契約事業者、サービス名、サーバーID、対象ドメイン、WordPressの実行PHP、事業者告知の適用範囲、バックアップ日時、テスト担当、公開影響、ステータスを行ごとにまとめます。「告知確認待ち」「バックアップ済み」「切替中」「検証中」「完了」「保留・要連絡」など、次にすべき作業が分かる状態を使います。

例えば3サイトはさくらの対象レンタルサーバー、4サイトはConoHa WING、2サイトはエックスサーバー、1サイトはロリポップ！とします。さくらの3サイトは公式告知の対象サービス一致を確認して緊急切替をせず、稼働確認と中期のPHP移行計画へ進みます。ConoHaとロリポップ！の5サイトは、今回の対応完了が各契約で確認できない限り「完了」にしません。エックスサーバーの2サイトは通常版とfor WordPressを分け、別々のパネル・告知を確認します。同じ制作会社の案件でも、事業者やサービスごとに結論が変わることが分かります。

顧客へは「全サイトを更新しました」という曖昧な報告ではなく、サイトごとに「事業者側の修正確認済み」「利用者がPHPを切替済み」「機能検証済み」「事業者回答待ち」の別を記します。回答待ちの案件には再確認時刻を入れます。修正済みの確認と侵害調査の完了も別項目です。ログを調査していなければ「侵害なし」とは書きません。

証跡として保存するもの、保存しないもの

作業証跡には公式告知のURLと確認日時、管理画面に表示されたPHPの系列、設定変更前後のスクリーンショット、主要ページのテスト結果、サポート問い合わせ番号を残します。後から「あの時点ではどの告知を根拠にしたか」を説明できる形が理想です。ただしスクリーンショットやログには管理画面URL、クッキー、トークン、顧客のメールアドレスが含まれることがあります。共有する前に伏せ、保管先のアクセス権を絞ります。パスワードや秘密鍵を作業台帳に記載しないでください。

HTTPエラーのログを保存する場合は、発生時刻、対象URLのパス、エラーの種類、変更操作との前後関係を整理します。サポートに送るときは問題を再現する最短の操作を添えます。「サイトが動きません」だけでは担当者が調査しづらいため、「10月22日15時に対象ドメインのPHP設定を変更し、15時10分に問い合わせフォームで500が発生。トップは200。PHPを元へ戻すとフォームは正常」というように区別します。実際に確認していない結果は推測として書かず、未確認とします。

次回に備える保守ルール

今回の緊急対応を終えた後は、PHPを含むランタイムのサポート期限、WordPress本体とプラグインの更新担当、公式告知を受け取るメール、毎日のバックアップと復元試験の担当を決めます。レンタルサーバーが自動でパッチを適用する範囲と、利用者がバージョンを選び直す必要がある範囲を契約ごとに整理します。毎回の脆弱性発表後に初めて管理画面のログイン先を探す状態なら、技術的な更新以前に運用の改善余地があります。

最低限、四半期ごとに1回、ステージング環境でPHPの次の系列を試し、重要なフォームと業務導線を検証しておくと、緊急時に互換性問題で立ち止まりにくくなります。これは今回のCVEに対する即時の修正ではなく、次の更新を安全に進めるための準備です。バックアップの「取得」だけでなく、復元にかかる時間と手順も演習しておくと、実際の障害時に戻し方を判断できます。

今回の点検を終えたら、次回のセキュリティリリースに備え、契約サービス・管理者・更新担当・バックアップ・復旧手順を1枚にまとめておくと安心です。自社で管理できるWordPress本体・テーマ・プラグインと、事業者が管理するPHP実行環境の境界を明らかにしてください。問い合わせのたびに契約情報を探す状態をなくすことが、緊急時の対応時間を短くします。

関連する確認・対応記事

• PHP2Shellの概要とWordPress運営者が先に行う対策：脆弱性と初動の全体像を確認できます。
• 自サイトのPHP版と修正適用状況を見分ける方法：対象かどうかの判断を深掘りできます。
• WordPressのPHPを安全に更新する手順：互換性検証と切り戻しを詳しく確認できます。

AIスキルで、未来の自分をアップデート！

今なら完全無料でAIを学べる！

今回のPHP対策は、レンタルサーバーの公式情報を確認して進めてください。WithAIは脆弱性の緊急対応窓口ではなく、AIスキルを学ぶための案内です。日々の情報整理や仕事でのAI活用を学びたい人は、WithAIの無料学習案内を確認してください。AI副業、AI転職、AI活用の目的に合わせて学ぶコースが用意されています。