PHPの脆弱性:WordPress運営者の確認手順【2026年10月21日時点】

情報の日時: 2026年10月21日の夜(日本時間)に、PHP公式のページなどで確認した内容です。

（サイト主自身への備忘録でGeminiとまとめたメモです。緊急でまとめたので、今後間違いは修正・訂正いたします。なお、参考サイトは制作時点繋がらないものもありました。復旧後再確認いたします。）

PHP公式は、2026年10月21日付で、重大な脆弱性2件を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。公開時刻の記載はありません(PHP公式の勧告)。WordPress公式も同日、WordPress本体の更新は不要としたうえで、PHPの更新を案内しています(WordPress公式の告知)。最新の情報は、公式でご確認ください。

PHPの重大な脆弱性のニュースを見たものの、自分のWordPressサイトで何を確認すればよいのか分からない。この記事は、そう感じている運営者の方に向けて、確認する順番をまとめたものです。

分かっていることと、公式が書いていないことを分けて書きました。PHPのバージョンの調べ方、ホスティング会社に聞くこと、バックアップ、切り替えと動作確認までを、順に説明します。

私自身もWordPressサイトを運営しているので、「私のサイトでは」という例を、確認した範囲でところどころに添えます。

結論と、最初にやること

PHP公式は、すべてのPHP利用者に、すぐに更新することを強く勧めています(PHP公式の勧告)。

運営者がやることは、確認、問い合わせ、バックアップ、更新の4つです。順に進めます。

最初にやること

1. 確認する。 自分のPHPのバージョンを見ます。管理画面で確認できます(次の節で説明します)。修正版の番号と比べます。
2. 問い合わせる。 ホスティング会社のお知らせを見ます。PHPの更新を会社が行うのか、自分で切り替えるのかで、やることが変わります。お知らせが見つからないときや、自分のバージョンの扱いが分からないときは、問い合わせます。
3. バックアップを取る。 バックアップが取れているかを見ます。データベースとファイルの両方が必要です。
4. 更新する。 会社が更新を行う場合は、その案内に従います。自分で切り替える場合は、バックアップのあとで、修正版のバージョンに更新します。

1から3は、サイトの設定を変えない作業です。

公式が発表したこと(PHPとWordPress)

PHP公式の勧告(#2026-10-21-5)と、GitHubのセキュリティアドバイザリ(CVE-2026-109618、CVE-2026-109619)に書かれていることです。

• 修正版: PHP 8.5.12、8.4.27、8.3.36、8.2.35が、2件の重大な脆弱性を修正しています。
• 脆弱性の内容: 認証なしで、外部からサーバー上でプログラムを実行される(リモートコード実行)可能性がある、とされています。CVE番号は、CVE-2026-109618とCVE-2026-109619です。CVSS v4.0はどちらも9.2と評価されています(事前告知とアドバイザリに記載)。
• 影響を受けるバージョン: アドバイザリでは、8.2.35、8.3.36、8.4.27、8.5.12より前のバージョンが影響を受けるとされています。たとえば8.3系なら、8.3.35以前が対象です。
• 影響を受ける環境: Webのリクエストを処理するPHP全般(PHP-FPM、Apacheのmod_phpなど)です。公式は、mod_phpのリスクが最も高いと見ています。
• 完全な対策は更新だけ: 公式は、完全な緩和策はなく、更新が唯一の安全な選択だと書いています。
• WordPressの問題ではなくPHPの問題: 公開されたのはPHP本体の修正です。WordPress本体やプラグインを更新するだけでは、PHP側の修正にはなりません。

WordPress公式も、2026年10月21日付で「Critical PHP Security Release」という告知を出しています(WordPress公式の告知)。

• WordPress本体の更新は不要: この件のために、WordPress本体の更新は必要なく、予定もない、と書かれています。更新が必要なのはPHPです。
• PHPをすぐ更新する: PHPの確認場所として、「ツール」→「サイトヘルス」→「情報」→「サーバー」が示されています。
• ホスティング会社にも確認する: ホスティング会社が、すでにPHPの更新やWAFルールの適用を進めている可能性があります。そのうえで、自分でも状況を確認し、必要なら速やかに更新するよう書かれています。
• 古いバージョンを自分で運用している場合: PHP 8.2より前のバージョンには、セキュリティ更新が出なくなっています。自分でホスティングを管理している場合は、更新の準備をする間、サーバーをオフラインにすることの検討が書かれています。

「php2shell」という呼び名は、研究者やセキュリティ会社の記事で使われる通称で、PHP公式の名称ではありません。また、2026年7月にあったWordPress本体の別の脆弱性「wp2shell」とは、別の件です(カゴヤのお知らせにある名前です)。

公式が書いていないこと、情報が分かれていること

次の点は、公式の発表だけでは分からないこと、または、情報源によって分かれていることです。断定せずに、確認できる範囲で書きます。

• 悪用の有無: PHP公式は、悪用されているとも、されていないとも書いていません。mod_phpについて「実証された攻撃」があると書いていますが、これは、実環境で悪用された、という意味とは別です。ほかの組織の発言は、分かれています。Patchstackは、提携するホスティング会社から悪用の試みの報告を受けたとし(ただし、侵害の確かな証拠はまだない、とも書いています)、CloudflareのCTOは初期の攻撃に触れた、とTenableが伝えています(Patchstack、Tenable)。一方、IPAは「悪用した攻撃を確認しているわけではありません」と書き、watchTowrも、野生での悪用は報告されていないとしています(IPA、watchTowr)。Patchstack、IPA、watchTowrの記載は、修正版の公開前のもので、公開後の更新は確認できていません。JPCERT/CCの注意喚起に、この件の項目が出ているかも、確認できていません。悪用の有無が分からなくても、公式は更新を強く勧めています。
• 8.1以前が影響を受けるか(個別の説明はない): アドバイザリの影響範囲は「8.2.35より前」などで、下限の記載はなく、8.1以前の扱いは個別には説明されていません。ただし、7.4、8.0、8.1向けにも、最小限の修正(ソースバックポート)をGitHubで公開しています。8.1以前はPHPプロジェクトからの更新がなくなっているので、ベンダー(OSやホスティング会社)に問い合わせるか、サポート中のバージョンに更新する、というのが公式の案内です。

設定の変更だけで足りるのか

「設定を変えておけば大丈夫」「セキュリティ対策を入れておけば大丈夫」と読める情報も、見かけるかもしれません。公式の記載の範囲で整理します。

• session.upload_progress.enabled=0 の設定: 公式は、この設定が塞ぐのはCVE-2026-109619の「確認された」セッションの経路だけで、ほかの経路は塞がないと書いています。php.ini、FPMのプール設定、サーバー設定のように、リクエストを解析する前に効く場所で設定し、すべてのワーカーを再起動する必要があります。ini_set() と .user.ini には頼れません。サーバー側の設定なので、契約によっては、ご自身では変えられない場合があります。
• ほかの緩和策: 公式は、リクエストのサイズを制限する方法なども挙げていますが、どれも攻撃経路を減らすだけで、「安全にはしない」と明記しています。
• WAF(Webアプリケーションファイアウォール): セキュリティ会社のTenableによると、Cloudflareは暫定のWAFルールを出しました。同社は「暫定にすぎない。PHPの更新を適用してほしい」としており、対象はCloudflare経由の通信だけです(Tenable)。
• メンテナンスモードや、サイト全体のアクセス制限: メンテナンスモードや、IP制限・BASIC認証が、今回の攻撃を防げるという公式の根拠は、確認できていません。サイト全体にかけると、訪問者も見られなくなります。

自分のサイトのPHPバージョンを確認する

PHPは、WordPressとは別に、サーバー側で動いているソフトウェアです。WordPress本体が最新でも、PHPのバージョンは別に確認する必要があります。

管理画面で見る

WordPressの管理画面から、PHPのバージョンを確認できます。WordPress公式の案内では、次の順に開きます(WordPress日本語サポート)。

1. 管理画面の「ツール」→「サイトヘルス」を開く
2. 「情報」タブを開く
3. 「サーバー」の項目を開き、PHPのバージョンを見る

「情報」タブは、情報を表示するためのもので、ここから設定は変えられません(サイトヘルス画面の説明)。画面の表示が違って見つからないときは、上の公式ページを開いて確認してください。

ホスティングの管理画面で見る

契約しているレンタルサーバーによっては、サーバーの管理画面でも、PHPのバージョンを確認・切り替えできます。たとえばエックスサーバーには、公式マニュアルがあります(新しいサーバーパネル向け、移行メンテナンス前のパネル向け)。ご自身のサーバーパネルに合うマニュアルを開いてください。

修正版の番号と比べる

PHP公式のサポート状況(サポート期間、サポート終了)と、今回の修正版を、あわせて表にしました。

バージョン	今回の修正版	公式の状況	セキュリティサポートの終了日
8.5	8.5.12	サポート中	2029年12月31日
8.4	8.4.27	サポート中	2028年12月31日
8.3	8.3.36	サポート中	2027年12月31日
8.2	8.2.35	サポート中	2026年12月31日
8.1	PHPプロジェクトからの更新なし	サポート終了(最終版 8.1.34)	2025年12月31日
8.0	PHPプロジェクトからの更新なし	サポート終了(最終版 8.0.30)	2023年11月26日
7.4	PHPプロジェクトからの更新なし	サポート終了(最終版 7.4.33)	2022年11月28日

7.3以前については、この記事では確認していないため、表に入れていません。

サイトヘルスに表示された番号が、自分の系統の「今回の修正版」以上であれば、公式が示した修正版のバージョンです。たとえば8.3系なら、8.3.36以上です。8.3.35のように、系統が同じでも、修正版より小さい番号は、修正版ではありません。

今回の脆弱性では、「8.3以上なら大丈夫」とは言えません。8.3系でも、8.3.36より前は更新が必要です。

WordPress公式のPHP更新の案内には、PHP 8.3以上であれば今は更新しなくてよい、という趣旨の記述があります。これは、新しい系統へ移るかどうかの話で、今回のような脆弱性の修正版を想定したものではない、というのが私の読みです(この点は公式の記述ではなく、この記事の解釈です)。

ただし、番号だけでは判断できない場合もあります。ホスティング会社やOSの提供元が、番号を変えずに、修正だけを当てていることがあるからです(後の節で説明します)。

私のサイトの場合

私のサイトで、サイトヘルスの「情報」→「サーバー」を確認したところ、PHPのバージョンは7.4.33でした。WordPressのバージョンは6.2.3です。

7.4.33は、PHP 7.4の最終版で、公式のサポートはすでに終わっています。上の表のとおり、7.4向けの公式の修正版(リリース)は出ていません。公式は、7.4向けにも最小限のソースバックポートをGitHubで公開していますが、説明では、ソースからビルドする人などに向けたものです。レンタルサーバーを使っている私のサイトに、これを自分で当てる使い方は、想定されていないようです。公式の案内に沿うなら、ホスティング会社に確認するか、サポート中のバージョンに更新する、という流れになります。

更新先を考えるうえでは、WordPressの互換表も関わります。WordPress 6.2はPHP 5.6から8.2までが対応で、8.3以降は対応外です(PHPとWordPressの互換表)。WordPressの最新版は7.1.3(2026年10月6日公開)です(WordPress.orgのリリース一覧)。つまり、8.2.35であれば、WordPress本体を更新しなくても、対応の範囲に入ります。ただ、8.2のセキュリティサポートは2026年12月31日に終わり、WordPress公式の推奨は8.3以上です。8.3以上にするなら、WordPress本体の更新も必要になりそうです。いまはまだ、PHPもWordPressも切り替えていません。切り替えるときの手順は、後の節で書きます。

なお、WordPress公式が「本体の更新は不要」と書いているのは、今回の脆弱性を直すために、WordPress本体の更新は出ない、という意味です。PHPの系統を変えるときに、WordPress本体の更新が必要になることとは、別の話です。

ホスティング会社の対応を確認する

自分で切り替えるのか、会社が更新するのか

PHPの更新方法は、ホスティング会社ごとに違います。WordPress公式も、自分で変えられる場合と、ホスティング会社に依頼が必要な場合があると案内しています(WordPress公式のPHP更新の案内)。この案内ページには、ホスティング会社ごとの手順の一覧へのリンクと、問い合わせ文の例が載っています。

大まかには、次の2つに分かれます。

• 管理画面でPHPのバージョンを切り替えられるサーバー: 修正版が出ているので、自分で切り替える作業が必要になる場合があります。
• 会社がサーバー側で更新するサーバー: 会社が更新を行うのを待つことになります。

どちらになるかは、契約しているサービスのお知らせやマニュアルで確認します。WordPress公式も、ホスティング会社が、すでにPHPの更新やWAFルールの適用を進めている可能性があるので、自分でも状況を確認するよう書いています。PHP公式は、Linuxのディストリビューション(OS)やLTSベンダーには、パッチが事前に渡されていたので、ベンダーの更新パッケージを確認するよう案内しています。

お知らせで見ること

ホスティング会社のお知らせでは、次の3点を見てください。

1. この脆弱性について、お知らせが出ているか
2. 会社が、いつ、どのバージョンへ更新する予定か(または、更新済みか)
3. 利用者側で必要な作業があるか

例として、カゴヤは2026年10月21日に、お知らせを出しています(カゴヤのお知らせ)。

• 元の告知: レンタルサーバー(PHP 8.2から8.5系)は、当日公開予定の修正版を確認したうえで、順次アップデートする予定とされていました。
• 18時20分の更新: 対象のプランが広がり、影響の有無を調査中で、新しい情報は同じページで案内する、と書かれていました。

修正版の番号や、利用者に求める作業は、書かれていません。18時20分より後の更新は、この記事の確認時点ではありませんでした。このページは更新される可能性があります。契約先の最新のお知らせをご確認ください。

エックスサーバーを含め、そのほかのレンタルサーバーも、各社の公式のお知らせでご確認ください。この記事の確認では、エックスサーバーの公式サイトで、今回の脆弱性への対応の告知を確認できていません。

問い合わせるときの文面の例

お知らせが見つからないとき、または自分のバージョンの扱いが分からないときは、問い合わせてみるのも一つの方法です。たとえば、次のような短い文面で聞けます。

契約中のサーバー(プラン名:○○)で、PHPのバージョン○○を使っています。2026年10月21日にPHP公式が修正版(8.5.12、8.4.27、8.3.36、8.2.35)を公開した脆弱性(CVE-2026-109618、CVE-2026-109619)について、次の点を教えてください。

1. 私が使っているバージョンに、修正を適用済みか、または適用する予定か(いつか)
2. 利用者側で必要な作業があるか
3. 私のバージョンがPHPのサポート終了版である場合の、対応方針

番号だけで「安全」「危険」を決めない

PHP公式は、8.1以前については、ディストリビューションやLTSベンダーが、修正を提供している場合があるので、ベンダーに問い合わせるよう案内しています。

Red Hatは、古いバージョンのソフトウェアに、修正だけを当てる「バックポート」という方法を説明しています。その公式ページは、パッケージのバージョン番号を見るだけでは、脆弱かどうかは分からない、と書いています。修正の有無は、アドバイザリに付けられたCVE番号で照合できるそうです(Red Hat)。

これはRed Hatの方針なので、ほかのホスティング会社やOSが同じ運用かどうかは、各社の案内を見るしかありません。問い合わせるときに、バージョン番号ではなく、CVE番号ごとの対応を聞くとよい理由は、ここにあります。

更新前にバックアップを取る

バックアップするもの

WordPress公式のバックアップの案内では、次の2つがそろって、はじめて完全に復元できるとされています(WordPress公式のバックアップ)。

• データベース: 投稿やコメントなどが入っています。ファイルをダウンロードするだけでは、含まれません。
• ファイル: WordPress本体、プラグイン、テーマ、画像などのアップロード、wp-config.php、.htaccess などです。

同じ案内に、いくつか目安が書かれています。

• 更新やアップグレードの前には、必ずバックアップを取る
• 取る順序は、データベースが先、ファイルがあと。復元するときは、ファイルが先、データベースがあと
• 少なくとも3から5世代を、複数の場所に残す
• 自動バックアップを使っていても、動いているかを確かめるために、ときどき手動でも取る

サーバー側の自動バックアップ

レンタルサーバーによっては、自動バックアップが用意されています。保存期間や復元の手順は、プランやサーバーパネルによって異なることがあります。エックスサーバーの場合は、公式マニュアルでご確認ください(自動バックアップの復元、MySQLの復元)。

WordPress公式は、バックアップを複数の場所に残すことを勧めています。サーバー側の自動バックアップに加えて、自分でも取っておくと安心です。

手動で取る、取れているか確かめる

プラグインのUpdraftPlusを使っている場合は、提供元の案内にある手動バックアップの手順は次のとおりです(UpdraftPlusのブログ)。画面の表記は英語のものです。日本語表示では違うことがあります。

1. 管理画面でUpdraftPlusを開き、「Backup / Restore」タブへ進む
2. 「Backup Now」ボタンを押す
3. ポップアップで、含める項目を確認する(通常はすべて選択)
4. ポップアップ内の「Backup Now」で開始する
5. 完了すると、「Existing backups」の欄に表示される

復元の手順は、提供元のドキュメントにあります。

取れているかを確かめるときは、最後に取れた日時、データベースとファイルの両方が含まれていること、保存先に実際に保存されていることを、順に見ていきます。

私のサイトの場合

私のサイトでは、UpdraftPlusで、Google Driveに自動でバックアップを保存しています。自動バックアップが動いて、成功していることは確認しました。

WordPress公式の案内にあるとおり、更新やアップグレードの前には、あらためてバックアップを取っておくのが基本です。自動バックアップが動いていても、切り替えの直前に手動で取る、という考え方もあります。

修正版が出たあと、PHPを切り替えて動作を確認する

この節では、PHPを更新または切り替えるときの手順を説明します。会社が更新を行うサービスでは、会社の案内に従ってください。

最初に見ること

次の順に確認します。

1. 自分のバージョンと、修正版の番号: 前の節の表のとおり、自分の系統の修正版以上かどうかを見ます。公式の発表は、php.netのニュースで確認できます。
2. ホスティング会社のお知らせ: 会社が更新するのか、自分で切り替えるのかを確認します。
3. 修正版がない系統の場合: 8.1以前は、PHPプロジェクトの更新がありません。公式の案内に沿って、ホスティング会社やOS提供元に、CVE番号ごとの対応を聞くか、サポート中のバージョンへの更新を考えます。

切り替える前の準備

古い系統から新しい系統へ移るときの準備として、WordPress公式のPHP更新の案内は、次の順を示しています(WordPress公式のPHP更新の案内)。

1. サイトのバックアップを取る
2. WordPress本体、テーマ、プラグインを最新にして、動作を確認する
3. 必要に応じて、「PHP Compatibility Checker」プラグインで互換性を調べる(誤検出や見落としがありうる、との注記があります)
4. PHPのバージョンを変更する

PHPの新しい系統では、古いプラグインやテーマが動かなくなることがあります。たとえば、PHP 7.4から8.0への移行では、each() や create_function() など、いくつかの関数が削除されました(PHPマニュアルの移行ガイド)。古いプラグインやテーマが、これらを使っていると、エラーになる可能性があります。

修正版が出ているのは、8.2から8.5です。そのうえで、PHP 8.2のセキュリティサポートは2026年12月31日に終わります。8.2.35の公式の告知も、移行の計画を勧めています。WordPress公式は8.3以上を推奨しているので、長く使うなら、8.3以上を選択肢に入れておくとよいと思います。

私のサイトのように、WordPressが古い場合は、前の節で触れた互換表のとおり、8.3以上に移る前に、WordPress本体の更新が必要になる可能性があります。

切り替えと、動作の確認

切り替えの操作は、ホスティング会社ごとに違います。エックスサーバーの場合は、先ほどの公式マニュアル(新しいサーバーパネル向け、移行メンテナンス前のパネル向け)で手順を確認してください。反映にかかる時間の目安は、公式マニュアルでご確認ください。切り替えたら、すぐにページを開いて確認してください。

切り替えたあとは、例として次のページや機能を、一つずつ開いて確認します。

• トップページ
• 記事のページ
• 管理画面へのログイン
• お問い合わせフォームなど、入力して送信する機能
• 画像の表示

予約や決済など、サイトにほかの機能がある場合は、それも確認します。

画面が真っ白になったとき、エラーが出たとき

切り替えのあとで問題が出たときは、まずPHPのバージョンを元に戻すことを、WordPress公式は案内しています。元に戻すには、ホスティング会社に依頼が必要な場合があります。そのうえで、バックアップから復元します(WordPress公式のPHP更新の案内)。元に戻した間は、元のバージョンで動いているので、今回の修正版にはなっていません。原因を直して、もう一度切り替える流れになります。

原因の手がかりについて、WordPress公式のよくあるエラーの案内には、次のことが書かれています(よくあるエラー)。

• 画面が真っ白: 原因の候補として、プラグインの互換性が挙げられています。管理画面に入れるなら、すべてのプラグインを無効にして、一つずつ有効にして調べます。入れないときは、FTPで wp-content/plugins のフォルダ名を plugins_old に変えます(すべてのプラグインが無効になります)。テーマが原因のときは、デフォルトのテーマに切り替えます。
• 「致命的なエラー」の表示: 管理者のメールアドレスに、通知が届きます。原因の候補には、プラグインやテーマの競合、対応していないPHPのバージョン、メモリの上限、ファイルの破損などがあります。
• リカバリーモード: 致命的なエラーのメールには、リカバリーモードに入るためのリンクが付いています。エラーの原因になっているプラグインやテーマが、そのブラウザだけで一時的に停止されます(WordPress開発チームのブログ)。

エラーの内容をログに残して調べる方法もあります。ただ、WordPress公式は、公開中のサイトで WP_DEBUG を使うことを勧めていません(デバッグの案内)。使う場合は、ステージングやバックアップを用意して、画面には表示せず、ログに保存する設定にします。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

この3行は、wp-config.php の「/* That's all, stop editing! ... */」の行より前に書きます。サイトヘルスは、デバッグのログが有効になっていると、ログが公開される可能性があるとして警告します。確認が終わったら、元に戻してください。

切り替え後の点検と、今後の情報の追い方

切り替え後に見ること

切り替えたあとの数日は、次のような点を見ておくと安心です。

• サイトヘルスの指摘や、管理者のメールアドレスに届くエラーの通知がないか
• お問い合わせフォームなど、入力する機能が動いているか

あわせて、身に覚えのない変化がないかも確認します。WordPress公式の「サイトがハッキングされたとき」のFAQでは、乗っ取りを示す兆候の例に、新しいユーザーの作成など、許可していない動作に気づいたことが挙げられています(WordPress公式のFAQ)。管理者のユーザー一覧に、心当たりのないアカウントがないかを見ておきます。

WordPress本体のファイルについては、WP-CLIの wp core verify-checksums が、公式のチェックサムと比較して確認します。ただし、対象はWordPress本体のファイルです(WP-CLIのドキュメント)。

今回の脆弱性について、侵入されたかどうかを判定する公式の方法は、確認できていません。

疑わしいと感じたときは、WordPress公式のFAQにある流れが参考になります。

1. いつ、何を見たか、直近の変更を記録する
2. ホスティング会社に連絡する
3. パスワードを変更する(FTP/SFTP、管理画面、ホスティングの管理画面、MySQL)
4. 掃除の前に、もう一度バックアップを取る

また、セキュリティ会社のFlatt Securityは、ログが記録されているか、改ざんされにくい形で保全されているかの確認を勧めています(Flatt Securityの記事)。

サポート期限の見方

切り替えた先のバージョンにも、サポートの終了日があります。前の節の表のとおり、8.2は2026年12月31日、8.3は2027年12月31日です。次の期限が分かるように、カレンダーなどに入れておくと、次の移行を急がずに済みます。

情報の追い方

状況が変わる話題なので、次の情報源を、確認する先として覚えておくと便利です。

• PHP公式のニュース: php.net のニュース一覧。勧告や、リリースの告知が載ります。
• IPAの注意喚起: IPAのページ。追記すべき情報があれば、その都度ページを更新する、と書かれています。
• 契約しているホスティング会社のお知らせ: 更新の予定や、利用者に必要な作業が載ります。
• WordPress公式のニュース: WordPress公式の告知と、ニュース一覧。

この記事の情報の日時と、公開後に変わること

この記事は、2026年10月21日の夜(日本時間)に、PHP公式やWordPress公式などのページを確認して書きました。公式の勧告のページに公開時刻の記載はないため、時刻は書いていません。次の項目は、時間が経つと変わる可能性があります。公式の最新情報をご確認ください。

• PHP公式の勧告: 追記される場合があります(悪用の有無、影響範囲、緩和策など)。
• 悪用の状況: 本文で挙げた各社の発言には、修正版の公開前のものが多く含まれます。公開後に、変わる可能性があります。
• IPA・JPCERT/CC: IPAのページは、事前の注意喚起のままでした。追記や、新しい注意喚起が出ていないか、ご確認ください。
• ホスティング会社の対応: 各社のお知らせで確認してください。例に挙げたカゴヤのお知らせは、2026年10月21日18時20分の更新が最新でした。
• 8.1以前向けのバックポート: GitHubのブランチで公開されています。公式のリリースになるかどうかは、確認できていません。
• WordPressの最新版と推奨PHP: 最新版は7.1.3(2026年10月6日公開)、推奨PHPは8.3以上でした。WordPress公式の告知も、更新される可能性があります。
• PHPのサポート期間: 8.2のセキュリティサポートは2026年12月31日に終わります。

---

更新履歴

日時	内容
2026年10月21日 夜(日本時間)	公開。PHP公式が修正版を公開したあとの情報