



WithCodeMedia-1-pc
WithCodeMedia-2-pc
WithCodeMedia-3-pc
WithCodeMedia-4-pc




WithCodeMedia-1-sp
WithCodeMedia-2-sp
WithCodeMedia-3-sp
WithCodeMedia-4-sp









「レンタルサーバーの管理画面にPHP 8.1と表示されています。PHP2Shellへの対策は済んでいますか」「WordPress側でPHPを切り替えるべきですか」。2026年10月のPHP緊急更新後、このような疑問を持つサイト運営者は少なくありません。結論は、表示されたバージョン番号だけで安全・危険を決めず、契約しているサーバー会社の公式告知と、自分のサイトに割り当てられた実行環境への修正適用を照合することです。告知だけでは対象プランやドメインが読み取れないときは、この記事の文面を使ってサポートへ問い合わせてください。
PHP公式は2026年10月21日、CVE-2026-109618とCVE-2026-109619を修正するPHP 8.2.35、8.3.36、8.4.27、8.5.12を公開しました。PHPを使うWebサーバーが対象で、WordPress本体の更新だけでは解決しません。一方、Linuxディストリビューションやホスティング事業者は、同じバージョン表記を維持したまま修正を取り込む「バックポート」を提供する場合があります。自分で切り替えられるプランと、事業者が一括管理するプランでも対応の主体が違います。PHP公式の緊急勧告、WordPress公式のお知らせ、JPCERT/CCの注意喚起を2026年10月26日に確認して制作しました。各社の対応状況は更新されるため、作業時に必ず最新告知を再確認してください。
この記事はレンタルサーバー利用者が「何を準備して」「何を質問し」「どの返答なら完了と判定するか」を決めるための実務用です。PHP2Shellの仕組みと基本対策はWordPress利用者向けの総合記事、各社の公開情報や設定場所はレンタルサーバー別の対応記事にまとめています。ここでは同じ説明を繰り返さず、問い合わせと回答の読み方に集中します。
2026年10月26日時点では、エックスサーバー、ConoHa WING、ロリポップ!、さくらのレンタルサーバは、対象サービスで修正を適用済みと公式に案内しています。まず告知の対象範囲と契約サービスを照合してください。VPS・独自導入PHPなど告知対象外の環境や、プラン・ドメインの適用状況が読み取れない場合に個別問い合わせをしてください。

サポートに「PHPの脆弱性は大丈夫ですか」とだけ送っても、契約の特定や対象環境の照合に往復が必要になります。まずは管理画面とWordPressから、対象を絞る材料を集めます。WordPressにログインできる場合は、「ツール」→「サイトヘルス」→「情報」→「サーバー」でWebから実行されるPHPのバージョンを確認できます。WordPress公式もこの経路を案内しています。サーバーの管理画面には、ドメイン別のPHP設定や契約プランが表示されることがあります。画面に「8.3」とだけ出るか「8.3.36」まで出るかはサービスによります。
このとき、コマンドラインで取得したPHPの版だけを採用しないでください。SSHで動くCLIと、ブラウザーからアクセスしたWordPressに割り当てられるPHPは別の設定になり得ます。サブドメインや別の公開ディレクトリごとに違う版を選べるサービスもあります。管理画面の「PHP設定」が契約全体の共通設定か、対象ドメイン個別の設定かを見分けます。たとえばConoHa WINGの公式設定ガイドはドメインごとの設定を説明し、ロリポップ!の公式マニュアルもドメイン別の確認場所を示しています。これらは設定方法の例であり、2026年10月の修正適用状況を示す資料ではありません。
管理画面が一時的に使えない場合も、サイトのURL、事業者名、サービス名、契約プラン、直近の請求書にある契約識別子を社内で確認します。問い合わせフォームに入力する契約番号は、事業者が指定する安全な窓口にだけ入力してください。公開コメント、SNS、共同編集のURLには載せません。サポートへの連絡であっても、パスワード、WordPressの管理者ログイン情報、秘密鍵、APIキー、データベース接続文字列は送らないでください。求められた場合は、その依頼が公式窓口から来たものか確認し、代替の安全な方法を相談します。
| 準備する情報 | どこで確認するか | 問い合わせでの使い方 |
|---|---|---|
| 対象サービス・プラン | 契約管理画面、請求明細 | 共用サーバー、マネージド、VPSなど責任範囲の特定に使う |
| 対象ドメインとサイトURL | 公開サイト、管理画面 | 複数サイトのうち対象環境を誤らないために使う |
| Web経由のPHP版と確認時刻 | WordPressサイトヘルス、サーバーパネル | 表示上の版と修正適用の照合に使う |
| 事業者の公式告知URLと最終更新日 | サポートサイト、障害・お知らせ欄 | サポート回答との食い違いを確かめる |
| 影響を受ける機能 | フォーム、購入、予約、ログインなどの運用台帳 | 切り替え・停止・検品の優先度を伝える |
例として、二つのWordPressサイトを同じアカウントで運用する会社を考えます。企業サイトはPHP 8.4、会員サイトはPHP 8.1と表示され、後者は申込フォームを毎日使っています。「アカウントのPHPは修正済みですか」では片方だけの回答で終わるおそれがあります。問い合わせ票にはドメインごとの表示版、機能、確認時刻を別行で記録します。社内の保守担当が対象一覧を作り、決裁者が公開停止を判断できる状態にしてから連絡すると、返信を待つ間も安全な運用判断ができます。
公開ページで確認できるバージョン情報を求めて、phpinfo()のページをインターネットに置くのは避けてください。設定値やパスなど多くの情報が公開されます。公式の管理画面やサイトヘルスを優先し、技術者が一時的な診断を行う場合もアクセス制限と削除期限を設けます。「版番号を確認するために別の情報漏えいを生む」という逆転を防ぎます。

問い合わせの主語は「PHPが最新版ですか」ではなく、「当該CVEの修正が、対象ドメインのWeb実行環境に適用済みか」です。バージョン番号だけを尋ねると、事業者独自のバックポートが回答から抜けます。逆に「WAFは入っていますか」だけでは、PHP本体の修正状況が分かりません。以下の文面は、必要な識別情報を自分の内容に置き換え、契約先の公式サポートフォームに貼り付けて使えます。角括弧の中は送信前に必ず編集してください。
件名:CVE-2026-109618/CVE-2026-109619の修正適用状況について(対象ドメイン:[ドメイン])
ご担当者さま
当社が利用する[サービス名・プラン名]の[対象ドメイン]について、2026年10月21日にPHP公式が公表した二つの脆弱性への対応を確認したく、ご連絡します。WordPressのサイトヘルス/貴社管理画面では、[確認時刻]時点でPHP[表示版]と表示されています。対象のサイトは[一般サイト/会員サイト/ECサイト等]です。1. このドメインのWebリクエストを処理するPHP実行環境には、CVE-2026-109618とCVE-2026-109619の両方の修正が適用済みでしょうか。適用済みであれば、適用完了日時と対象プラン・PHP系列を教えてください。
2. 表示版がPHP公式の修正版番号と異なる場合、貴社またはOS提供元によるバックポートで両CVEへ対応したものかを教えてください。確認できる公式告知・更新履歴のURLがあれば併せてお願いします。
3. 共用サーバー側のPHP更新は貴社側で自動実施されますか。それとも当社がドメイン別のPHP切り替えを行う必要がありますか。必要な場合は、推奨系列・操作場所・反映目安・切り戻しの可否を教えてください。
4. 未適用または適用中の場合、予定日時と、完了まで当社が取るべき対応を教えてください。WAF等の一時対策だけなのか、PHP本体の修正まで済んでいるのかも区別していただけると助かります。
5. 当社側の画面から修正適用を確認できない場合、どの公式告知またはサポート回答を記録すればよいでしょうか。契約の確認に必要な追加情報があれば、貴社指定の安全な方法でお知らせします。ご回答よろしくお願いします。
この文面には攻撃を再現する情報を含めていません。サポート側が対象を特定し、修正済みか、利用者が作業すべきか、まだ未完了かを回答できる設計です。事業者ごとに質問数や入力欄の上限が異なるため、短いフォームなら最初の二問を優先し、契約が必要とされる情報は追加返信で補います。正確な契約IDはサポートフォームに入れ、記事や社外共有資料に貼り付けた文面には残さないでください。
共用レンタルサーバーでは、事業者が基盤のPHPを更新・再起動し、利用者が系列を選ぶ方式があります。ここでは「自動適用なのか」「旧版の表示はバックポートなのか」「ドメインごとに利用者操作が必要なのか」を重点的に聞きます。マネージドWordPressやマネージドクラウドでは、プラットフォーム側がPHP環境を管理していることがあるため、管理対象の境界、テスト環境への反映、本番への予定を確認します。VPSや専用サーバーでは利用者自身がOSやPHPパッケージを管理する契約もあり、サポートが更新作業を代行しないことがあります。管理責任の範囲、利用OSのセキュリティ更新パッケージ、保守窓口を契約書と公式手順で照合してください。
「WordPressを最新にしたので安全ですか」という質問を加える必要はありません。WordPress公式は、今回の問題はPHP環境側であり、WordPress本体の更新は予定していないと説明しています。WordPress本体・プラグインの更新は別の重要な保守ですが、この二つのCVEへのPHP修正を代替しません。サーバー側へ聞くべきこととサイト側で行う互換性検証を分けるのが、回答を得る近道です。
「CVE-2026-109618と109619について、契約中の[プラン]で[ドメイン]のWeb実行PHPは両方修正済みですか。画面には[版]と出ています。バックポートなら、どの公式告知で確認できますか」と短く伝えます。電話を受けた担当者が即答できないなら、「調査後にチケットまたはメールで回答してください」と依頼します。口頭で聞いた「大丈夫です」だけでは、対象の取り違えや更新状況の変化を後から追えません。話した時刻、担当部署、受付番号、回答予定時刻を残してください。

サーバー会社の返答に「対策済み」と書かれていても、何を指すかを確認します。PHP本体への修正、事業者のバックポート、WAFルール、管理画面の一時停止は異なる対策です。PHP公式は今回の二つのCVEについて、更新が完全な解決であり、緩和策だけでは安全にならないと明記しています。WAFや一時制限は重要な時間稼ぎですが、それを「PHPへの修正適用済み」と記録しません。
| 受け取った返答の例 | 読み取り | 次の行動 |
|---|---|---|
| 「対象プランのPHP 8.4.27を[日時]に適用済み」 | 公式修正版番号と対象・日時が一致している | 対象ドメインの実行版を再確認し、重要機能を検品する |
| 「表示は8.1のままだが両CVEの修正をバックポート済み」 | 番号だけでは判断できないが、事業者の修正説明がある | 対象プラン、適用日時、両CVE、公式告知の対応範囲を照合して記録する |
| 「全サーバーでWAFを強化した」 | 攻撃経路の一部を抑える可能性はあるが本体修正とは別 | PHP修正の有無・予定を再質問し、暫定運用を判断する |
| 「順次対応中」 | 自分のサーバー・ドメインが完了したか不明 | 対象識別子と完了予定・確認方法を求める |
| 「PHP 8.5が選べます」 | 選択肢の存在だけでは現在の実行環境は不明 | 現在のドメイン設定と8.5の細かな修正版を確認する |
| 「サイトは正常表示されています」 | 正常表示はパッチ適用の証拠ではない | 両CVEの修正適用の質問に戻す |
バックポートとは、見かけのメジャー・マイナー版を据え置いて、脆弱性を修正する変更だけを取り込む方式です。PHP公式の2026年10月21日の勧告は、LinuxディストリビューションやLTS提供元が修正を取り込む場合があるため、提供元に更新パッケージを確認するよう案内しています。したがって「8.1と表示=未修正」と断定するのは危険です。ただし逆に「バックポートの可能性がある=修正済み」とみなすのも危険です。契約先が自分のサービス、対象PHP系列、対象CVE、適用時刻について確認した情報が必要です。
事業者によっては公開告知がプランごと、サーバー番号ごと、データセンターごとに分かれます。Aプランに「完了」と書かれた告知を、同じ会社のBプランへ一般化しないでください。会社名が同じでも、共用サーバー、VPS、クラウド、WordPress専用プランで責任分界やパッチ配布方法が異なることがあります。発表日時も「作業開始」「緩和策投入」「全台適用完了」を区別します。公式告知を保存するなら、記事URL、更新日時、該当範囲、参照した時刻を一緒に残します。
例えば「PHP 8.2.34を利用中。弊社独自の安全対策を実施済み」とだけ返った場合、修正適用を断定できません。両CVEに対応したバックポートなのか、WAFなどの暫定対策なのか、適用対象が自分の契約プランかを再質問します。逆に「PHP 8.2.35が選択可能」と書かれていても、自分のサイトが以前の8.2.34を実行したままなら、利用者の切り替えが必要かもしれません。どちらも文章の一部だけではなく、「現在動いている環境」と「適用内容」の二つを揃えてから完了にします。
サーバー側の修正が済めば、次はアプリケーションの動作確認です。運用担当は公開トップ、問い合わせフォーム、会員ログイン、検索、予約、決済などサイト固有の重要経路をテストします。エラーがないだけでなく、フォームの受付記録や通知メール、注文ステータス、認証後の権限まで確認します。PHP系列の切り替えを自分で行った場合は、テーマとプラグインの互換性問題が同時に表面化することがあります。必要ならPHP更新後のプラグイン互換性確認やHTTP 500・白画面の切り分けを参照してください。障害が出たとき、いきなり未修正版へ戻す前にホストへ相談します。
「対応完了日より前に不正アクセスがなかったか」は別の問いです。パッチ適用は将来の悪用を防ぐ対策であり、過去の侵害がなかったことの証明ではありません。JPCERT/CCは不審なログやプロセス、ファイル変更を確認し、痕跡がないだけで無侵害と断定しないよう注意しています。高リスクな個人情報サイトや、不審な管理者追加・ファイル変更があるサイトは、修正適用後も侵害有無の調査を検討してください。

回答が来ない間も、公開サイトのリスクは止まりません。問い合わせ送信時刻を記録し、事業上重要な機能を持つサイトから優先して社内の責任者へ共有します。「何時間待つべきか」という普遍的な答えはありません。取扱情報、外部公開範囲、サーバー会社の告知、障害発生の有無で判断します。受付メールに返信予定が書かれていればその時刻を管理し、予定を過ぎたら同じチケット番号で再連絡します。新しい問い合わせを乱立させると経緯が分散するため、緊急窓口へ移る場合も元の受付番号を示します。
未修正と確認された場合は、まず事業者が提示する修正版の適用手順、適用可能な日時、検品時間を確保します。共用サーバーで自分がPHPを切り替えられるなら、バックアップと復元手順を確認し、テスト環境でプラグイン・テーマ・業務機能を検証してから本番へ反映します。重要機能が止まる恐れがある場合も、脆弱な版のまま無期限に運用する理由にはなりません。機能を一時停止する、公開範囲を狭める、代替の修正版へ移る、サイトを一時的にオフラインにするなど、影響と安全性を比較して責任者が決めます。WordPress公式は、PHP 8.1以前で自分がホスト管理者なら、更新までサーバーをオフラインにすることも検討するよう呼びかけています。
PHP公式の緩和策を自社で勝手に一つだけ設定し、「対策完了」とするのは避けてください。今回の二つのCVEには複数の経路があり、設定変更は一部の経路を抑えるだけです。PHP公式も更新だけが完全な解決としています。共用サーバーの利用者には変更権限がない設定もあります。提供元に適用状況と正式な対応予定を確認し、サイト側でできる作業はバックアップ、不要な公開機能の見直し、ログ監視、重要経路の検品に限定します。WAFが入っていても、PHP本体の修正予定は問い続けてください。
問い合わせの再送例は「先ほどの受付番号[番号]について、対象ドメイン[ドメイン]のCVE-2026-109618/109619へのPHP本体修正適用状況を確認したく、再度ご連絡しました。公開機能は[会員ログイン/決済等]で、[時刻]時点で公式告知から当契約の完了を確認できていません。適用済み・作業中・未適用のどれに該当するか、対象範囲と次の確認時刻をお知らせください」です。決済障害や明らかな不審ファイルがある場合は、通常の情報照会ではなく「障害」「セキュリティインシデント」の窓口に切り替えます。
見覚えのない管理者アカウント、意図しない公開ページの改ざん、不審なファイルの増加、サーバーからの異常な外部通信、アクセスログとPHPエラーの不自然な集中があれば、単なる「パッチ待ち」の扱いから切り替えます。まず発見時刻、画面、ログ、ファイルの更新時刻を保全し、社内のセキュリティ担当や契約先へ緊急連絡します。復旧を急ぐあまり、初期化やプラグインの一括削除で痕跡を消さないようにします。サイトを停止するか、通信を制限するか、利用者へ知らせるかは、扱う情報と影響範囲を調べて責任者が判断します。詳細はWordPressのPHP2Shell侵害時の初動記事を参照してください。
「ログがきれいだから被害はない」と判断しないことも重要です。ログを保存していない、ローテーションで消えた、記録対象に該当リクエストが含まれない場合があります。JPCERT/CCも、攻撃の痕跡が確認されない場合でも悪用を受けていないとは断定できないとしています。ホストへログの保管期間と取得方法を尋ね、必要なら専門家の調査につなぎます。一方、単にPHP更新後にWarningが増えただけで侵害を断定もしません。症状、変更時刻、ログ、利用者影響を並べて切り分けます。

対応の完了条件は「問い合わせを送った」でも「返事があった」でもありません。対象ドメインのWeb実行環境について、両CVEへの修正適用が確認でき、担当者が重要機能の検品を終え、残課題と再確認日を記録した状態です。事業者の回答を担当者の個人メールだけに残すと、担当変更や次の脆弱性で同じ調査を繰り返します。社内でアクセス権を制限した保守台帳へ、出典付きで残します。契約IDや連絡先が含まれる場合は閲覧権限を限定してください。
| 記録項目 | 完了時に残す内容 | 確認者 |
|---|---|---|
| 対象 | 事業者、サービス、プラン、ドメイン、Web実行PHPの表示版 | サイト管理者 |
| 修正の根拠 | 二つのCVE、公式修正版またはバックポート、告知URL、対象範囲 | サーバー担当 |
| 適用と確認の時刻 | 事業者の適用完了時刻、自社での確認時刻、チケット番号 | 運用担当 |
| 重要機能の検品 | 画面表示、ログイン、フォーム、決済などの結果と担当者 | 業務担当 |
| 残課題 | 古いPHP系列からの移行、互換エラー、次の見直し期限 | 運用責任者 |
たとえば「8.1のままバックポート済み」と確認できても、PHP 8.1以前はPHPプロジェクトの通常サポート外です。今回のCVEがホストによって修正されていることと、将来にわたりサポートを受けられることは別です。契約先が旧系列をどこまで保守するかを確認し、WordPress本体・テーマ・プラグインの対応を見ながら、サポート中のPHP系列への移行日を決めます。PHP公式のサポート版一覧によれば、PHP 8.2のセキュリティサポートも2026年12月31日で終わる予定です。今回だけの対応で終わらせず、定期点検の予定へつなげます。
自分の契約サービス・プラン・PHP系列が明確に含まれ、対象CVEと適用完了日も示されていれば、まずその告知を記録し、サイトの実行環境と重要機能を確認します。告知に対象の制限がある、別プランの情報しかない、複数ドメインで設定が異なる、という場合は問い合わせた方が確実です。「全サーバー」という言葉だけを切り取らず、脚注や対象サービス一覧まで読んでください。公式告知が更新される可能性もあります。
一律には決めません。PHPプロジェクトでは8.1はサポート外ですが、契約先が今回の二つのCVEをバックポートしている可能性があります。まず修正適用を確認し、サポート中の系列への移行を早めに計画します。8.5への大きな版変更はサイトのプラグインやテーマに影響することがあるため、バックアップと検証が必要です。「安全確認」と「将来のバージョン移行」を同じ日の無計画な操作にしないでください。
WAFは一時的なリスク低減に役立つ場合がありますが、今回の脆弱性に対する完全な解決策ではありません。PHP公式は更新だけが完全な対策としています。WAFの有無を記録しつつ、PHP修正の適用予定と完了確認を続けます。どの暫定措置が自社サイトで使えるかは、事業者の公式案内とサーバー管理者の指示に従ってください。
まず契約書またはサービス仕様で責任範囲を確認します。VPSや専用サーバーなら、OSとPHPパッケージを自社で更新する契約かもしれません。サーバーの保守委託先が別にいる場合は、その担当へチケットと公式勧告を渡し、完了日時・適用パッケージ・再起動・Web実行環境の確認を依頼します。自社にサーバーを保守できる人がいないなら、事業者の有償サポートや外部の保守会社へ緊急相談するか、公開機能の一時停止を検討します。権限が不明なまま設定を変更しないでください。
この記事のテンプレートは、どの事業者にも同じ回答を強制するものではありません。契約プランとWeb実行環境を特定し、両CVEへの修正適用を裏付ける情報を得るための質問票です。脆弱性情報や各社告知は変わるため、送信前に日付とリンクを再確認し、回答後は運用台帳へ残してください。

サーバー会社からの回答を理解するには、PHP、WordPress、Webサーバー、バックポートなどの基本を区別できることが役立ちます。WithAIでは、AIを使った情報整理や技術の学習を進められます。AIの出力を公式資料と照合し、自分のサイトに合う質問や検品項目を組み立てる力を身につけたい方は、WithAIの無料案内を確認してください。WithAIはホストのパッチ適用や緊急のインシデント対応を代行する窓口ではありません。緊急時は契約先と専門の保守担当へ連絡してください。
公式サイト より
今すぐ
無料カウンセリング
を予約!