PHPの重大な脆弱性（CVE-2026-109618、CVE-2026-109619）が公表され、サーバー会社の告知や自社サイトのPHPバージョンを見直す必要が生じています。一方で、「8.3に上げれば対応は完了なのか」「契約中のレンタルサーバーはどの単位でバージョンを設定できるのか」「複数のサイトを1台に載せていて影響が読めない」といった点が課題になっています。本記事では、完了の基準になる修正版の番号、PHPバージョン設定の粒度、当社の更新記録、主要各社の公式情報、サーバー選定のチェックリストを解説します。
- PHPの脆弱性対応で完了の基準になる修正版の番号
- レンタルサーバーのPHPバージョン設定の3つの粒度と、当社の構成での制約
- 当社がPHPバージョンを更新した5ステップの記録
- 複数サイトの同居のメリットとリスク、主要各社の公式情報
- 選定のチェックリスト7項目と、構成別の判断の起点
PHPの脆弱性対応は、修正版の番号に到達して完了する
完了の基準は、PHPのバージョンを上げたことではなく、開発元が公開した修正版の番号に到達したことです。たとえば8.3系なら、「8.3に上げた」では足りず、「8.3.36という修正版に到達した」ことが条件になります。
php.netの「PHP: News Archive – 2026」（2026年10月21日掲載、2026年10月23日閲覧）によると、開発元は2026年10月21日に、認証なしでリモートからコードを実行され得る2件の重大な脆弱性の修正版を公開しました。評価はいずれもCVSS v4.0で9.2です。JPCERT/CCの「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日更新、2026年10月23日閲覧）と、JVNの「JVNVU#99905564: PHPにおける複数の任意のコードが実行可能な脆弱性（CVE-2026-109618、CVE-2026-109619）」（2026年10月23日更新、2026年10月23日閲覧）も、同じ2件を取り上げています。
| 使用中の系統 | 修正版の番号 |
|---|---|
| PHP 8.5系 | 8.5.12 |
| PHP 8.4系 | 8.4.27 |
| PHP 8.3系 | 8.3.36 |
| PHP 8.2系 | 8.2.35 |
JPCERT/CCによると、影響を受けるのは、これらの番号より前のバージョンです。なお8.2系は、php.netの告知で2026年12月31日にサポートが終了するとされています。脆弱性対応の完了は、系統の新しさではなく、修正版の番号で判断することをおすすめします。
当社は、2026年10月23日に本番サイトのPHPを8.1から8.3.36へ切り替えました。8.3.36は、2026年10月21日に公開された修正版そのものです。
8.1以前の扱い
8.1以前には、開発元の通常リリースとしての修正版はありません。php.netの告知は、8.1以前が開発元の更新を受けないことを示したうえで、7.4、8.0、8.1向けに最小限のバックポート（修正内容を古い版へ移植したもの）を公開したと記載しています。ディストリビューションやLTSベンダー（長期サポートを提供する事業者）、レンタルサーバー各社が、独自に適用している場合もあります。
レンタルサーバーの利用者が、自分でバックポートを適用する場面は通常ありません。8.1以前を使っている場合の行動は、契約中のサーバー会社の告知で対応状況を確認することです。
レンタルサーバーのPHPバージョン設定は3つの粒度に分かれる
公式ページで確認できた範囲では、ドメイン単位、WordPress単位、アカウント単位の3パターンです。粒度とは、PHPバージョンの設定が及ぶ範囲を指し、切り替え時の影響範囲を左右します。
| 粒度 | 設定が及ぶ範囲 | 切り替え時の影響範囲 | 契約前に確認すること |
|---|---|---|---|
| ドメイン単位 | ドメインごとにバージョンを選ぶ | 選んだドメインのサイト | 本番とステージングが別ドメインか |
| WordPress単位 | インストール済みのWordPressごとに選ぶ | 選んだWordPressのサイト | 契約内のWordPressの数と用途 |
| アカウント単位 | アカウント全体で1つのバージョンを選ぶ | アカウント内のすべてのサイト | 全サイトを同時に検証できるか |
粒度が細かいほど、特定のサイトだけを先に切り替えて検証しやすくなります。設定の粒度は、更新時の影響範囲そのものと考えておくと、選定の判断がしやすくなります。同じ会社でも、プランや契約時期で粒度が異なる場合があります。
本番とステージングが同一ドメイン配下にあった当社の場合
当社の構成では、同一ドメイン配下のステージングだけを先に切り替えることができませんでした。ステージング環境は、本番と同じドメインのサブドメインにあります。当社の本番サイトはエックスサーバーで運用しており、同社の公式マニュアルはドメイン単位の設定手順を説明しています。
この制約は、当社の構成で起きた事実の記録です。サーバー一般の仕様を述べるものではありません。ステージングを別ドメインに置けば別々に設定できるかは、契約先への確認が必要です。
当社では、この制約を踏まえて検証の順序を組み替えました。PHPバージョンに依存しない作業を先にステージングで行い、バージョンの切り替えは本番で行う順序です。ステージングの置き場所は、PHPの更新を検証できるかどうかに直結するため、選定の時点で考慮しておくと手順を組み替える手間を減らせます。環境の置き方は、要件の段階で決める項目です。全体像はWebサイト制作の要件定義｜発注前に決めておく7項目とRFPへのまとめ方にまとめています。
当社がPHPバージョンを更新したときの記録
当社は、静的解析、ステージングでの先行作業、本番での切り替え、デバッグログでの確認、設定の復元の5ステップで進めました。以下は当社の構成での実施記録であり、この手順どおりにすれば安全という意味ではありません。
| ステップ | 実施内容 | 結果 |
|---|---|---|
| 1. 静的解析 | PHPの非互換コードを、実行前に静的解析で洗い出した | 切り替え前に確認する箇所を把握した |
| 2. ステージングでの先行作業 | PHPバージョンに依存しない作業（プラグイン更新と問い合わせフォームの送信テスト）を、先にステージングで実施した | 切り替え前に、これらの作業を終えた |
| 3. 本番での切り替え | 2026年10月23日に、本番サイトのPHPを8.1から8.3.36へ切り替えた | 8.3.36は2026年10月21日公開の修正版 |
| 4. デバッグログでの確認 | WP_DEBUG_LOGを有効にして、サイト表示、管理画面、問い合わせフォームの送受信を確認した | いずれも正常。debug.logは一度も生成されず、エラーはゼロ |
| 5. 設定の復元 | 確認後、同日中にデバッグ設定を元に戻した | 作業完了 |
ステップ4では、デバッグログ（WordPressがPHPのエラーを書き出すファイル）の生成の有無を、確認の目安にしました。保守作業全体の分担や契約の見方は、サイト公開後の保守運用とは｜何を誰がやるかの切り分け方と契約範囲の見方で整理しています。
複数事業のサイトを1台のレンタルサーバーに同居させるメリットとリスク
メリットはコストと管理画面の一元化、リスクは更新時の影響範囲が全サイトに及ぶことです。以下は一般的な整理です。
| 観点 | メリット | リスク |
|---|---|---|
| コスト | 契約が1つにまとまり、費用の管理が単純になる | プランの上限に近づくと、全サイトが影響を受ける |
| 管理画面 | 運用担当の負担が小さい | 操作ミスが複数サイトに波及し得る |
| 更新作業 | PHPなどの更新を1回で済ませられる | 更新の影響範囲が全サイトに及ぶ |
| 障害時 | 対応窓口が1つで分かりやすい | 障害で全サイトが同時に止まる |
| 検証 | 検証環境を共有できる場合がある | 全サイトで動作を確認するため工数が増える |
| 負荷 | サイト間でリソースを融通できる場合がある | 1サイトのアクセス集中がほかに波及する |
PHPバージョンの設定粒度が細かければ、サイトごとに切り替えの時期をずらせます。アカウント単位であれば、全サイトを同じ日に検証する前提です。同居させるかどうかは、更新時に全サイトを検証できる体制があるかで決めるのが現実的です。
CMSの種類によっても、更新や検証の負担は変わります。構成の選び方はWordPressとヘッドレスCMSの違い｜自社に合うCMSの選定基準が参考になります。
主要レンタルサーバー各社の設定粒度と告知の公式情報
本記事では、公式ページで直接内容を確認できた範囲のみを掲載しています。掲載がないことは、対応の有無を示すものではありません。記載は2026年10月23日に閲覧した内容です。告知は更新が続くため、最新の内容は公式ページで確認してください。
PHPバージョンの設定粒度
| サービスと公式ページ | 公式ページに記載された設定の粒度 |
|---|---|
| エックスサーバー 「PHPのバージョンについて｜レンタルサーバーならエックスサーバー」（2026年10月23日閲覧） |
ドメイン単位 |
| ロリポップ! 「PHP設定 – ロリポップ！レンタルサーバー」（2026年10月23日閲覧） |
ドメイン単位（すべてのドメインへの一括設定も可） |
| ConoHa WING 「PHPの設定をする｜ConoHa WINGサポート」（2026年10月23日閲覧） |
ドメイン単位 |
| mixhost 「PHPのバージョン変更 | mixhostヘルプ＆サポート」（2026年10月23日閲覧） |
現行プランはドメイン単位、旧プランはアカウント単位 |
| コアサーバーV2 「PHPのバージョン変更（ドメイン別） | マニュアル | サポート | レンタルサーバー CORESERVER（コアサーバー）」（2026年10月23日閲覧） |
ドメイン単位 |
このほか、インストール済みのWordPressごとにバージョンを選べる、WordPress単位で設定できるサービスもあります。
今回の脆弱性に関する告知
本文を直接確認できた告知のみを載せています。いずれも2026年10月22日付です。パッチ番号の書き方は会社によって異なり、表示される番号が修正前のままになる場合があると記載している会社もあります。
| サービスと告知ページ | 適用方式の記載 | 番号に関する記載 |
|---|---|---|
| エックスサーバー 「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」（2026年10月23日閲覧） |
PHP 5.6〜8.1はバージョン番号を変えずに対策、8.2〜8.5は同じ系列の修正版に更新 | 具体的なパッチ番号の記載なし |
| ロリポップ! 「PHPの脆弱性への対応に伴うメンテナンス完了と経緯のご報告」（2026年10月23日閲覧） |
8.2〜8.5は開発元の修正版を適用、7.4・8.0・8.1は開発元が提供した修正を適用、5.3〜7.3は独自に修正を作成して適用 | 修正版として8.2.35、8.3.36、8.4.27、8.5.12を記載 |
| ConoHa WING 「【重要】PHPの脆弱性への弊社対応完了のお知らせ（終報）」（2026年10月23日閲覧） |
PHPのバージョンは上げず、修正のみを取り込む方式 | 開発元の修正版8.5.12に対し、表示は8.5.11になる例を記載 |
| mixhost 「【完了】PHPの重大な脆弱性への対応について」（2026年10月23日閲覧） |
PHPのバージョン番号を変更せずに適用 | phpinfoなどの表示（例: 8.4.26）は修正後も変わらないと記載 |
| コアサーバー（掲載先はバリュードメイン） 「【重要】PHPの脆弱性へのセキュリティアップデートに関する対応状況と動作確認のお願い」（2026年10月23日閲覧） |
提供中の全PHPバージョンに修正を適用 | バックポートの適用により、phpinfo()などの表示が変わらない場合があると記載 |
契約中のバージョンが修正版の番号に到達しているのか、番号を据え置いて修正を取り込む方式なのかは、告知の記載で読みます。管理画面に表示される番号は、告知と合わせて読むのが基本です。
レンタルサーバー選定のチェックリスト
確認項目は7つで、確認先は公式マニュアル、提供バージョン一覧、契約先の告知が中心です。契約後の更新作業の負担を左右する項目に絞りました。
| 確認項目 | 見るポイント |
|---|---|
| 1. 提供バージョンの選択肢 | 現行の系統が選べるか。サポート終了が近い系統だけでないか（8.2は2026年12月31日に終了予定） |
| 2. 設定の粒度 | ドメイン単位、WordPress単位、アカウント単位のどれか |
| 3. ステージングの置き方 | 本番と別にバージョンを設定して検証できる構成か |
| 4. 修正版の番号の見方 | 管理画面の表示と修正版の番号の関係。据え置き方式の場合の確認方法 |
| 5. 告知の確認先 | 障害・メンテナンスの告知の掲載場所と、メールで届くか |
| 6. 同居サイトの検証負荷 | 1台に載るサイトの数と、更新時に検証する担当・手順 |
| 7. バージョンを戻せるか | 切り替え後に問題が出たとき、元のバージョンへ戻せる設定か |
当社の構成で影響が大きかったのは、3番目のステージングの置き方です。同一ドメイン配下では先行して切り替えられず、検証の順序を組み替える必要がありました。見積もりや契約の確認項目はWeb制作会社の選び方とは｜見積もりで必ず確認すべき5つの内訳ポイントが参考になります。
サーバー選定は、料金の比較だけで終えず、更新時の検証のしやすさまで確認することをおすすめします。
自社のサーバー構成を確認するときの判断の起点
読んでも決めきれない場合は、次の表で自社に最も近い条件の行から着手します。
| 自社の条件 | 最初に確認すること |
|---|---|
| PHP 8.1以前で動いている | 契約中のサーバー会社の告知で、対応状況を確認する。そのうえで8.2以降へ移る計画を立てる |
| PHP 8.2系で動いている | 8.2.35に到達しているか告知で確認する。2026年12月31日に終了予定のため、移行先も決める |
| PHP 8.3系・8.4系・8.5系で動いている | 修正版（8.3.36、8.4.27、8.5.12）に到達しているか告知で確認する。番号を据え置く方式なら、告知の記載で適用状況を読む |
| 1台に複数のサイトを載せている | PHPバージョンの設定粒度を確認し、切り替えが及ぶサイトの範囲を洗い出す |
| ステージングを本番と同じドメイン配下に置いている | ステージングだけ先に切り替えられるかを契約先に確認する。できない場合は、バージョンに依存しない作業を先に済ませる順序を検討する |
| 契約先の告知や構成を社内で判断できない | サイトの保守を担当している制作会社や、保守契約の範囲から確認する |
複数の条件に当てはまる場合は、サイトが止まるおそれのある項目から先に確認します。構成が古く更新の負担が大きい場合は、Webサイトリニューアルの判断基準｜中小企業が知るべきタイミングと費用相場でリニューアルの要否を整理できます。社内で対応する範囲と外部に任せる範囲の線引きは、マーケティング内製化と外注の判断基準｜投資対効果から考える分岐点とはが参考になります。公開後の運用まで任せたい場合は、Webサイト制作・運用が対象です。
マーケティング支援サービスの資料ダウンロード
アズ・マーケティングのサービス内容・支援実績・料金体系をまとめた資料を無料でダウンロードいただけます。マーケティング戦略の検討にお役立てください。
よくある質問
Q PHPの脆弱性対応は、バージョンを上げれば完了ですか？
完了の基準は、系統を上げることではなく、修正版の番号に到達することです。今回の脆弱性では、8.5.12、8.4.27、8.3.36、8.2.35が修正版にあたります。管理画面の表示番号が変わらない方式の会社もあるため、契約先の告知で適用状況を確認してください。
Q レンタルサーバーのPHPバージョンはどの単位で設定できますか？
公式ページで確認できた範囲では、ドメイン単位、WordPress単位、アカウント単位の3パターンがあります。同じ会社でもプランや契約時期で異なる場合があるため、契約前に公式マニュアルで、設定が及ぶ範囲と切り替え時の影響範囲を確認することをおすすめします。
Q 複数のサイトを1つのレンタルサーバーで運用するリスクは？
コストと管理画面を一元化できる反面、更新時の影響範囲が全サイトに及ぶ、障害で同時に止まる、検証の工数が増える、1つのサイトの負荷がほかに波及するといったリスクがあります。PHPの設定粒度と、すべてのサイトを検証できる体制を、同居の前に確認します。
Q PHP 8.1以前を使っている場合、修正版の確認は何をすればよいですか？
8.1以前には、開発元の通常リリースとしての修正版はありません。7.4、8.0、8.1向けにはバックポートが公開され、サーバー会社やディストリビューションが独自に適用している場合があります。まず、契約中のサーバー会社の告知で、今回の脆弱性への対応状況を確認します。
Q 法人がレンタルサーバーを選ぶときの選定基準は何ですか？
提供バージョンの選択肢、設定の粒度、ステージングの置き方、修正版の番号の見方、告知の確認先、同居サイトの検証負荷、バージョンを戻せるかの7項目を確認します。料金だけでなく更新時の検証のしやすさまで見るのが基本です。ご不明な点については、当社へのご相談もご検討ください。
