2026年10月21日の夜、PHPの脆弱性(ぜいじゃくせい)を直した修正版が公開されました。

PHPは、WordPressを動かしているプログラミング言語の一つです(WordPress用語集)。脆弱性は、ソフトウェアに見つかった、セキュリティ上の弱点のことです(IPA)。

「PHPの脆弱性のニュースは見たけれど、自分のWordPressで何をすればよいのか分からない」。この記事は、そう感じた方に向けて書きました。

内容は、WordPressでサイトを運営している私が、この件でやったことの記録です。私はPHPやサーバーの専門家ではありません。一人の運営者として、順番に書きます。

この記事の情報は、2026年10月22日 20:55(日本時間)に、公式の情報で確認しました。

先に、私の受け止め方を書いておきます。騒ぎが落ち着いたあとで振り返ると、今回の出来事は、避難訓練のようでした。「いざというとき、自分は何を確認すればよいのか」を、一通り体験できたからです。これは、あとからの私の感想です。

この記事では、次のことを書きます。

  • 私が、いつ気づいて、何をしたか
  • 公式の情報で分かっていること(出典のリンクつき)
  • 次にWordPressを見直すときの、確認の順番と、見直しの目安(最後の見出しにあります)
目次 [ close ]
  1. PHPの脆弱性に気づいた夕方、私のサーバーはもう閉じていた
    1. 公式の経緯
  2. サーバーが開いたあと、まず自分のPHPのバージョンを確認した
    1. WordPressでPHPのバージョンを確認する方法
    2. 放置していた理由
  3. PHPを上げる前に、バックアップを取った
  4. PHPを7系から8系に上げたら、私のサイトは崩れなかった
    1. 7系の修正について
  5. 不要なプラグインとサイトを減らし、見せる用のサイトにはIDとパスワードをかけた
    1. プラグインを全部見直して、いらないものを削除した
    2. 運用していない空き家のサイトを1つ削除した
    3. 削除できないテスト用サイトには、IDとパスワードをかけた
  6. サイトヘルスが「良好」になった
  7. あとで振り返ると避難訓練のようだった。確認の順番と見直しの目安
    1. 避難訓練のようだった、と感じた理由
    2. 私が見聞きした範囲では
    3. 次に見直すときの、確認の順番
    4. 見直しの目安
    5. 情報の確認日時と、公式の情報源

PHPの脆弱性に気づいた夕方、私のサーバーはもう閉じていた

10月21日の夕方に気づき、夜に修正版が公開され、22日の朝と昼はまだサーバーが閉じていて、22日の午後に開いたという時間の流れを示す図

私が気づいたのは、10月21日の夕方でした。そのとき、私が契約しているサーバーは、もう閉じていました。

サーバーは、ホームページのデータやプログラムを置いて、インターネットに公開するためのコンピューターです。サイトを公開するための基盤を、通常は有料で提供している会社があります。WordPress公式の用語集(英語)では「Hosting provider」(ホスティング会社)と呼ばれています(WordPress用語集)。この記事では、そうした会社を「レンタルサーバー会社」と書きます。

ホームページを閉じるにも、サーバーの管理画面に入る必要があります。でも、入れません。何もしようがありませんでした。

夜は、各所が一斉にシャッターを下ろしているような、「強制閉店みたいな感じ」がしました。あとで、各社が修正のために作業していた時間帯だったのだ、と理解しました。ただ、私のサーバーが閉じていた本当の理由は、確認できていません。

翌22日の朝も、昼も、サーバーはまだ閉じていました。午後過ぎに開いたので、自分のサイトの設定を確認しました。

公式の経緯

あとから公式の情報を読んで、経緯を整理しました。時刻は、日本時間を主に書きます。UTCは、世界で共通に使われる時刻の基準です。日本時間は、UTCより9時間進んでいます。

  • もとの予定: PHPに関わる団体、PHP Foundationのブログによると、もとは10月22日の23:00(UTCでは14:00)に公開する予定でした(PHP Foundation)。
  • CVE番号が先に出回った: 10月21日の0:00ごろ(UTCでは10月20日の15:00ごろ)から、CVE番号が掲示板やSNSに出回りました。CVE番号は、脆弱性を一つずつ見分けるための、共通の識別番号です(IPA)。技術的な詳細は漏れていない、とも書かれています。
  • 前倒しと予告: そこで、公開を1日早めた、と説明されています。予告は、10月21日の朝4時30分ごろ(UTCでは10月20日の19:30)に出されました(PHP Foundation)。予告の内容は、10月21日の23:00に公開する、というものです(PHP公式のお知らせ)。
  • 公開: 修正版は、10月21日の夜11時に公開される予定とされ、同じ夜に公開されました。夜の10時台に、詳しい注意書き(勧告)がGitHubで先に公開された記録もあります(GitHubの勧告)。
  • 内容: 脆弱性は2件です。PHP公式は、どちらも「重大(critical)」とし、ログインなしで、外からサーバー上でプログラムを実行されうる種類だと説明しています。修正版の番号は、8.5.12、8.4.27、8.3.36、8.2.35です(PHP公式のお知らせ)。

この修正版のことを、この記事では「パッチ(修正版)」とも呼びます。弱点を直すために配られる、更新用の版のことです。今回は、PHPの新しい版がそれにあたります。

WordPress公式は、この件でWordPress本体の更新は必要なく、予定もない、と書いています。更新が必要なのは、WordPressではなくPHPです。PHPのバージョンの確認方法と、レンタルサーバー会社への確認も案内されています(WordPress公式のお知らせ)。

サーバーが開いたあと、まず自分のPHPのバージョンを確認した

WordPressの管理画面から、ツール、サイトヘルス、情報タブ、サーバーの順に進むと、PHPのバージョンが見られる道すじを示す図

サーバーが開いたので、最初にやったのは、自分のPHPのバージョンの確認です。

バージョンは、PHPの版を表す番号です。「7.4」「8.3」のように、番号で版が分かれています。版ごとに、サポートが終わる日が決まっています(PHP公式の対応表)。この記事では、7で始まる版をまとめて「7系」、8で始まる版をまとめて「8系」と呼びます。

確認すると、私のPHPは7系でした。7.4.33です。7.4のサポートは、2022年11月28日に終わっています(PHP公式)。

WordPress公式が推奨するPHPは、8.3以上です。7.4以上でも動きますが、古い版は、公式のサポートが終わっているため、セキュリティ上の問題が出るおそれがある、と案内されています(WordPress公式の動作環境)。

WordPressでPHPのバージョンを確認する方法

WordPressの管理画面では、サイトヘルスから確認できます。サイトヘルスは、WordPressがサイトの状態を点検して、結果を教えてくれる画面です(WordPress公式)。

WordPress公式の案内では、「ツール」の「サイトヘルス」を開き、「情報」タブの「サーバー」の項目に、PHPのバージョンが出ます(WordPress公式のお知らせ)。多くのレンタルサーバー会社は、自社の管理画面にも表示している、と書かれています。画面の表記は、環境によって違うことがあります。

PHPのバージョンとWordPressのバージョンは、別のものです。WordPress本体が最新でも、PHPは別に確認します。

放置していた理由

正直に書くと、私は7系を、ずっと放置していました。理由は、バージョンを上げるとサイトが崩れるのが心配だったからです。

WordPress公式も、PHPを更新しても問題にならないはずだが、保証はできない、と案内しています。更新の前には、バックアップを取ることが勧められています(WordPress公式のPHP更新の案内)。同じ案内には、新しいPHPは速く、古い版には最新のセキュリティ機能がない、とも書かれています。

PHPを上げる前に、バックアップを取った

PHPを上げる前にデータベースとファイルのバックアップを取り、PHPを上げてから、サイトの表示を確認するという作業の順番を示す図

バージョンを上げる前に、バックアップを取りました。バックアップは、万一に備えて取っておく、サイトの控えです。取り方の細かい話は、ここでは書きません。

WordPress公式のバックアップの案内では、WordPressのサイトのバックアップには、データベース(記事やコメントなどが入っている場所)とファイルの2つがあり、完全に戻すには両方が必要だとされています。そして、更新の前には必ずバックアップを取ることが、目安として書かれています(WordPress公式のバックアップの案内)。

PHPの更新の案内でも、問題が起きたときに、今の状態に戻せるように、バックアップを取ることが勧められています。戻すときには、PHPのバージョンも、レンタルサーバー会社に戻してもらう必要が出る場合がある、とも書かれています(WordPress公式のPHP更新の案内)。

私は、バックアップを取ってから、PHPを上げました。更新の前にバックアップ。これは、次の人にも、そのまま伝えたいことです。

PHPを7系から8系に上げたら、私のサイトは崩れなかった

PHP 7.4.33から PHP 8.3.36 へ矢印で引っ越しする図。下に「サイトは崩れなかった」と書かれている。

バックアップのあと、サーバーの設定で、PHPのバージョンを上げました。7.4.33から、8.3.36です。7系から8系へ、ひとつ飛びで上げました。

上げたあと、サイトを見て、崩れていないかを確認しました。私のサイトは、崩れませんでした。ほっとしました。確認は、一瞬、見て回った程度です。これは私のサイトの場合の結果で、どのサイトでも崩れないという意味ではありません。

8.3.36は、今回の公式の修正版(8.3系)の番号と、同じです(PHP公式のお知らせ)。8.3は、WordPress公式の推奨(8.3以上)にも合っています。PHP公式の対応表では、8.3のセキュリティ修正は、2027年12月31日まで続く予定です(PHP公式の対応表)。

今回の件については、ひとまず大丈夫かな、と私は思っています。これは私の感想です。これからは、PHPのバージョンアップに、ついていこうと思います。

7系の修正について

私は、最初は8系にだけ修正が入ると受け取りました。そのあと、私が見た範囲では、7系にも修正が出たようでした。

公式の案内を確認すると、次のとおりです(PHP公式のお知らせ)。

  • 公式の修正版は、8.2〜8.5向けです。
  • 8.1以前は、PHPプロジェクトからの更新が出なくなっています。OSの提供元や、長期サポート(LTS)を提供する会社が、独自に修正を出している場合があります。そのため、そうした会社に確認するか、サポート中の版に上げるよう案内されています。
  • 7.4、8.0、8.1向けにも、最小限の修正がGitHubで公開されました。ただし、PHPを自分で組み立てて使う人や、長期サポートの会社を使えない人のためのものです。

私が見た「7系への修正」が、このどれにあたるのかは、確認できていません。自分が使っているレンタルサーバー会社が7系にどう対応しているかは、その会社のお知らせで確認するのがよいと思います。

不要なプラグインとサイトを減らし、見せる用のサイトにはIDとパスワードをかけた

左に「不要なプラグインを整理」と「使っていないサイトを削除」、右に「見せる用のサイトに、ID・パスワードの入口」を置いた対比図。

PHPを上げたあと、ほかにも見直しました。

プラグインを全部見直して、いらないものを削除した

プラグインは、WordPressに機能を足す部品です(WordPress公式)。私は、入れているプラグインを、全部チェックしました。

その中に、過去に脆弱性が指摘されたプラグインがありました。今回のPHPの件とは、別の話です。調べてみると、更新で、すでに修正されていました。そのことを確認できたので、ほっとしました。プラグインの名前や数は、ここでは書きません。

そして、使っていないプラグインは削除しました。プラグインが原因で、画面が真っ白になることがあるからです。WordPress公式も、画面が真っ白になる原因の候補に、プラグインの互換性の問題を挙げています(よくあるエラー)。

不要なプラグインは、プラグインの画面で「無効化」してから「削除」する、と案内されています(WordPress公式)。

運用していない空き家のサイトを1つ削除した

もう一つ、運用していない「空き家」のようなサイトが、1つありました。使っていないので、削除しました。

削除できないテスト用サイトには、IDとパスワードをかけた

どうしても削除できないサイトが、1つあります。ライブ配信などで見せるための、テスト用のWordPressサイトです。

このサイトは、サーバーの管理画面から、サイト全体にアクセス制限をかけました。IDとパスワードを入れないと開かない設定です。お客様専用ページのような感覚です。

この仕組みは、BASIC認証と呼ばれます。サーバーがIDとパスワードを求め、ブラウザーが入力画面を出します(MDN)。MDNは、BASIC認証は暗号化ではないので、通信を暗号化する仕組み(HTTPS)と組み合わせて使う必要がある、と書いています。

ここで、正直に書いておきます。私は、これでリスクが半分になった気がしています。でも、これは体感です。数字の根拠はありません。

また、このアクセス制限が今回のPHPの脆弱性にどれだけ効くのかは、確認できていません。PHP公式は、完全な対策は更新だけだと書いています(PHP公式のお知らせ)。IPAは、更新が終わるまでの暫定対策として、アクセス制限などを検討するよう案内しています。ただし、BASIC認証を名指ししたものではありません(IPAの注意喚起)。

そのため私は、これを「対策」とは考えていません。見せる用のサイトなので、見られる人を限ることにした、という私の判断です。

サイトヘルスが「良好」になった

サイトヘルスの画面に「良好」と表示されている。ただし、それは点検項目の結果であり、今回の脆弱性が直ったという意味ではない、と吹き出しで注意している図。

一通り終えて、サイトヘルスを見ました。私の画面では、全体の状態が「良好」と表示されていました。

サイトヘルスは、WordPressの健康診断のような画面です。公式の日本語の案内では、結果は「致命的な問題」「おすすめの改善」「問題のない項目」に分けて表示されます(WordPress日本語サポート)。古いPHPを使っているときに、更新を促す指摘が出る例も、公式に載っています(WordPress公式のサイトヘルス)。

ただし、私の画面の「良好」は、点検項目の結果が良好だった、という意味です。今回の脆弱性が直った、という意味ではありません。サイトヘルスの「良好」だけで、今回の件が片づいたとは言えません。

私が今回の件を「ひとまず大丈夫かな」と思ったのは、サイトヘルスが理由ではありません。公式の修正版と同じ番号の8.3.36に、PHPを上げたからです。サイトヘルスは、点検の目安の一つとして使っています。

なお、サイトヘルスの「情報」の画面は、情報を表示するだけで、ここから設定は変えられません(WordPress公式のサイトヘルス)。PHPのバージョンは、多くの場合、レンタルサーバー会社の管理画面などで変えます。会社によっては、サポートへの依頼が必要なことがあります。

あとで振り返ると避難訓練のようだった。確認の順番と見直しの目安

次に見直すときの確認の順番を示すチェックリスト。1お知らせを見る、2バージョン確認、3バックアップ、4PHPを上げる、5プラグイン見直し、6アクセス制限を考える、7サイトヘルスを見る、の7ステップが矢印でつながっている。

避難訓練のようだった、と感じた理由

あとで振り返ると、今回の出来事は、避難訓練のようでした。

サーバーが閉じていて、何もできない夜がありました。サーバーが開いたら、バージョンを確認して、バックアップを取り、PHPを上げました。プラグインとサイトを整理して、見せる用のサイトにIDとパスワードをかけました。やるべきことを、順番にやる流れを、体験できました。

これは、あとからの私の感想です。今回の件を軽く見ているわけではありません。PHP公式もWordPress公式も、PHPの更新を案内しています。

またこういうことは、起きると思います。ただ、一度やってみたので、次は落ち着いて動けそうです。

何事もない状態を続ける仕事は、大変だと思いました。何もないことは、目立ちません。でも、誰かが守ってくれているから、何もない日が続くのだと感じました。

私が見聞きした範囲では

私が見聞きした範囲では、今回、大きな攻撃の話は聞いていません。ただ、これは私の範囲の話です。

公式の記述は、次のとおりです。誰の見解かを分けて書きます。

  • PHP公式: 勧告には、ある方式(mod_php)で、ログインなしの通信だけで攻撃が成り立つことが実証されている、と書かれています。一方で、実際に悪用された、という記述は、PHP公式のお知らせにはありません(PHP公式のお知らせ)。
  • PHP Foundation: PHPのセキュリティチームが、公開の時点で、動作する攻撃コードを確認できなかった、と書いています。一方で、公開の前に、あるセキュリティ会社の動画が誤って公開され、攻撃を試すコードの作成を早めた、とも書いています(PHP Foundation)。
  • IPA: 修正版の公開前に出した事前の注意喚起(10月21日掲載)で、「現時点で、IPAが悪用した攻撃を確認しているわけではありません」と書いていました(IPA)。10月22日の注意喚起には、悪用の観測についての記述はありません(IPAの注意喚起)。
  • Cloudflare: 自社の顧客に向けた攻撃のトラフィックを観測した、と書いています。これは、Cloudflare自身の観測です(Cloudflare)。

どれも、書かれた時点の情報です。最新の状況は、各ページでご確認ください。

次に見直すときの、確認の順番

私がやった順番を、読者の方向けに、チェックリストにしました。

  1. お知らせを見る。 PHP公式、WordPress公式、契約しているレンタルサーバー会社のお知らせを見ます。サーバーが閉じているときは、開くのを待ちます。
  2. PHPのバージョンを確認する。 「ツール」の「サイトヘルス」の「情報」タブ、「サーバー」の項目で見られます。レンタルサーバー会社の管理画面でも見られます。
  3. バックアップを取る。 更新の前に取ります。データベースとファイルの両方が必要です。
  4. PHPのバージョンを上げる。 手順は、レンタルサーバー会社ごとに違います。自分の会社のヘルプを見てください。上げたら、サイトが崩れていないか、見て確認します。
  5. プラグインを見直す。 更新が止まっているもの、使っていないものを探します。使っていないものは、「無効化」してから「削除」します。
  6. 見せる人を限りたいサイトは、アクセス制限を考える。 PHP公式は、完全な対策は更新だけだと書いています。IPAは、更新までの暫定対策として、アクセス制限などを案内しています。私のBASIC認証の効果は、確認できていません。
  7. サイトヘルスを見る。 点検の目安の一つとして使います。「良好」でも、安全の保証ではありません。

見直しの目安

目安は、公式が示しているものと、私の考えとを、分けて書きます。

公式の情報に基づく目安

  • PHPのサポート期間。 PHPの各版は、公開から2年は通常のサポート、そのあと2年はセキュリティ修正のみ、とされています(PHP公式の対応表)。2026年10月22日の時点で、8.2は2026年12月31日、8.3は2027年12月31日にサポートが終わる予定です。自分の版の終了日を、一度見ておくと安心です。
  • WordPressの推奨PHP。 8.3以上です(WordPress公式の動作環境)。
  • 更新の前のバックアップ。 頻度の目安として、更新が少ない小規模なサイトなら週1回、更新が多いなら毎日、とされています。3〜5世代を残すことも勧められています(WordPress公式のバックアップの案内)。取れたバックアップが、使える状態かを確認することも、大切だとされています(WordPress公式)。
  • WordPress本体とプラグインの更新確認。 WordPress公式のハウスキーピングに、本体は3〜6か月ごと、プラグインも3〜6か月ごとに、更新を確認する目安が書かれています(WordPress公式)。
  • サポート終了の時期を、先に知っておく。 総務省も、提供元が公表するサポート終了の時期を事前に把握して、計画的に更新するよう呼びかけています(総務省)。

私の考え(公式の目安ではありません)

  • PHPの見直し間隔について、公式の目安は確認できていません。
  • 私は、PHPのバージョンを、放置しないようにします。新しい版にはついていこうと思います。
  • 次に何かあったら、最初にPHPのバージョンを確認して、更新の前にバックアップを取ります。
  • 今度は、サイトに誰が入ってきたかも、見てみたいと思っています。まだ見ていません。
  • 見直しの間隔は、自分で決めておくと迷いません。たとえば、年に一度、PHPのサポート終了日を見る、のように決めておく方法があります。これは一例で、公式の目安ではありません。

情報の確認日時と、公式の情報源

この記事の情報は、2026年10月22日 20:55(日本時間)に、公式の情報で確認しました。情報は変わることがあります。公式のページで、最新の情報を確認してください。

この記事の中の「私の場合」は、私のサイトでの体験です。すべてのサイトで、同じ結果になるとは限りません。

使った公式の情報源は、次のとおりです。