PHPの脆弱性とは、Webサイトを動かすPHPの仕組みにある、攻撃に悪用されるおそれのある弱点です。条件によってはサイトの改ざんや情報漏えいにつながるため、利用しているPHPのバージョンと修正状況を調べ、必要な更新を行うことが基本になります。
「えぞノオト」のマンマユートです。「PHPが危ない」と聞くと、自分のブログも心配になりますよね。2026年10月21日には重大な脆弱性2件の修正版が公開されました。この記事では2026年10月22日に確認した公式情報をもとに、意味と影響、WordPress運営者ができる対応を整理します。
PHPの脆弱性とは？ウイルスとは違うもの
PHPは、サーバー側で動くプログラミング言語の一つです。WordPressもPHPを使っており、訪問者が記事を開くときなどに、サーバーがプログラムを処理してページを届けます。パソコンで記事を書く人も、サーバーを通してPHPを利用しているわけですね。
脆弱性はウイルスそのものではありません。プログラムなどの弱点を指す言葉で、攻撃者がそこを突くと、本来は許されていない処理が行われる場合があります。弱点が見つかったことと、すでに自分のサイトが侵入されたことは、別の話です。
また、「PHPの脆弱性」という言葉には注意が必要です。PHP自体の不具合と、PHPで作られたテーマやプラグインの不具合では、更新する対象が違います。通知を読んだら、製品名、CVE番号、影響するバージョンを手がかりに、何の問題かを特定するところから始めます。
2026年10月に公開された重大な脆弱性と修正版
2026年10月21日、PHPプロジェクトはCVE-2026-109618とCVE-2026-109619を修正する更新を公開しました。どちらも、条件がそろうと認証されていない攻撃者による遠隔からのコード実行につながる重大な問題です。
難しい表現ですが、ログインしていない第三者が、サーバーで不正な処理を実行できるおそれがある、という意味です。PHP公式はWebリクエストを処理する各種PHP環境をリスクの対象としており、特定のWordPressテーマだけの問題ではありません。
下表は、この2件への対応として公開された修正版です。「PHP 8.3を使っている」といった大まかな番号だけでは判断できません。末尾まで含むバージョンと、事業者による修正適用の案内を照らし合わせる必要があります。
| PHPの系列 | 2026年10月21日公開の修正版 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
この表は、将来見つかる脆弱性まで修正済みと保証するものではありません。また、OSの配布元などが修正だけを取り込む「バックポート」では、表示される番号だけで判別できない場合があります。そのときは、利用先のセキュリティ情報が判断材料になります。
自分のWordPressのPHPバージョンはどこで見る？
WordPressでは、管理画面の「ツール」から「サイトヘルス」を開き、「情報」の「サーバー」にあるPHPバージョンを確認できます。画面の表記は環境によって多少異なりますが、記事編集画面ではなく、サーバー情報を見るのがポイントです。
レンタルサーバーの管理画面にも、PHPの設定やバージョン表示が用意されている場合があります。複数のドメインを運営しているなら、サイトごとの設定を調べましょう。一つのブログを変更しても、別のサイトまで同じ設定になるとは限りません。
ここで混同しやすいのが、WordPress本体のバージョンです。WordPress、テーマ、プラグイン、PHPはそれぞれ更新対象が異なります。今回のPHPの問題について、WordPress公式はWordPress本体の更新では対応しないことを説明しています。
マンマユート「更新しました」が、何の更新なのかまで分かると安心ですね
レンタルサーバーでの更新はどう進める？
PHPの更新方法は契約先によって違います。サーバー会社が修正版を適用する場合もあれば、利用者が管理画面でPHPの系列を切り替える場合もあります。制作会社に管理を任せているなら、契約先と管理担当者に対応状況を尋ねるのが現実的です。
私なら、「更新済みですか」だけで終わらせず、対象ドメイン、稼働中のPHPバージョン、今回の2件への修正適用状況をまとめて聞きます。回答に対象と修正内容が書かれていれば、後から見返したときにも判断しやすいですよね。
更新前にはサイトのファイルとデータベースをバックアップし、復元方法も確かめておきます。PHPの系列を変えると、古いテーマやプラグインが動かなくなる場合があるためです。ただし、重大な脆弱性への対応を長く先延ばしにせず、事業者と更新・検証の段取りを急いで相談します。
検証用の環境が利用できる場合は、そちらで動作を試してから本番へ反映する方法があります。更新後はトップページの見た目だけでなく、記事表示、管理画面へのログイン、問い合わせフォーム、予約や購入など、そのサイトで使っている機能を実際に確かめます。
古いPHPは、動いていても使い続けてよいとは限らない
2026年10月22日時点のPHP公式サポートでは、PHP 8.2と8.3はセキュリティ修正の対象、8.4と8.5は通常のバグ修正も行う対象です。ただし、サポート対象の系列であっても、古い小さなバージョンのままなら今回の修正が入っていないことがあります。
PHP 8.1以前は、PHPプロジェクトの通常のサポートが終了しています。一部の配布元や長期サポート事業者による修正提供はありますが、「古いけれど動く」だけでは安全性を判断できません。提供元の対応確認と、サポート中の系列への移行を考える必要があります。
PHP公式は今回の重大性を踏まえ、7.4、8.0、8.1向けの最小限のソース修正も特例として提供しています。ただし、これは通常サポートの再開を意味しません。一般のブログ運営者が自力で修正を組み込むより、契約先がどう対応するかを確認するほうが確実です。
表示が正常でも、被害がないとは言い切れない
サイトが普通に表示されていても、脆弱性がないとは判断できません。反対に、PHPに弱点があるからといって、訪問者全員のパソコンが感染したと決まるわけでもありません。影響は脆弱性の内容と利用環境、実際に受けた攻撃によって異なります。
IPAは、別件である2024年のCVE-2024-4577について、国内で悪用被害を確認したと公表しています。修正適用後もログなどから被害を調べるよう呼びかけており、「更新すれば、それ以前の侵入の痕跡も消える」という考え方は避けたいところです。
身に覚えのないページや管理者アカウント、不審な転送などがある場合は、サーバー会社や管理担当者に相談します。記録の保存と被害範囲の調査が必要になるため、慌ててファイルを消すより、いつ何に気づいたかを残して伝えることが役立ちます。
WAFだけに頼らず、修正の適用まで確かめよう
WAFは、Webサイトへの不正な通信を検知・遮断するための仕組みです。ただし、導入しているだけで今回の脆弱性が直ったことにはなりません。PHP公式は、特定の攻撃経路への露出を減らす暫定措置と、修正を適用する更新を明確に区別しています。
すぐに修正できない場合、CERT-EUは修正の適用と検証が終わるまで、インターネットからのアクセスを隔離することを検討するよう勧めています。WordPressに休止画面を出すだけで十分かは別問題なので、サーバー側での公開停止やアクセス制限を管理担当者と相談する必要があります。
ブログ運営者が最初にすることは、自分のサイトのPHPバージョンと契約先の対応案内を把握することです。番号が分からなければ、ドメインを添えて問い合わせるところからで大丈夫です。
PHPの脆弱性への対応は、一度の更新で終わりではありません。サーバー会社のお知らせを受け取れる状態にし、バックアップと更新後の動作確認を続けることで、次の案内にも対応しやすくなります。まずは管理画面のPHPバージョンを一つ、控えるところから始めてみませんか。
