ConoHa WINGのPHP2Shell対策は必要？旧PHP表示でも修正済みか確認【2026年10月】

2026年10月26日

ConoHa WINGでWordPressを運用していて、「PHP2Shellの修正版は8.5.12なのに、サイトヘルスには8.5.11と表示される。自分のサイトは危険なのか」と不安になっていませんか。2026年10月26日に確認したConoHa WINGの公式終報では、提供中のすべてのPHPバージョンに今回の脆弱性向けセキュリティパッチを適用済みです。利用者が今回の修正を目的にPHPバージョンを変更する必要はないと明記されています。旧番号が表示される理由は、PHP系列を変えずに修正だけを取り込む「バックポート」です。

ただし、これはConoHa WINGの共有レンタルサーバーについての説明です。ConoHa VPSの契約者は、自分で管理するPHPの更新が必要になる場合があります。契約名を確認し、WINGとVPSの告知を混同しないでください。また、今回のパッチ適用と、WordPress・テーマ・プラグインの更新、古いPHP系列からの計画的な移行は別の仕事です。

この記事ではConoHa WING利用者向けに、公式終報の読み方、表示番号の解釈、コントロールパネルで確認する場所、動作確認、バックアップ、障害時の切り分け、サポートへ聞くべき内容をまとめます。脆弱性の全体像はPHP2ShellとWordPressの総合解説、複数事業者の違いはレンタルサーバー別の確認ガイドも参照してください。

ConoHa WINGのPHP2Shell対策は完了した？

ConoHa WINGの公式終報は、2026年10月22日20:45時点でサーバーへのセキュリティパッチ適用が完了したと発表しています。提供中のすべてのPHPバージョンについて、元のバージョンを維持したまま修正プログラムを取り込んだとも明記しています。したがって、今回のCVE-2026-109618とCVE-2026-109619の対応だけを目的に、WING利用者が急いでPHPを変更する必要はありません。

同じ終報は、WordPressのサイトヘルスで、PHPプロジェクトが公開した8.5.12などの番号ではなく、8.5.11など以前と同じ番号が表示される可能性を具体的に説明しています。公式に挙げられている適用後の表示番号には、8.2.34、8.3.35、8.4.26、8.5.11などが含まれます。番号だけをPHP公式の修正版と照合し「対策が終わっていない」と断じるのは誤りです。WINGでは、事業者が自分の提供するPHPに修正を取り込んだという告知を、番号表示と併せて読む必要があります。

PHP公式の修正版とホスト独自のバックポート

PHPプロジェクトの2026年10月21日の告知では、8.5.12、8.4.27、8.3.36、8.2.35が修正版です。これはPHP本家が配布する上流リリースを指します。一方、ConoHa WINGは同社のサーバー環境へ修正プログラムを取り込み、表示される系列番号を変えない方式を採りました。一般にこうした方式をバックポートと呼びます。事業者の適用状態を、上流のバージョン番号という一つの指標だけで判定できない例です。

バックポートは、今回の2件以外のすべての問題を永続的に解消したことを意味しません。古いPHP系列を使用している場合は、他の脆弱性、ライブラリ互換性、今後の保守終了も考慮して移行計画が必要です。PHP公式のサポート期間とWordPress・プラグインの対応表を見て、無停止に近い形で更新できる工程を作ります。「今回の緊急対応は完了」と「旧PHPからの移行は必要」を両立して考えてください。

ConoHa VPSにはWING終報を当てはめない

ConoHaはWING以外にVPSを提供しています。ConoHa VPSの注意喚起は、利用者に修正版PHPへのアップデートを求めています。VPSでは管理者がOSとPHPパッケージを運用する構成が一般的で、WING終報にある「利用者のPHP変更不要」はそのまま適用できません。契約名や管理画面上部のサービス区分が「WING」か「VPS」かを最初に確認します。複数サイトを別契約に分けている場合は、サイトごとに契約と担当者を紐付けてください。

対象	今回の確認先	避ける判断
ConoHa WINGで提供されるPHP	WING公式終報、契約サービス、対象ドメイン	旧表示番号だけで未修正と断定して緊急切替
ConoHa VPS上で管理者が入れたPHP	VPS告知、OS・PHPパッケージの適用情報	WINGの終報を自分のVPSにも適用
CDNや別ホストを経由する複合構成	実際にPHPを実行する各サーバーの管理者	公開URLの契約だけで実行環境を推測

WordPress公式の注意喚起も、今回の問題はWordPress固有ではなくPHP本体にあり、WordPress更新では修正されないと説明しています。WING利用者がWordPress管理画面で「更新がありません」と表示されても、PHP対策の証明にはなりません。事業者の公式通知を確認してください。

コントロールパネルとサイトヘルスの確認手順

確認の目的は、PHPを即座に切り替えることではなく、自分のWordPressサイトが公式終報の対象となるWINGのPHPを使っているかを特定することです。ConoHa WINGのPHP設定マニュアルは画面の場所を示しています。見た目や配置が更新された場合は、現在の公式マニュアルを優先してください。

「WING」→「サイト管理」→「サイト設定」→「応用設定」→「PHP設定」

ConoHaのコントロールパネルへログインし、上部メニューで「WING」を選びます。左メニューの「サイト管理」から「サイト設定」を開き、上部タブの「応用設定」内で「PHP設定」を選びます。そこに「PHPバージョン」が表示されます。複数ドメインや複数サーバーを管理している場合、対象サイトのドメイン・サーバーを選べているか確認してから、値を控えます。この段階では編集アイコンを押して変更を保存する必要はありません。

記録するのは、契約サービス名、対象ドメイン、表示中のPHP系列、確認日時、公式終報URLです。スクリーンショットを社内共有する場合は、アカウント識別子、別サイト名、個人情報を隠します。運用委託先が操作するなら、誰が確認し、誰が本番変更を承認できるのかも明確にします。

WordPress「ツール」→「サイトヘルス」→「情報」→「サーバー」

WordPressの管理画面に入れる場合は、WordPressのサイトヘルスでも動作中のPHPバージョンを表示できます。ここで例えば8.4.26と表示されても、ConoHa WINGの公式終報では同番号の環境に今回の修正が適用されたと説明しています。サイトヘルスは動作環境の情報を知る画面であって、事業者のバックポート有無を独立して証明する監査ツールではありません。

パネルのPHP番号とサイトヘルスの表示に差がある場合、対象ドメインの選択や、WordPressが別のホストにある可能性などを疑います。php -vの結果はCLIのPHPであり、Webリクエストを処理するPHPと異なる場合があります。値が一致しないからといって、深追いして本番設定を変更せず、対象URL、双方の値、確認時刻、契約情報を揃えてサポートまたは運用担当へ問い合わせます。

古い表示番号に慌てて「編集」→「保存」を押さない

ConoHaのマニュアルでは「PHPバージョン」の右側の鉛筆アイコンから候補を選び、保存して変更できます。便利な機能ですが、WordPressの既存テーマやプラグインにPHP新系列との互換性がない場合、管理画面やフォームが止まる可能性があります。ConoHaのWordPress FAQも、PHP切り替え後の表示障害についてプラグイン・テーマの対応状況を確認するよう案内しています。

今回のCVEに対してWING側の修正適用は完了とされています。したがって切り替えが必要なのは、旧PHPの長期保守上の移行、アプリの要件変更、あるいは個別契約についてサポートから追加対応を指示された場合などです。そのときも、変更理由、対象範囲、テスト結果、戻し方を記録してから実行します。安全のための操作が可用性の事故にならないようにする判断です。

修正適用後にサイトが正常か確認する

事業者のパッチが完了していても、WordPressの表示や業務機能の健全性はサイト運用者が確認できます。大きな構成変更をしないで点検できる項目から始めます。パッチ適用済み＝自サイトが一度も侵害されていないとも限りません。今回の告知は修正適用状況を示すもので、すべての顧客サイトを個別に調査したという意味には読めません。

5分で済む初期確認と、業務機能の確認を分ける

初期確認では、公開トップページ、代表的な記事、管理画面のログイン、ダッシュボードの表示、サイトヘルス、テーマ・プラグインの更新待ちを確認します。次に、サイト固有の重要機能を点検します。お問い合わせフォーム、資料請求、会員ログイン、予約、検索、決済、メール通知などです。実際の課金が生じる機能は、決済提供元の安全なテストモードや検証環境で行います。単にトップページが200を返すだけでは、注文やフォームまで正常とは分かりません。

担当者が複数いるなら、各機能の確認者と結果を表に残します。例えば「フォーム担当：入力→送信→受信を確認。10月26日11時、テスト用の架空情報を使用」と書きます。実際の顧客情報やメールアドレスを検証データへ流用しません。失敗があれば画面、時刻、再現操作、直前の変更を保存します。修正適用の告知と同時期に別のプラグイン更新が行われていた場合、因果を決めつけないためです。

変更履歴とログを残してから原因を分ける

ConoHa WINGのWebサイト設定FAQはPHPログの確認先として/home/logs/php_error_logを案内しています。ログやエラー文を見る際は、今回のパッチ適用による影響、PHP系列を手動で変更した影響、テーマ・プラグイン更新、サーバー高負荷、設定ファイル変更を区別します。PHPの警告が見えたから侵害と決めつけず、エラーが見えないから無害とも決めつけません。

ログには内部パスやリクエスト情報などを含む場合があります。公開Web領域にコピーしたり、外部チャットへ丸ごと貼ったりせず、アクセス権を限定して保存します。担当者が参照しにくい場合は、必要な時刻と対象ドメインを伝えてサポートへ確認します。ログの保存期間に依存するため、障害を見つけたら早めに必要部分を保全してください。

侵害の兆候があれば通常の更新確認から切り替える

見覚えのない管理者アカウント、記事改ざん、意図しないリダイレクト、公開ディレクトリの不審なPHPファイル、予期しない外部通信などがある場合は、単なる表示障害の処理では不十分です。作業前に時刻、ログ、ファイルの状態、ユーザー一覧を保全し、契約管理者・セキュリティ担当に連絡します。無計画にプラグインを再インストールすると調査に必要な証拠が失われることがあります。初動の順序はPHP2Shellを疑う場合の対応手順を参照してください。

見る対象	合格条件	異常時の次の行動
公開ページ	主要URLが想定どおり表示	時刻・URL・HTTPエラーを記録
WordPress管理画面	正規管理者がログインできる	Cookie・ログイン制限・更新履歴を確認
フォーム・通知	架空のテスト入力で送信・受信できる	PHPログとメール設定を切り分け
会員・注文等	テスト環境で重要フローが成立	本番課金を避け、担当者へエスカレーション
侵害兆候	不審な改ざんや追加ユーザーなし	証拠保全とインシデント対応に切り替え

PHP変更・障害に備えるバックアップと復旧

今回の脆弱性対策としてWINGで緊急PHP変更は不要です。それでも、長期的に新しいPHP系列へ移す際や、すでに自分で変更してサイトが壊れた場合には、復旧できる準備が必要です。PHPバージョンを戻す操作だけで、誤って消したファイルやデータベースの変更が元に戻るとは限りません。変更内容ごとに戻し方を分けます。

自動バックアップの日付と対象を先に見る

ConoHa WINGの自動バックアップ案内は、過去14日間分を取得し、コントロールパネルの「WING」→「サーバー管理」→「自動バックアップ」で一覧を確認できると説明します。「リストア可」となっている日付から「Web」「Mail」「DB」を項目別に復元できます。ただし、利用可能な日付と対象は実際の契約画面で確認してください。自動取得の存在だけをもって、求める日時の全データを復旧できると約束しないでください。

WordPressはWebファイルとDBが組になっています。プラグインファイルを昨日に戻し、DBだけ今日のままにすると設定の整合性が崩れる場合があります。ECサイトや会員サイトでは、DBを過去へ戻すとその後の注文・登録が失われる危険があります。復元前に対象範囲、失われる更新、業務側の記録との照合方法を決めます。可能なら別保管先にもファイル・DBを保存し、復元の試験を行います。

PHPを変更して壊れた場合の切り分け

ConoHa WINGのWordPress FAQは、PHP切り替え後にサイトが表示されなくなる要因として、プラグインやテーマの非対応を挙げています。変更直後にエラーが出たなら、元のPHP系列、変更日時、サイトと管理画面の症状を記録します。公式終報の対象であるWINGの元系列へ戻す場合、今回のCVEについて事業者パッチ済みとされている点を確認し、サービス復旧を優先します。その後、エラー原因を調べて互換性を改善します。

ただし、無差別に全プラグインを停止・削除したり、DBを丸ごと過去へ戻したりしません。複数の変更を同時にすると原因が分からなくなります。管理画面に入れない場合は、ConoHaの500エラーFAQに沿ってログを見ます。フォームだけ止まるならPHP更新後のフォーム・メール障害の切り分け、管理画面だけの問題ならログイン・セッション不具合の確認も参考になります。

障害・メンテナンス情報と自サイトの不具合を分ける

ConoHaは2026年10月22日の対応でメンテナンスや一部機能の停止・再開も案内しました。公式終報ではメンテナンス終了とファイルマネージャー、Webメール、phpMyAdminの再開が示されています。個別のエラーをすべて今回のPHP脆弱性のせいにするのではなく、現在のWINGニュース、発生時間、対象機能を照らします。メンテナンス時間外に一つのサイトだけ異常なら、サイト側の更新や設定変更を調べます。

万一パネルを開けないときは、非公式の「緊急ログイン先」やメール内の短縮URLを使わず、普段のブックマークまたは公式サイトから案内を辿ります。認証情報を急いで第三者へ送らないことも重要です。連絡時にはサービス名、サーバー・対象ドメイン、症状、時刻、直前に行った操作を整理します。ログ全量やパスワードは一般問い合わせへ貼らないでください。

ConoHa WING利用者の確認表とFAQ

最後に、自サイトの確認を短い表で残します。社内報告では「PHP2Shellは全部大丈夫」と一文で済ませず、「WING公式終報は今回の修正適用完了を公表」「当社サイトの動作確認は実施済み／未実施」「旧PHP系列からの移行は別途予定」と分けて記録してください。事実と未確認事項の境界が明確になります。

項目	記録例	未確認なら
契約区分	ConoHa WING／対象ドメイン	請求書とパネルで確認
適用情報	公式終報URLと確認日	最新告知を再確認
PHP表示	パネル値とサイトヘルス値	対象ドメインと実行環境を照合
業務機能	ログイン・フォーム・予約等のテスト結果	担当者と安全なテスト方法を設定
復旧	Web・DBバックアップ日、復元責任者	リストア可の範囲を確認
保守計画	旧PHPから移行する目標日	テーマ・プラグイン互換性を調査

FAQ：8.5.11と表示されます。8.5.12へ変えないと危険？

今回の2件については、ConoHa WINGの公式終報が8.5.11のような旧表示番号にも修正プログラムを取り込んだと明記しています。表示番号だけを理由にWING上で緊急変更する必要はないと同社は説明しています。ただし、これはWINGが提供するPHPと、この告知対象の脆弱性についての判断です。別契約のVPS、自分で導入したPHP、今後の別の脆弱性には自動的に当てはめないでください。

FAQ：PHP 7.xが残っています。ずっとそのままでよい？

いいえ。ConoHa WINGが今回の修正をバックポートした事実と、PHPプロジェクトによる旧系列の長期サポートは別です。テーマやプラグインの互換性を調査し、ステージングで新しい系列を検証してから、計画的に移行します。移行できない依存プラグインがある場合は代替・改修・廃止を検討し、管理者を決めて期限を置きます。PHPをすぐ上げられない場合の対応も参照してください。

FAQ：WordPressやセキュリティプラグインを更新すれば同じ効果？

同じではありません。WordPress公式は今回の問題がPHP本体にあり、WordPress更新は予定していないと案内しています。WAFやセキュリティプラグインは追加の防御に役立つ場合がありますが、PHP本体の修正適用を確認する代わりにはなりません。WINGでは事業者側の公式終報を根拠にし、WordPress本体・プラグインはそれぞれの保守目的で更新します。

FAQ：サポートへどのように問い合わせればよい？

「ConoHa WINGの契約で、対象ドメインは○○。コントロールパネルに表示されるPHP系列とWordPressサイトヘルスの値は○○。2026年10月22日のPHP脆弱性への対応完了告知を確認したが、この契約で今回のCVE-2026-109618・CVE-2026-109619について追加の利用者操作が必要か。表示番号が旧版のままでも適用済みの対象か」を、確認日時と共に尋ねます。回答後は受付番号、回答日、担当者、指示内容を保存します。質問のためにパスワード、APIキー、秘密鍵を送らないでください。

FAQ：画面に警告が出ません。侵害もなかったと判断できる？

判断できません。警告の有無はバックポートの適用状況や過去の侵害の証明にはなりません。公式終報は今回の修正を示しますが、個々のサイトが以前に侵害されていない保証ではありません。侵害の兆候があれば、ログ・変更履歴・不審なユーザーやファイルを確認し、必要に応じて専門家へ相談します。異常がなくても、バックアップと主要機能の動作確認を実施します。

本記事の情報確認日は2026年10月26日です。セキュリティ告知、サポート画面、提供PHP系列は変わり得ます。実際の操作前にはConoHa WINGの終報とPHP設定マニュアルを再確認してください。

実例1：サイトヘルスが8.4.26と表示される

以下は架空のケースです。ConoHa WING上の企業サイトでサイトヘルスにPHP 8.4.26と表示され、担当者がPHP公式の8.4.27と比較して不安になりました。まず契約サービスがWINGであることを確認し、WING終報の旧番号への修正適用という記述と照合します。今回の2件に関しては、旧番号だけを理由に緊急変更しません。パネルの対象ドメイン、確認日時、告知URL、表示番号を記録し、フォーム・管理画面・代表的なページが動くか確かめます。これで「PHP公式の番号とは違う」と「ConoHa WINGのパッチが未適用」は同じ意味ではないと社内へ説明できます。

実例2：ConoHa VPSも同じアカウントで契約している

架空の会社がWINGでブログ、VPSで独自アプリを運用しています。ConoHaアカウントへログインすると両サービスの管理入口があるため、担当者がWING終報を全サイトへ広げてしまいました。しかしVPSのPHPは運用者の管理対象であり、VPS向け注意喚起は利用者自身の更新を求めています。ドメインごとに「WINGかVPSか」「PHPのインストール主体」「更新担当」を整理します。VPS担当はOSベンダーのパッケージ情報と適用履歴、必要な再起動、Web経由で動くPHPを検証します。WING担当は事業者告知とサイトの機能確認を行います。一つのアカウント画面に並ぶからといって同じ運用責任にはなりません。

実例3：更新作業後、予約フォームだけ失敗する

架空の予約サイトで、管理者がPHPを手動で新しい系列へ切り替えた翌日、公開ページは表示される一方、予約完了画面だけ500エラーになりました。このとき、表示障害を「ConoHaのバックポート失敗」と即断しません。作業履歴から切り替え前後の系列を記録し、PHPログ、予約プラグインの対応情報、テーマや独自コードの更新内容を確認します。個人情報や実予約を使わず検証環境で再現し、業務に影響する場合は事前に決めた戻し手順で復旧します。予約データがDBに記録されたかも確認し、二重予約を防ぎます。復旧後に原因となる互換性を修正し、動作テストをしてから移行を再開します。

三例に共通するのは、契約の切り分け、事業者の告知、実際の画面表示、業務機能の結果を別の証拠として扱うことです。ひとつだけで結論を出すと、不要なPHP切り替えや、VPSの未更新を見逃す危険があります。結果は「公式の適用情報」「自サイトの機能テスト」「今後の旧PHP移行計画」の三行に分けて記録してください。

WithAIでAI活用を学ぶ

緊急時のAI検索は情報整理に役立ちますが、サーバー設定の根拠は公式告知で確認する必要があります。一次情報を探し、複数の案内を比較し、社内共有用の確認表を作る力を身につけたい方はWithAIの無料学習案内をご覧ください。WithAIはAI活用の学習案内であり、ConoHaのPHPパッチ適用、WordPressの緊急復旧、侵害調査を代行するサービスとして案内していません。実環境の判断は契約先の公式情報と運用担当者の確認を優先してください。