WordPressのPHP更新は誰がする？確認ポイント4つ
コラム学校のPTAや地域のサークル、小規模な教室などでWordPressを使ってウェブサイトを運営していると、サーバーやセキュリティに関する通知が届くことがあります。日頃は記事の投稿や写真の差し替えといった更新作業を行っていても、裏側で動いているプログラムの更新と言われると、自分たちで触るべきものなのか判断に迷う場面があるかもしれません。
2026年10月には、PHPに関する重大な脆弱性としてCVE-2026-109618とCVE-2026-109619が公表され、多くのサーバー環境で早急な対応が求められました。
安全にサイトを維持するためには、WordPress本体の更新とサーバーのPHP更新の違いを理解し、管理会社やホスティング会社へ確認すべきポイントを押さえておく必要があります。
目次
WordPress本体の更新とサーバーのPHP更新の違い
WordPressを運用していると、管理画面のダッシュボードに更新の通知が表示される場面をよく見かけます。ここからワンクリックで更新できるのは、WordPressの本体プログラムや、デザインを決めるテーマ、機能を追加するプラグインの3つです。
一方で、WordPressを動かしている土台であるPHPは、サーバー上で稼働するプログラミング言語であり、WordPressの管理画面から直接バージョンを切り替えることはできません。
WordPress公式サポートページのGet a faster, more secure website: update your PHP today – WordPress.orgでも、利用できるPHPのバージョンを決定しているのはホスティング会社であり、切り替えもホスト側を通じて行う操作であると明記されています。
サイト運営者が日常的にログインして操作するWebアプリケーションの層と、サーバー会社が管理する実行基盤の層という明確な境界が存在します。この役割の違いを把握しておくと、管理画面で存在しない設定ボタンを探して時間を浪費したり、誤った操作で混乱したりする事態を防げます。
今回の脆弱性でWordPress本体の更新は必要か
2026年10月21日、PHP開発チームから公式リリースPHP: News Archive – 2026が公表され、メモリ処理の不具合に起因するCVE-2026-109618と、リクエスト処理に起因するCVE-2026-109619の2件が修正されました。未認証の攻撃者による遠隔コード実行を許す可能性があるとされ、ウェブ要求を処理する幅広いPHP環境が対象といわれています。
この発表を受けて、利用中のWordPress本体を急いでアップデートすべきか気になるところですが、結論としてWordPress本体側の更新は不要とされています。
WordPress公式ニュースのCritical PHP Security Releaseでは、今回の問題はWordPress固有の欠陥ではなくサーバーで動作するPHPそのものに起因するため、WordPress本体の修正リリースは不要であり予定もしていないと案内されています。
サイト運営者に求められているのは、WordPress本体の更新を待つことではなく、サーバー側で動くPHPが脆弱性の修正されたバージョンに対応しているかをホスティング会社や管理会社へ確認する作業です。
管理会社・ホスティング会社に確認する4つのポイント
サーバー側のPHP更新は、契約しているホスティング会社の管理パネルから切り替えるか、サイトの保守を委託している管理会社へ作業を依頼するのが一般的な流れです。問い合わせや依頼を行う際は、単に最新にしてくださいと伝えるだけでなく、安全に作業を進めるための4つの確認ポイントを押さえておく必要があります。
修正版の提供状況を確認する
1つ目のポイントは、利用中のサーバー環境において、脆弱性の修正版が提供されているかどうかの確認です。
PHP開発チームが公開した正式な修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12以降となります。しかし、管理画面やサーバー情報に表示されるバージョン番号の数字だけでは、修正済みかどうかを即座に判断できない場合があります。
ホスティング会社やOSのディストリビューションによっては、既存のバージョン番号を維持したまま、セキュリティ修正だけを独自に取り込んで反映させる運用を行っているためです。
たとえばUbuntu公式のセキュリティ告知 USN-8948-1を確認すると、Ubuntu 24.04環境のPHP 8.3に対して「8.3.6-0ubuntu0.24.04.13」という独自の修正済みパッケージ番号が付与されています。見かけの番号が8.3.6であっても、提供元による修正が反映されている場合があります。
管理画面に表示されるバージョン番号の比較だけで判断せず、ホスティング会社や管理会社に対して「今回の2件の脆弱性に対応した修正パッケージが適用されているか」を問い合わせることが確実な確認方法となります。
バックポート対応の有無を確認する
2つ目のポイントは、利用中のPHP系列に応じた修正の適用方針を確かめることです。
PHP 8.1以前の古い系列を利用している場合でも、サーバー環境によっては、ホスティング会社やOS提供元が独自にセキュリティ修正を取り込むバックポートを実施している場合があります。
同様に、PHP 8.2以降のバージョンを使っている場合であっても、前述のように提供元ごとの告知内容やパッケージ更新番号によって修正の反映状況は異なります。
利用している系列の見かけのバージョン番号だけで判断せず、ホスティング会社やOS提供元によるセキュリティ告知を確認し、修正パッケージが提供されているかを確かめることが重要です。もし修正が提供されていない場合は、安全に利用できるバージョンへの切り替えについて管理会社や事業者に相談しましょう。
復旧手段の準備を確認する
3つ目のポイントは、更新作業に伴うトラブルに備えた復旧手段の確保です。
PHPのバージョンを変更すると、使用しているWordPressのテーマや古いプラグインが新しい環境に対応できず、画面が正しく表示されなくなったり機能が停止したりするリスクがあります。前述のWordPress公式ガイド（update-php）でも、更新前の事前バックアップと互換性の確認が強く推奨されています。
管理会社やホスティング会社へ更新を依頼する際は、データベースやファイル全体のバックアップが直近で取得されているかを必ず確認してください。
万が一更新後に重大な不具合が発生した場合に備え、以前の正常な状態へ速やかに復旧できる手順が整っているかを作業前に合意しておくことが、安全な運用の基本です。
更新後の動作確認を依頼する
最後のポイントは、サーバー側の切り替え作業が完了した直後の動作検証です。
サーバーの更新作業自体は事業者が行いますが、その結果としてウェブサイトが正常に閲覧できるか、各種機能が意図通りに動いているかを確かめる責任はサイト運営側にあります。
具体的には、トップページや主要な記事ページの表示崩れがないか、管理者ページへ正常にログインできるか、問い合わせフォームからの送信テストが完了するかといった基本動作を点検します。
自社で確認を行うか、あるいは管理会社の保守範囲として動作確認まで委託しているかを事前に確認しておきましょう。家庭や組織における情報管理の全体像については、個人情報流出が不安なときに｜家庭の対策と相談先でも安全な管理の考え方を整理しています。
よくある質問
Q. 更新後にエラーが出た場合、古いPHPバージョンに戻してそのまま使い続けてもよいですか。
A. 脆弱性を抱えた古いバージョンへ戻したままサイトを公開し続けることは、セキュリティの観点から一般的には推奨されません。表示の崩れやエラーを回避するために一時的な切り戻しが必要な場合でも、管理会社の判断を仰いで安全性を再確認し、プラグインの改修や代替への切り替えを進めたうえで、速やかに修正版へ再移行する方針をとる必要があります。
Q. 管理会社やホスティング会社へ問い合わせる際、どのような文面で伝えるとスムーズですか。
A. 運用中のサイト情報（URL）を添えたうえで、2026年10月に公表されたPHPの脆弱性（CVE-2026-109618、CVE-2026-109619）に対するサーバー側の修正適用状況を確認したい旨を伝えます。あわせて、更新前のバックアップ取得と復旧手順の有無についても確認すると、その後の作業が円滑に進みます。
Q. サーバーの更新を依頼する前に、WordPressの管理画面側で準備できることはありますか。
A. 使用しているテーマやプラグインを、管理画面から最新の状態へ更新しておくことが有効です。古いプラグインが残ったままだと、サーバー側のPHPが修正版へ切り替わった際に互換性のエラーが発生しやすくなるため、事前の更新が推奨されます。
まとめ
WordPressの運用において、管理画面から行う本体やプラグインの更新と、サーバー側で行うPHPの更新は担当する領域が明確に異なります。
2026年10月に公表されたPHPの脆弱性（CVE-2026-109618、CVE-2026-109619）に対しては、WordPress公式ニュースが案内しているとおりWordPress本体の更新は不要であり、サーバー側でのPHP対応が求められます。管理会社やホスティング会社へ連絡する際は、以下のポイントを整理して確認を進めましょう。
– 修正版の提供状況：PHP 8.2.35、8.3.36、8.4.27、8.5.12以降、またはディストリビューション独自の修正パッケージが適用されているか
– バックポート対応の有無：利用中の系列における独自修正の有無や、修正版への移行相談
– 復旧手段の準備：更新作業前のバックアップ取得と、トラブル発生時の復旧手順の合意
– 更新後の動作確認：表示崩れやログイン、フォーム送信などの重要機能が正常に動くかの点検
あわせて読みたい
参考資料
吉田先生やよっしー、たまによしぞーって呼ばれたりしています。よろしくお願いします。
