WordPressの更新は要らないが、PHPの更新は要る。公式の記事が書いたこと ── サイトヘルスで版を見て、事業者に確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — WordPress.orgは、WordPressの更新は要らず、PHPの更新が要ると書いた
   1. 2026年10月21日に出た、WordPress.orgの短い告知
   2. 告知がWordPressの運営者に言っていること
   3. 告知の5つの要点を、運営者の動作に直す
2. 02 なぜ・背景 — 「WordPressを更新すれば直る」と思い込むと、PHPが放置される
   1. WordPressの下に、PHPがある
   2. 欠陥は、PHPを使うすべてのサーバーにある
   3. よくある誤解を4つ並べる
   4. 同じ公式サイトに「8.3」と「8.2」の2つの数字がある
   5. WordPress自身の文書も、版の更新を事業者に任せる書き方をしている
3. 03 この記事に出てくる用語
   1. PHPとPHPの版・系統
   2. サイトヘルス
   3. WAF（Webアプリケーションファイアウォール）
   4. バックポートとLTSベンダー
4. 04 型別 — サイトヘルスで版を見て、事業者に確かめる
   1. 🅰 この確認が当てはまるサイト
   2. 🅱 この確認が測っていないこと
   3. 🅲 手順: 型を見分け、版を見て、事業者に確かめる
   4. 手順1: サイトヘルスでPHPの版を見て、書き写す
   5. 手順2: 表示された版を、系統ごとの修正版と見比べる
   6. 表示された番号が、修正を当てたかを決めない場合がある
   7. 手順3: 事業者の告知を探す
   8. 手順4: 告知が無いか、版が書かれていないなら、問い合わせる
   9. 手順5: 自分で版を選べる場合は、バックアップ → 互換の確認 → 変更 → 確認の順で進める
   10. WordPress本体の版は、新しいPHPを選ぶ妨げになりにくい
   11. 手順6: 版を変えたあと、4か所を開いて、サイトヘルスを取り直す
   12. 手順7: 攻撃を受けたかもしれないときの見方
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新がすぐできないときに、取りうる道
   1. 4つの選択肢と、それぞれの限界
   2. 暫定策は「安全にする」のではなく「経路を減らす」
   3. サイトを止める判断の材料
   4. 8.1以前を使い続けている場合の選び方
7. 07 当サイトで確かめたこと — この記事の根拠にした10ページと、確かめていないこと
   1. 2026年10月23日に取り直して照らした10ページ
   2. 確かめていないこと
   3. 当サイトのサーバーの対応
8. 08 このテーマは、ここまで
   1. 2026年10月21日 — PHP公式とWordPress.orgの告知
   2. 2026年10月23日 — この記事の確認日
   3. 便乗への注意は、公式の記述からの筆者の読み
9. 09 この記事のまとめ

01 何が書いてあるか — WordPress.orgは、WordPressの更新は要らず、PHPの更新が要ると書いた

2026年10月21日に出た、WordPress.orgの短い告知

2026年10月21日、WordPress.orgのニュースに「Critical PHP Security Release」（訳: 重大なPHPのセキュリティ更新）という記事が載った。書き手はJohn Blackbourn氏、分類は「Security」である。PHPの開発チームが出した、重大な脆弱性2件の修正版を受けた告知で、WordPressのサイトを持つ人に向けて、短くまとまっている。PHP側の中身（2件の欠陥の仕組み、版の表、暫定策）は、ブログPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いたので、ここでは繰り返さない。

この記事は、告知のうちWordPressを運営する人の動作につながる部分だけを取り出し、サイトヘルスで版を見る手順、事業者に聞くこと、自分で版を選べる場合の進め方まで、1つの作業としてたどる。

告知がWordPressの運営者に言っていること

告知は、まず、PHPの開発チームが重大な脆弱性2件を直したことを知らせたうえで、サイトの持ち主に次のように呼びかける。

"Due to the critical severity of the issues, site owners are encouraged to immediately update their installations of PHP."

（訳: 問題が重大であるため、サイトの持ち主は、PHPのインストールをただちに更新することが勧められる。）

続けて、WordPressの管理画面でPHPの版を見る場所を、次のように示している。

"Within WordPress, you can see which version of PHP your site runs under Tools > Site Health > Info > Server."

（訳: WordPressの中では、サイトが動いているPHPの版を、「ツール」「サイトヘルス」「情報」「サーバー」で見られる。）

そして、告知の中心になる一文が、これである。

"These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues."

（訳: これらの脆弱性はWordPressに限ったものではなく、PHPのアプリケーションを動かすあらゆるサーバーに影響する。この問題のために、WordPressの更新は必要とされておらず、予定もされていない。）

告知の5つの要点を、運営者の動作に直す

告知の内容を、運営者がやることの形に直すと、次の表になる。「公式が書いたこと」の列は告知の要旨で、「運営者の動作」の列は、筆者がそれを実行できる形に直したものである。

02 なぜ・背景 — 「WordPressを更新すれば直る」と思い込むと、PHPが放置される

WordPressの下に、PHPがある

WordPressのサイトは、いくつかの層が重なって動いている。いちばん下に、事業者が管理するサーバーがある。その上で、PHPという言語を動かす部分がある。その上に、WordPress本体が乗り、さらにその上に、テーマとプラグインが乗る。管理画面の「更新」で直せるのは、上の2層（WordPress本体と、テーマ・プラグイン）である。

図の下の2層は、多くのサイトでは事業者が管理している。そのため、運営者が「更新」ボタンを押しても、PHPの層は変わらない。WordPress.orgが「WordPressの更新は必要でなく、予定もされていない」と書いたのは、この構造のためである。

欠陥は、PHPを使うすべてのサーバーにある

PHP公式サイトの2026年10月21日の告知は、誰が危険にさらされるかを、次のように書く。

"Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed."

（訳: 危険にさらされるのは誰か。Webの要求を処理しているすべてのPHPのインストールで、PHP-FPM、mod_php付きのApache、php-cgi、FrankenPHP、LiteSpeedを含む。）

WordPressは、この「Webの要求を処理するPHP」の上で動く。WordPress側に手を入れても、下の層の欠陥は残る。逆に、WordPressを使っていないPHPのサイトにも、同じ欠陥がある。

よくある誤解を4つ並べる

公式の告知から、運営者が陥りやすい誤解を4つ選ぶと、次のようになる。

• 誤解1: WordPressを最新にしてあるから大丈夫 — 公式は、WordPressの更新は必要でないと書いた。WordPressの版が最新でも、PHPの層は別に確かめる
• 誤解2: サイトヘルスに警告が出ていないから大丈夫 — 警告は、PHPの版が古いかどうかの目安で、今回の修正が当たったことの保証ではない
• 誤解3: 事業者が直してくれているはず — 公式は「進めているかもしれない」と書き、そのうえで確かめることを求めた
• 誤解4: PHPの版が8.3以上なら、今日は何もしなくてよい — 04章の手順2に書くとおり、8.3系で修正が入った版は8.3.36であり、系統の数字だけでは決まらない

同じ公式サイトに「8.3」と「8.2」の2つの数字がある

WordPress.orgの文書を読むと、PHPの版の数字が2つ出てくる。ひとつは、WordPressの要件のページの数字で、ホスティングに勧める版として、「PHP version 8.3 or greater.」（訳: PHPの版は8.3以上）と書く。もうひとつは、今回の告知の「8.2より前の版は、セキュリティ更新を受けない」である。

この2つは、別のことを言っている。8.3は、WordPress.orgが勧める版（速さと安全のための目安）で、8.2は、PHPプロジェクトが今も修正版を出している版の下限である。今回の修正版は、8.2系なら8.2.35、8.3系なら8.3.36というように、系統ごとに番号が違う。同じ系統の中で、修正版の番号に達しているかが、本当に確かめるべきことになる。

WordPress自身の文書も、版の更新を事業者に任せる書き方をしている

WordPress.orgの「PHPを更新しよう」の文書は、PHPの版を決める主体を、次のように書く。

"Your hosting company determines which versions of PHP are available for your site, and many hosters let you change this yourself."

（訳: あなたのホスティング会社が、サイトで使えるPHPの版を決める。そして、多くのホスティング会社では、これを自分で変えられる。）

03 この記事に出てくる用語

PHPとPHPの版・系統

WordPressが書かれている言語がPHPで、サーバーの上でプログラムを動かす。版は、「8.3.36」のように3つの数字で表す。最初の2つ（8.3）が系統、3つ目（36）が、その系統の中の修正の通し番号である。

サイトヘルス

WordPressの管理画面にある診断の画面で、「状態」と「情報」の2つのタブがある。WordPress.orgのドキュメントは、「情報」のタブを次のように説明している。

"There is also a useful export feature that allows you to copy all of the information about your site to the clipboard."

（訳: そのほか、サイトのすべての情報をクリップボードにコピーできる便利な書き出しの機能もある。）

この書き出しは、事業者への問い合わせに貼る材料として使える。ただし、サーバーの設定が含まれるので、貼る先は事業者の問い合わせ窓口に限る。

WAF（Webアプリケーションファイアウォール）

Webへの通信の中から、攻撃に見えるものを選んで止める仕組みをいう。事業者が入れていることがあるが、PHP公式は、完全な解決は更新だけだと書いている（06章に引用）。

バックポートとLTSベンダー

バックポートは、新しい版で作った修正を、古い版にも当てることをいう。PHP公式の告知は、ディストリビューションやLTSベンダー（長期のサポートを売る会社）の中に、バックポートされた修正を出すところがある、と書く（04章に引用）。画面に出る版の番号だけでは、修正が当たったかを決められない場合がある、ということだ。

04 型別 — サイトヘルスで版を見て、事業者に確かめる

🅰 この確認が当てはまるサイト

WordPressで作ったサイトを、自分で、または制作会社の担当として運営している人が対象である。契約はレンタルサーバー、WordPress専用のマネージドサービス、自分で管理するVPSのどれでもよい。複数のサイトを担当しているなら、1サイトずつ回す。担当サイトの全体を一覧にする作業は、別の解説記事PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）で扱う。

🅱 この確認が測っていないこと

• 攻撃を受けたかどうか — 版を確かめる手順は、いま安全かを保証しない。受けたかもしれないときの見方は、末尾の手順に別に置く
• 特定の事業者の対応状況 — 事業者の名前と対応は書かない。公式の告知を開いて、自分で確かめる
• プラグインやテーマがPHPの新しい版で動くか — 公式が勧める確認方法を紹介するだけで、個別の動作は試験環境で試す
• サイトヘルス画面の実機での表示 — 公式のドキュメントの記述に基づく。画面の文言は版で変わることがある

🅲 手順: 型を見分け、版を見て、事業者に確かめる

最初に、自分のサイトが次のどの型かを確かめる。型によって、PHPを更新する人が違うからである。

表の「共用のレンタルサーバー」で管理画面から版を選べる、という書き方は、WordPress.orgの文書の「多くのホスティング会社では、これを自分で変えられる」に沿っている。ただし、契約によって違うので、自分の管理画面で確かめる。

手順1: サイトヘルスでPHPの版を見て、書き写す

管理画面の「ツール」から「サイトヘルス」を開き、「情報」のタブにある「サーバー」を開く。PHPの版を示す欄があるので、表示されている文字を、そのまま書き写す。同じ欄のほかの行（サーバーの構成やウェブサーバーなど）も写すと、問い合わせの材料になる。WordPress.orgのドキュメントは、「サーバー」の欄に、サーバーの構成、ウェブサーバー、PHPの各種の変数などが出る、と説明している。

手順2: 表示された版を、系統ごとの修正版と見比べる

PHP公式の告知が挙げる修正版は、8.5.12、8.4.27、8.3.36、8.2.35である。書き写した版が、自分の系統の修正版の番号以上かを見る。たとえば表示が「8.3.20」なら、8.3系の修正版8.3.36に届いていない。分かるのは、表示された番号が修正版に届いているかまでである。

表示された番号が、修正を当てたかを決めない場合がある

PHP公式の告知は、次のように書く。

"Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version."

（訳: ディストリビューションやLTSベンダーの中には、バックポートされた修正を提供するところがある。詳しくはその事業者に連絡するか、サポートされている版に上げるとよい。）

この場合、画面の番号は元の版のままで、修正は入っていることがありうる。したがって、番号が修正版に届いていなくても「入っていない」と決めつけず、事業者に適用したかを聞く。届いているときも、事業者の告知で裏を取ると確かである。

手順3: 事業者の告知を探す

契約している事業者の「お知らせ」「障害・メンテナンス情報」のページを開き、PHPの脆弱性に触れた告知を探す。見つかったら、対象のプラン、完了した日時、適用した版の番号を書き写す。「メンテナンス完了」の表示は、運営者が選んでいる版にまで当たったことを意味するとは限らない（筆者の推測で、公式の文書の記述ではない）。告知の文面で確かめる。

手順4: 告知が無いか、版が書かれていないなら、問い合わせる

告知が見つからないとき、または告知に版の番号が無いときは、問い合わせる。問い合わせの文は、次の3つを聞く形にするとよい。

1. PHPの重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）の修正を、私の契約のサーバーに適用したか
2. 適用した日時と、適用後のPHPの版の番号
3. 私のサイトが選んでいるPHPの系統が、修正の対象に入っているか

手順1で書き写した、サイトヘルスの「サーバー」の欄の内容を、問い合わせに添える。事業者が、運営者のサイトを特定しやすくなる。

手順5: 自分で版を選べる場合は、バックアップ → 互換の確認 → 変更 → 確認の順で進める

管理画面にPHPの版を選ぶ設定があるときは、運営者が自分で更新を進められる。WordPress.orgの「PHPを更新しよう」の文書は、版を変える前に、バックアップを取り、WordPress、テーマ、プラグインを更新し、PHPの互換性を確かめるよう書いている。

同じ文書は、互換性について、こう書く。

"WordPress itself works with PHP as far back as version 7.4, but we don’t know if your themes or plugins will work on newer versions."

（訳: WordPress自身は7.4までさかのぼるPHPで動くが、あなたのテーマやプラグインが、新しい版で動くかは分からない。）

ここで挙がる互換性の確認は、系統を上げる（たとえば8.1から8.3へ）ときほど、必要になる。同じ系統の中で修正版に上がるだけなら、通常は変更が小さい（これは筆者の整理で、公式の文書の記述ではない）。管理画面が系統までしか選べない契約では、その系統の中の、どの版に当たるのかを、事業者に聞く。

WordPress本体の版は、新しいPHPを選ぶ妨げになりにくい

WordPress開発チームの互換性のページ（最終更新2026年8月19日と表示）の表では、WordPress 7.1と7.0の行が、PHP 8.5から7.4まですべて「Y」（対応）である。そのため、本体が最近の版なら、修正版を含む8.2から8.5へ上げることを、本体の側が妨げる場面は少ないと読める（筆者の読み。確かめるのはテーマとプラグインの側になる）。古いWordPressなら、この表の自分の版の行を先に見る。

手順6: 版を変えたあと、4か所を開いて、サイトヘルスを取り直す

版を変えたあとは、トップページ、投稿1本、固定ページ1本、管理画面のログインの4か所を開いて表示を見る。そのあとサイトヘルスを開き直し、PHPの版が変わったことと警告の数を書き写す。

手順7: 攻撃を受けたかもしれないときの見方

PHP公式とNCSCは、更新できない場合の暫定策と、侵害の有無の確認について書いている。NCSCの告知は、更新も暫定策も当面できない場合について、こう書く。

"If you are unable to update or disable the system immediately then you should assess the system for any evidence of compromise prior to your upgrade or mitigation and look for backdoors installed by an attacker."

（訳: 更新もシステムの停止もすぐにはできない場合は、更新や緩和策の前に、システムに侵害の証拠がないかを評価し、攻撃者が仕込んだバックドアを探すべきである。）

WordPress.orgの「サイトがハッキングされた」というFAQは、侵害の例として、検索エンジンのブラックリストに載った、事業者がサイトを止めた、承認していない動作（たとえば新しいユーザーの作成）に気づいた、などを挙げている。管理者のユーザー一覧に、心当たりのないユーザーが居ないかは、5分以内に確かめられる。

05 明日、自社のサイトで確認できることチェックリスト

以下は、WordPressの運営者が、PHPの脆弱性への対応を確かめる13項目である。1〜4番目は版を見る、5〜8番目は事業者に確かめる、9〜11番目は版を変える場合、12〜13番目は侵害の確認と記録である。1項目は5分以内でできる。チェックの状態はブラウザに保存され、サーバーには送られない。

• WordPressの管理画面で「ツール → サイトヘルス → 情報 → サーバー」を開き、PHPの版の表示を書き写す
• 同じ「サーバー」の欄にある、サーバーの構成やウェブサーバーの行も書き写し、問い合わせに貼れる形にする
• 書き写した版を、PHPの系統ごとの修正版（8.5.12、8.4.27、8.3.36、8.2.35）と見比べ、修正版の番号以上かを1行で書く
• 表示の版が8.1以前なら、その日のうちに事業者へ送る問い合わせの文を書き、送る
• 契約している事業者の「お知らせ」のページを開き、PHPの脆弱性に触れた告知を探す
• 告知が見つかったら、対象のプラン、完了した日時、適用した版の番号を書き写す
• 告知が無いか、版が書かれていないなら、「適用したか・いつか・適用後の版」の3つを聞く問い合わせを送る
• 事業者から返事が来たら、日付と版の番号が入っているかを見て、入っていなければ聞き返す
• 管理画面にPHPの版を選ぶ設定があるか探し、あれば選んでいる版を画面から写す
• 版を変える前に、バックアップを取り、取れたファイルの日時を確かめる
• 版を変えたあと、トップ、投稿1本、固定ページ1本、管理画面のログインの4か所を開いて、表示を確かめる
• 管理者のユーザー一覧を開き、心当たりのないユーザーが居ないかを数える
• 確かめた日付と結果を1行で書き、次に事業者の告知を見直す日を決める

1番目と3番目の確認で、版の表示が修正版に届いているかを書き写したら、サイトの外から見える情報も合わせて調べるとよい。当サイトの無料ツールの1つ、🔧 WEBサイトの外からできるセキュリティ対策監査ツールは、外部からサイトの情報を集め、利用しているCMSやフレームワークなどのWebテクノロジーの検出も含めて、セキュリティリスクを評価する（要ログインのツール）。このツールの結果が、PHPの版の番号まで示すかどうかは、この記事では確かめていない。

9番目から11番目の版を変える前後には、比べる道具が使える場合がある。🔧 WEBサイトの状況チェック・比較ツールは、2つのURLのサイトを、サイト内を回遊して全ソースで比べる道具である（要ログインのツール）。更新の前後を比べるには、更新前の写しを別のURL（試験環境など）に置いておく前提になる。

06 代替・他の選択肢 — 更新がすぐできないときに、取りうる道

4つの選択肢と、それぞれの限界

更新がすぐにできないとき運営者が取りうる道を、表にまとめる。「限界」の列は、筆者の整理である。

暫定策は「安全にする」のではなく「経路を減らす」

PHP公式の告知は、暫定策について、次のように書く。

"If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe."

（訳: すぐに更新できない場合。完全な解決は更新だけだが、次の対策は、特定の攻撃の経路への露出を減らす。ただし、インストールを安全にするものではない。）

事業者がWAFのルールを入れていても、同じことがいえる。経路を減らす手段であって、更新の代わりにはならない。このため、事業者に聞く質問は、「暫定策を入れたか」ではなく、「修正版を適用したか」にするのがよい。

サイトを止める判断の材料

WordPress.orgの告知は、8.2より前の版でサーバーを自分で管理している人に、NCSCの文を引いて、止めることを検討するよう書く。引かれている文は、次のとおりである。

"Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated."

（訳: すぐに修復できない場合、組織は、完全に緩和できるまで、システムを止めることを検討すべきである。）

この文は、組織向けに書かれたものである。止める損失（問い合わせが来なくなる）と、止めない危険（攻撃を受ける）を並べて、事業者の返事とPHPの版を材料に判断する。

8.1以前を使い続けている場合の選び方

PHP公式の告知は、8.1以前について、こう書く。

"PHP 8.1 and older no longer receive updates from the PHP project."

（訳: PHP 8.1以前は、PHPプロジェクトから更新を受けない。）

8.1以前の契約では、運営者の取りうる道が少ない。事業者がバックポートの修正を出しているかを聞き、出していないなら、サポートされている版へ上げる計画を事業者と立てる。8.2系のセキュリティサポートは2026年12月31日までである。移行の進め方は、解説記事PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）にある。

07 当サイトで確かめたこと — この記事の根拠にした10ページと、確かめていないこと

2026年10月23日に取り直して照らした10ページ

この記事の引用は、2026年10月23日に、WordPress.orgの告知、PHP公式サイトの3ページ（2026年のニュース、サポートされている版、サポートの終わった系統）、WordPress.orgの文書4ページ、WordPressの互換性のページ、NCSCの告知の、合わせて10ページの本文を取り直して、1文字ずつ照らしたものである。引用の英文は、本文から全部抜き出して原文と照らした。

確かめていないこと

• サイトヘルス画面の実機での表示 — 公式のドキュメントの記述に基づく
• 各事業者の対応状況 — 公式の告知を開いて確かめたものだけを書く、という考えにより、書かない
• 偽の更新を装った便乗の事例 — この記事を書いた時点で、具体的な事例を確かめていない。確かめていないことは書かない。08章の注意は、公式の告知の記述からの筆者の読みである

当サイトのサーバーの対応

当サイト自身のサーバーの対応と、チームの記録は、ブログPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いてある。サーバーの設定の中身は、公開すると攻撃の手がかりになるので、この記事には書かない。当サイトのサーバーを更新した別の例は、ブログ記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.69を、記事を公開したその日に上げるまでにある。

08 このテーマは、ここまで

2026年10月21日 — PHP公式とWordPress.orgの告知

PHP公式サイトが重大な脆弱性の修正版（8.5.12、8.4.27、8.3.36、8.2.35）を告知し、同じ日に、WordPress.orgが「WordPressの更新は必要でなく、予定もされていない」と書いた。

2026年10月23日 — この記事の確認日

この記事の内容は、2026年10月23日に、10ページを開いて確かめた時点のものである。公式の記述が変わったときは、この記事に日付つきで追記する。

便乗への注意は、公式の記述からの筆者の読み

WordPress.orgが「更新は必要でなく、予定もされていない」と書いたことから、「WordPressをこの脆弱性のために更新してください」と促すメールや、更新を装ったプラグインの案内は、公式の記述と合わない、と読める。メールのリンクを押す前に、管理画面の「ダッシュボード → 更新」の表示と見比べる。具体的な便乗の事例は確かめていない。