【2026年10月21日】PHPの重大な脆弱性|WordPress利用者が今すぐ確認したいこと・ConoHa WINGで実際に行った対応

※この記事は2026年10月22日時点の情報をもとにした途中経過です。レンタルサーバー各社の対応状況は随時変わっています。最新情報は各社の公式発表もあわせてご確認ください。

総理からも対応が呼びかけられる事態になっています

2026年10月21日、Webサイトを動かすために広く使われている「PHP」に、重大なセキュリティ上の問題が見つかったとして注意喚起が出ました。

IPA(情報処理推進機構)から対応に向けた事前準備が呼びかけられただけでなく、同日夜には高市総理からも、自身のXを通じて「大至急のお願い」として対応が呼びかけられています。

個別のソフトウェアの問題について総理から直接こうした発信が行われるのは珍しく、今回は普段のWordPressやプラグインのアップデートとは少し違うものとして、私も管理しているサイトの確認を始めました。

また、すぐに修正することが難しい場合には、一時的にWebサイトを停止することもリスクを下げる方法の一つとして示されています。

とはいえ、

「PHPって何?」

「WordPressを使っているけど、自分にも関係あるの?」

「結局、何をすればいいの?」

という方も多いと思います。

私も普段WordPressでホームページを制作・管理していますが、今回まず知りたかったのは、

「今、自分が管理しているサイトに対して何ができるのか?」

ということでした。

この記事では難しい技術的な説明よりも、

  • 何を確認すればいいのか
  • どこを操作すればいいのか
  • 安全だと確認できない間はどうしたのか
  • どこまでやれば、ひとまず待てる状態になるのか

を、できるだけ分かりやすくまとめます。

まだ完全に解決したわけではありませんが、同じようにホームページやブログを管理している方の参考になればと思い、途中経過も含めて公開します。

時間がない方は、まずこの3つを確認してください

とりあえず今できることだけでもやっておきたい場合は、

① WordPressからPHPのバージョンを確認する

② レンタルサーバーのWAFがONになっているか確認する

③ 安全が確認できない場合は、必要に応じてBasic認証でサイトを一時的に閉じる

まずはこの3つです。

この記事の後半で、ConoHa WINGを例に実際の操作手順まで紹介します。

そもそもPHPって何?

かなり簡単に言うと、PHPはWordPressを動かすために使われている仕組みの一つです。

WordPress本体とは別物ですが、WordPressを動かす土台のようなものだと思ってもらえれば大丈夫です。

今回問題が見つかったのは、WordPressそのものではなく、このPHPです。

そのため、

「WordPressを最新版にしたから大丈夫」

「プラグインを全部更新したから大丈夫」

というわけではありません。

ここが今回、少し分かりにくいところでした。

今回はPHPの修正版が公開されています

今回の問題に対応したPHPの修正版として、

  • PHP 8.2.35
  • PHP 8.3.36
  • PHP 8.4.27
  • PHP 8.5.12

が公開されています。

ここで注意したいのが、

「PHP 8.2を使っているから大丈夫」ではない

ということです。

同じPHP 8.2でも、

「8.2.31」

と

「8.2.35」

では違います。

今回のような場合は「8.2」までではなく、その後ろの細かい数字まで確認する必要があります。

① まず自分のPHPバージョンを確認する

WordPressを使っている場合は、管理画面から確認できます。

WordPress管理画面で、

「ツール」

↓

「サイトヘルス」

↓

「情報」

↓

「サーバー」

と進みます。

その中に、

「PHPバージョン」

という項目があります。

例えば、

PHP 8.2.31

のように表示されます。

今回、私が管理しているConoHa WING上のサイトを確認したところ、

PHP 8.2.31

となっていました。

今回公開された8.2系の修正版は「8.2.35」です。

そのため、少なくともWordPress上に表示されている数字だけを見ると、まだ公式の修正版にはなっていませんでした。

「PHP 8.2」と表示されていても安心とは限らない

ConoHa WINGの管理画面では、

「PHP 8.2」

「PHP 8.3」

といった形で表示されています。

でも実際には、その中にさらに、

8.2.31

8.2.35

といった細かいバージョンがあります。

そのため、レンタルサーバーの管理画面だけでなく、WordPressのサイトヘルスから実際のバージョンを確認するのがおすすめです。

ただし、ここでもう一つ注意があります。

レンタルサーバー会社によっては、表示されているバージョン番号を変更せず、問題になっている部分だけを修正する場合もあります。

そのため、

「数字が古い=絶対に未対応」

とも言い切れません。

最終的には、利用しているレンタルサーバー会社の公式発表も確認する必要があります。

レンタルサーバー会社によって対応状況が違う

今回、各レンタルサーバー会社が順次対応を進めています。

例えば、さくらインターネットでは、PHPのバージョンアップを目的とした緊急メンテナンスが実施され、対応完了と案内されています。

エックスサーバーなどでも対応が進められています。

一方で、私が利用しているConoHa WINGでは、この記事を書いている時点で、WordPressから確認したPHPのバージョンは「8.2.31」のままでした。

そのため私は、

「ConoHa側で対応済みだと確認できるまでは、安全だと自己判断しない」

という方針にしています。

この部分については、ConoHa側から新しい発表があればこの記事にも追記します。

自分でPHPを最新版に変更した方がいい?

ここは注意してください。

例えば現在PHP 8.2を利用しているからといって、

「PHP 8.5が一番新しいから8.5に変更しておこう」

と安易に変更するのはおすすめしません。

WordPress本体だけでなく、利用しているテーマやプラグインが新しいPHPに対応していない可能性があるためです。

場合によっては、サイトが正常に表示されなくなることもあります。

今回のような場合、

PHP 8.2.31を利用していた環境が、

レンタルサーバー会社側の対応によって、

PHP 8.2.35

になるのであれば、その方が影響を抑えやすいです。

よく分からない状態でPHPのバージョンを大きく変更するのではなく、まずはレンタルサーバー会社の対応状況を確認してください。

② ConoHa WINGのWAFがONになっているか確認する

次にWAFを確認しました。

WAFは、Webサイトに対する不正なアクセスを検知・防御するための仕組みです。

ConoHa WINGの場合は、

「WING」

↓

「サイト管理」

↓

対象のドメインを選択

↓

「サイトセキュリティ」

↓

「WAF」

と進みます。

WAFがONになっているか確認してください。

OFFの場合はONにしておきます。

ただし、

WAFをONにすれば今回のPHPの問題自体が修正されるわけではありません。

あくまで、PHPそのものが修正されるまでの間、サイトへの防御を強くするものだと考えています。

③ 安全が確認できるまでサイトを一時的に閉じる

今回私は、

「安全だと確認できるまで、一旦外部からアクセスできない状態にしておこう」

と判断したサイトについて、Basic認証を設定しました。

Basic認証とは、ホームページを表示する前にユーザー名とパスワードの入力を求める仕組みです。

正しい情報を入力しなければ、その先のWordPressにアクセスできません。

ConoHa WINGでは「ディレクトリアクセス制限」という機能を使います。

ConoHa WINGでサイト全体にBasic認証を設定する方法

ConoHa WINGにログインします。

「WING」

↓

「サイト管理」

↓

対象のドメインを選択

↓

「サイトセキュリティ」

↓

「ディレクトリアクセス制限」

と進みます。

右側にある、

「+ディレクトリ」

を押します。

サイト全体を対象にする場合は、

の後ろに表示されている入力欄には何も入力せず、そのまま保存します。

つまり、特定のフォルダだけではなく、ドメインの一番上から制限をかけます。

その後、作成されたディレクトリを開いて認証用のユーザーを追加します。

Basic認証のユーザー名とパスワード

目安として、

ユーザー名:12〜16文字程度

パスワード:16〜20文字以上

にしました。

できるだけランダムなものにします。

例えば、

ユーザー名

u7Kp4N2xQ9Lm

パスワード

T8#vQ2!mL9@xR4$kP7

くらいです。

ユーザー名についても、

「admin」

会社名

ドメイン名

など、推測されやすいものは避けた方が安心です。

また、

  • WordPress管理画面と同じパスワード
  • メールと同じパスワード
  • 他のサービスで使用しているパスワード

などは使い回さないようにします。

Basic認証が本当に設定できたか必ず確認する

設定しただけで終わらず、実際に動いているか確認します。

Chromeなどのブラウザで、

シークレットモード

を開きます。

そこから、

へアクセスします。

ホームページがそのまま表示されず、

「ユーザー名」

「パスワード」

の入力画面が先に表示されればBasic認証が動いています。

念のため、

にもアクセスします。

WordPressのログイン画面より先にBasic認証が表示されれば、サイト全体に設定できていると判断しやすいです。

WordPressのメンテナンスモードではダメなの?

最初は私も、

「WordPressをメンテナンスモードにすればいいのでは?」

と思いました。

ただ、WordPressのメンテナンスモードは、訪問者にメンテナンス画面を表示していても、その裏側ではWordPressやPHPが動いています。

今回はPHP自体の問題です。

そのため私は、

「WordPressにアクセスする前の段階で止める」

ために、サーバー側のBasic認証を利用しました。

Basic認証をかける場合の注意点

当然ですが、Basic認証を設定すると一般の方もホームページを見ることができなくなります。

そのため、

  • お問い合わせフォーム
  • Web予約
  • 商品購入
  • 広告からのアクセス
  • 外部サービスとの連携

なども影響を受ける可能性があります。

長期間そのままにするものではなく、今回はPHPの対応状況が分かるまでの一時的な措置として使用しています。

サイトの役割によっては簡単に止められない場合もあるため、その場合は制作会社やサーバー会社に相談した方がいいと思います。

実際にアクセスログも確認してみました

今回、念のため管理しているサイトのアクセスログやエラーログも確認しました。

すると、

.env

phpinfo.php

credentials.json

cache.php

wp-admin/install.php

などを探しているアクセスが複数ありました。

見慣れないURLが大量に並んでいるので、初めて見るとかなり怖く見えます。

ただし、

「こうしたアクセスがあった=サイトに侵入された」

という意味ではありません。

インターネット上では、こうしたファイルが存在しないかを自動的に探しているアクセスが普段から行われています。

今回私が確認した範囲では、

404
→ そのファイルは存在しない

403
→ アクセスを拒否した

401
→ 認証が必要なので止めた

というものが中心でした。

Basic認証を設定したサイトでは、実際に怪しいアクセスが「401」で止まっていることも確認できました。

今回確認したログの範囲では、侵入に成功したと判断できるものは見つかっていません。

「攻撃された」と「侵入された」は別物

ここは私自身も今回ログを確認していて大事だと感じました。

インターネット上にホームページを公開している以上、怪しいアクセス自体は普段から来ています。

そのため、

怪しいアクセスがあった

↓

サイトが乗っ取られた

ということではありません。

一方で、アクセスログだけを見て、

「絶対に何も起きていない」

と断定することもできません。

そのため、念のため、

  • WordPressに知らない管理者ユーザーが追加されていないか
  • 見覚えのないファイルが増えていないか
  • 最近、身に覚えのないPHPファイルが更新されていないか

なども確認しておくと安心です。

私も管理しているサイトについて順番に確認しています。

ここまでやったら、ひとまずサーバー会社の対応を待つ

今回の問題を完全に解決するには、最終的にはPHPそのものが修正された状態になる必要があります。

レンタルサーバーを利用している場合、この部分は利用者側では対応できず、サーバー会社側の対応を待つケースがあります。

そのため私は現在、

  1. WordPressからPHPバージョンを確認
  2. レンタルサーバー会社の公式発表を確認
  3. WAFをONにする
  4. 安全を確認できないサイトにはBasic認証を設定
  5. Basic認証が正常に動いていることを確認
  6. アクセスログ・エラーログを確認
  7. サーバー会社の対応状況を引き続き確認

というところまで対応しています。

PHPの修正が確認できたら、Basic認証を解除して通常公開に戻す予定です。

つまり、

「自分でできるところまでは対応する」

「自分ではできない部分は、サーバー会社の対応を確認する」

と分けて考えると分かりやすいと思います。

よく分からない場合は、まずPHPバージョンだけでも確認してください

今回の話は専門用語が多く、普段ホームページを管理していない方にはかなり分かりにくいと思います。

全部を理解する必要はないと思っています。

WordPressを利用しているのであれば、まず、

「自分のサイトのPHPバージョンは何になっているのか」

だけでも確認してみてください。

そして、

「このバージョンで大丈夫なのか分からない」

「Basic認証まで自分で設定するのは怖い」

という場合は、無理に操作せず、ホームページを制作した会社やレンタルサーバー会社に確認するのが一番確実です。

特にPHPのバージョンについては、

「新しいものにすれば安全だろう」

と自己判断で大きく変更すると、サイトが正常に動かなくなる可能性があります。

分からない状態で変更するより、

まず確認する。

それだけでも今回のような問題への大切な一歩だと思います。

最後に

今回の記事は、セキュリティの専門家として難しい技術的な解説をするために書いたものではありません。

私自身もWebサイトを制作・管理する立場として、

「今回何が起きているのか」

「自分の管理サイトでは何を確認したのか」

「安全だと確認できない間に何をしたのか」

を共有するために書いています。

今回のような話は、調べれば調べるほど専門用語が出てきます。

でも、

「よく分からないから何もしない」

ではなく、

「よく分からないけど、とりあえず今できることだけでもやっておこう」

と思ってもらえれば、それだけでもこの記事を書いた意味があると思っています。

私自身もまだ現在進行形で確認しています。

ConoHa WINGをはじめ、各レンタルサーバー会社の対応状況やPHPの更新を確認でき次第、この記事にも追記していく予定です。

同じようにWordPressやホームページ、ブログを管理されている方にとって、少しでも参考になれば嬉しいです。


参考情報

・IPA(情報処理推進機構)「PHPのセキュリティリリース公開予定について」

・高市総理による対応の呼びかけ

・PHP公式 セキュリティリリース情報

・各レンタルサーバー会社の公式メンテナンス・障害情報

※状況が随時変わっているため、この記事だけで判断せず、利用しているレンタルサーバー会社の最新情報もあわせてご確認ください。