PleskのPHP緊急修正は二つの確認が必要｜管理画面とサイト用PHPを点検する

Pleskを使うサーバーでは、今回のPHP重大脆弱性への対応を二つに分けて確認する必要があります。契約者のWebサイトで動くPHPに加え、Pleskの管理画面を動かすsw-engineも更新対象です。サイト側のPHPを更新しても、管理画面側まで修正されたという証明にはなりません。

Pleskの公式セキュリティ告知を2026年10月22日に確認しました。本記事はCVE-2026-109618・CVE-2026-109619への対応を、管理パネルとサイト用ランタイムの分担から整理します。以下の確認台帳と作業順序は本サイトの提案です。

管理画面とサイト用PHPを別々に扱う

Pleskの告知は、同梱PHPとsw-engineの影響をそれぞれ説明しています。sw-engineは管理パネルの動作に関わるため、訪問者向けのサイトで選択するPHPとは確認する対象が異なります。管理画面にログインできることや、WordPressが表示されることだけでは、どちらの修正も判定できません。

運用台帳には「Plesk本体の版とUpdate番号」「サイトごとのPHPハンドラー」「PHPの版と必要なビルド情報」を別の列で残します。VPSの所有者、サーバー保守会社、サイト制作会社が異なる場合は、それぞれ誰が確認するかも付けます。曖昧な「PHP更新済み」という連絡を、この三つの情報へ分解する方法です。

さらに、OSが配るPHP、Pleskが配るPHP、独自に追加したPHPは取得元が異なります。同じサーバー上で似た版が並んでいても、ある配布元の告知を別の配布元の実体へ流用しないでください。本記事の修正番号はPleskが示した対象についての情報です。

sw-engineはPleskのUpdate番号まで確認する

告知で示された管理パネル側の修正済みリリースは、Plesk 18.0.80 Update 11と18.0.81 Update 4です。LinuxとWindowsの両方について記載されています。18.0.80や18.0.81という部分だけで判定せず、Update番号を含めて照合します。

確認する系列	告知にある修正済みリリース
Plesk 18.0.80	Update 11
Plesk 18.0.81	Update 4

自動更新を設定していても、対象サーバーが実際にどこまで更新されたかを読み戻します。更新を保留している、管理者の承認が必要、取得先へ接続できなかった、といった運用上の事情は個別に確認が必要です。告知が出た日時と、自分のサーバーへ適用した日時は分けて記録します。

本サイトでは、更新前後の表示、実行結果、担当者、実施時刻を一組で保管することを勧めます。Update番号が期待と異なる場合は、サイト用PHPの切り替え作業へ進んだだけで完了とせず、Plesk本体の更新経路を確認してください。

サイト用PHPは系列ごとの修正版へ更新する

Pleskの告知は、PHP 8.2から8.5についてLinux・Windows向けの修正版を示しています。対象サイトで使っている系列を特定し、その系列の修正を反映します。脆弱性対応と大きな系列変更を同時に行う必要があるかは、互換性も含めて判断します。

PHP系列	告知にある修正版
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

同じ契約者でも、メインサイト、サブドメイン、旧システムで別のPHPを選んでいる場合があります。一つのサイトで修正版を確認した結果を、全ドメインへ広げないことが必要です。サイト一覧とハンドラーの対応を先に把握すると、更新後の確認漏れを減らせます。

管理画面の「ツールと設定」にあるPHP設定などから、利用可能なハンドラーと版を確認します。ただし、ハンドラーがインストールされていることと、そのサイトが実際に選択していることも別です。各サイトのPHP設定までたどり、割り当てられたものを照合してください。

Linuxの旧系列は同じ版でもビルド日が違う

今回のPlesk告知で見落としやすいのは、Linux向けPHP 8.1、8.0、7.4の扱いです。修正前後で8.1.34、8.0.30、7.4.33という版番号が変わらず、2026年10月21日のビルドが修正済みとして示されています。版の数字だけを比較すると、この更新を判別できません。

Linux向けの版表示	告知で示された判定材料
PHP 8.1.34	2026年10月21日の修正済みビルドか
PHP 8.0.30	2026年10月21日の修正済みビルドか
PHP 7.4.33	2026年10月21日の修正済みビルドか

これはPleskが説明するLinux向けパッケージの情報です。同じ版番号を表示する独自ビルドや、Windows向けの旧系列まで修正済みと断定する根拠にはできません。取得元とビルド情報が分からない場合は、保守担当または提供元へ確認します。

また、今回の修正が提供されたことは、旧系列を将来にわたって安全に使い続けられる保証ではありません。緊急の修正適用を先に進めつつ、サポートされる系列への移行計画は別に残してください。短期の対応完了と、長期の保守判断を分けます。

コマンドは対象のPHP実体を明示する

Pleskの告知では、Linux上で特定のPHP実体を指定して版とビルド日を確認する例が示されています。PHP 8.3向けの読み取り例は次のとおりです。対象サーバーと系列に合わせて確認してください。

/opt/plesk/php/8.3/bin/php -v

単にphp -vを実行すると、シェルの検索パスで見つかったPHPを調べることになります。その実体が、確認したいサイト用ハンドラーと同じかを先に照合します。このコマンドでPleskのsw-engineまで検証できるわけでもありません。

出力に修正版が見えても、Webリクエストを処理するサービスが更新後の実体へ切り替わっているかは別途確認します。Plesk側の更新結果と、サイト側のPHP情報を対応させる必要があります。公開ディレクトリーに詳細なphpinfo画面を置き続ける方法は避け、既存の管理機能や保守担当の確認結果を使います。

サーバーへログインする権限がない契約者は、無理に管理者向けコマンドを実行する必要はありません。「対象ドメインのハンドラー」「修正後の版またはビルド」「適用・反映の完了時刻」を問い合わせると、回答を自分のサイトへ結び付けやすくなります。

更新前に復旧手段と確認対象を用意する

次は、本サイトが勧める作業の流れです。実際の更新操作は、契約先や保守会社の運用手順に従ってください。複数人が異なるコンポーネントを更新する場合は、管理画面側とサイト側の担当をあらかじめ分けます。

• 対象サーバー、Pleskの版、公開サイトとPHPハンドラーを記録する。
• バックアップと復旧方法を確認し、実行中の重要な処理を把握する。
• Plesk本体と利用中PHPの修正を、それぞれの更新経路で適用する。
• 更新結果を読み戻し、Update番号、PHPの版、必要なビルド日を照合する。
• 管理画面と各サイトの代表機能を確認し、未確認の対象を残す。

代表機能にはトップページだけでなく、ログイン、投稿、フォーム、画像処理など、そのサイトでPHPを使う重要な操作を選びます。表示できたという一点だけで業務機能まで正常と結論づけないようにします。本サイトは、読者のサーバーでこれらの動作試験を実施したわけではありません。

更新後に不具合が出た場合も、古いパッケージへ戻せば脆弱性への対処まで戻る可能性があります。復旧候補が修正を保つかを確認し、必要なら一時的な機能制限を含めて保守担当と判断してください。元に戻す操作を自動的な安全策とは扱えません。

サーバーが複数ある場合は予備機も確認する

本サイトでは、同じPlesk構成を複製している予備機や、災害復旧用の起動イメージも確認対象として残すことを勧めます。現在の公開機を修正しても、次の切り替えで以前のPHPを持つ環境が復帰する可能性があるためです。

公開を担当するサーバーの一覧と、復旧時に使う元データを対応させます。すぐ更新できない予備機は、起動前に修正する手順と担当者を明記します。この作業は、Pleskの告知が利用者の予備機まで自動更新するという意味ではありません。

対応完了は二つの面で説明できる状態にする

契約者へ報告する際は、「Pleskの管理パネル側はこのUpdateで修正」「対象サイトはこのPHPハンドラーと版で修正」と分けて書くと、何を確認したかが伝わります。独自PHPや未使用か不明な旧ハンドラーは、そのまま未確認事項として残します。

今回のポイントは、Pleskという製品名だけでひとまとめにしないことです。管理画面、サイト用ランタイム、各ドメインの割り当てを結び付けて初めて、自分のサービスへの反映を説明できます。修正の提供状況と実際の対応を、同じ言葉で済ませない運用が必要です。

関連記事

• PHP重大RCEの修正版と更新対象を確認する：今回の脆弱性と上流PHPの修正版を整理しています。
• 国内ホスティング各社のPHP緊急修正対応：サービス提供元と利用者の作業範囲を比較する記事です。