PHPに「深刻度9.2」の脆弱性が2つ。ホームページを持つ人が知っておきたいこと

もくじ

PHPに、深刻な脆弱性が2つ見つかった

2026年10月21日、PHPの公式サイトに、緊急のセキュリティ勧告が出た。
PHPの重大な脆弱性が2つ見つかり、修正版が公開されたという内容だ。

2つとも、深刻度は、CVSS v4.0という評価方法で、9.2(10点満点)とされている。
GitHubで公開されているPHPの公式の勧告では、どちらも、最も高い区分の「Critical」だ。

PHPは、WordPressをはじめ、多くのホームページで使われている仕組みだ。
ホームページを持っている方、お客様のサイトを預かっている方には、関係のある話になる。

この記事では、PHPの公式の勧告とIPAの注意喚起に書かれている範囲を中心に、何が起きたのか、何をすればよいのかをまとめる。

結論から言うと、レンタルサーバーでは、PHPの更新はサーバー会社が行うことが多い。
まず、使っているサーバー会社のお知らせを見てほしい。

何が見つかったのか

見つかったのは、次の2つだ。

  • CVE-2026-109618
  • CVE-2026-109619

どちらも、GitHubで公開されているPHPの公式の勧告では、認証なしで、外部からコードを実行されてしまう可能性があるもの(リモートコード実行)とされている。
つまり、ログインしていない第三者が、サーバーの上で好きなプログラムを動かせてしまう可能性がある、ということだ。
攻撃が成立するには一定の条件が必要とされているが、サイトの持ち主が何も間違ったことをしていなくても、対象になりうる。

悪用されると、何が起きるのか

CVE-2026-109618の公式のアドバイザリ(GitHub)には、確認された影響として、「認証なしで、Webサーバーの処理を担当するアカウントの権限で、コードを外部から実行できる」と書かれている。
同じアドバイザリには、mod_phpに対して、HTTP経由でコードの実行を確認した、とも書かれている。
もう1つのCVE-2026-109619のアドバイザリにも、mod_phpでの攻撃を確認した、との記載がある。
また、CVSSの評価では、情報の漏えい、改ざん、サービスの停止のいずれも、影響が「高い」とされている。
攻撃の複雑さは、CVSSの評価で「高い」とされている。
それでも、ログインなどの認証は、要らない。

ここからは、公式の勧告そのものではなく、コードを実行されたときに、一般に起きると言われている被害の例だ。

サイトの乗っ取り。

ホームページの内容を書き換えられたり、サーバーの中にある情報を持ち出されたり、不正なプログラムを置かれたりする。

サイトが「踏み台」にされる。

自分のサイトが、他のサイトへ攻撃をするための足場に使われる。
また、他のサイトの乗っ取りを手伝わされることもある。
被害者になるだけでなく、知らないうちに、攻撃の加害側に使われてしまう。

修正版より前のバージョンのPHPを使っている場合は、サイトが小さくても、アクセスが少なくても、対象になりうる。
対象になりうる場合でも、私は、まずは、サーバー会社のお知らせを確認し、その報告を待つのが基本になると考えている。
ただし、PHPのバージョンが古い場合は、私は、アップデートを推奨したい。

どれくらい深刻なのか

PHPの公式は、次の点を挙げている。

対象は、Webのリクエストを受けつけるPHPのすべての環境だ。
PHP-FPM、Apacheのmod_php(PHPをWebサーバーに組み込んで動かす方式)、php-cgi、FrankenPHP、LiteSpeedなどが挙げられている。
なかでも、mod_phpのリスクが最も高いと、公式は考えている。
mod_phpでは、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立する実証がある、と書かれている。

IPA(情報処理推進機構)は、修正版の公開前の10月21日に、事前準備を呼びかける注意喚起を出した。
その時点では、IPAが、この脆弱性を悪用した攻撃を確認しているわけではない、としている。
一方で、PHPの脆弱性は、2024年7月にも、悪用した攻撃への注意喚起を出していて、今回も悪用されるおそれがあるため、予防的に発信している、と書かれている。
さらに、サポートが終了した古いPHPを使い続けているサイトも見受けられ、攻撃者が極めて短時間で攻撃する可能性もある、とも書かれている。

また、PHPの公式は、修正版にすぐ更新することを強く勧めている。
更新できない場合の一時的な対策も書かれていて、具体的な内容は、PHPの公式の勧告にある。
ただし、公式は、完全な解決は更新だけであり、一時的な対策だけでは安全にならない、としている。

修正されたバージョン

修正版は、次の4つだ。

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

PHP 8.1以前は、PHPのプロジェクトとしては、もう更新が出ていない。
公式は、ディストリビューション(Linuxなどを配布している団体や会社)やLTS(長期サポート)を提供する会社が、修正を移植して出している場合があると書いている。
そのため、古いバージョンを使っている場合は、サーバーを提供している会社に確認するか、サポートされているバージョンへ上げることが勧められている。

また、PHPのプロジェクトは、今回の深刻さから、例外として、PHP 7.4・8.0・8.1向けにも、最小限の修正を用意した、と書いている。
ソースからビルドする人や、LTSを提供する会社を使えない人向けなので、レンタルサーバーを使っている場合は、サーバー会社の案内を確認することになる。

ホームページを持つ人は、何をすればよいのか

ここからは、公式の勧告ではなく、私の考えを含む。

レンタルサーバーを使っている場合は、まず、サーバー会社のお知らせを見る。

多くの場合は、自分で更新するのではなく、サーバー会社が更新するのを、確認することになる。

自分でPHPのバージョンを選べるサーバーの場合は、バージョンを確認する。

IPAは、PHPを利用しているプログラムを、可能な範囲で棚卸しするよう呼びかけている。
8.1以前のまま動いているサイトがないかを、一度見ておくとよい。
WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」の「サーバー」の欄に、PHPに関する情報が出る。
私が見たサイトでは、サイトヘルスが見当たらないものもあった。
そのときは、ダッシュボードの「サイト情報」のような欄に、WordPressやテーマと並んで、PHPのバージョンが出ていることがある。
PHPのバージョンが古いと、ダッシュボードに「PHP の更新を推奨」という通知が出るサイトもある。
バージョンが分からないときは、サーバー会社のサポートに、使っているPHPのバージョンを尋ねる方法もある。
分からなくても、自分を責める必要はない。
8.1以前の扱いは、サーバー会社によって違う可能性があるので、サーバー会社のお知らせやサポートページで案内を確認してから判断する。
また、ロリポップ!は、公式の修正版がない古いバージョンのPHPにも、独自に修正を適用している。
バージョンの番号だけでは、修正が済んでいるかどうかは分からないので、サーバー会社の案内もあわせて見てほしい。

お客様のサイトを預かっている場合は、先に一言伝える。

今回のように、サーバー側で緊急メンテナンスが入ることがある。
「サーバー側の事情で、一時的に見られなくなるかもしれません」と、先に伝えておくと、実際に起きたときの受け止め方が違う。
私の場合は、夜遅い時間だったが、メンテナンスの前に、お客様全員に、LINEやメール、メッセンジャーで報告した。

メンテナンスの最中や直後は、設定を触らない。

サイトが表示されなくなる例もある。
今回、私が確認したサイトでも、表示できなかったものがあった。
そのときに、慌てて自分のサイトの設定を触ると、原因が分からなくなる。
サーバー会社のお知らせを、先に見るのが、いちばん確実だ。

サーバー会社の対応は、会社によって違った

同じ脆弱性への対応も、サーバー会社によって違った。

XREAの場合

自社のサイトを置いているXREAは、公式のお知らせで、次のように案内していた。
メンテナンスは、2026年10月22日の0時から0時50分まで行われ、対象はXREAの全サーバーだった。
作業中は、サービスの再起動で、10分程度、Webサイトが繋がりにくくなる場合があるとされていた。
完了の報告には、PHP 7.4以上のバージョンで対応を完了していて、該当のバージョンを使っているお客様は、PHPのバージョンを変えるなどの対応は必要ない、とも書かれている。

ロリポップ!の場合

ロリポップ!は、PHPの修正版が公開される前に、予防措置としてメンテナンスを実施する、と10月21日にお知らせのページで案内していた。
メンテナンスのお知らせには、PHPの重大な脆弱性に関するセキュリティリリースが、10月21日の23時に公開されることが予告されたこと、IPA(情報処理推進機構)からも事前準備を呼びかける注意喚起が出ていることが書かれていた。
メンテナンスの対象として、サービスサイトやユーザー専用ページなどが、順次停止する、とされていた。
また、安全な運用に支障があると判断された場合は、お客様のサイトを保護するため、予告なくサイトを停止(制限)することがある、とも書かれていた。

10月22日、ロリポップ!の公式Xには、次の投稿があった。
12時5分ごろの投稿には、PHPの重大な脆弱性について修正を行い、お客様のサイトは、あと1時間程度で再開を予定している、とあった。

私が確認した12のサイトのうち、ロリポップ!にある10のサイトは、12時20分の時点で、「502 Bad Gateway」のエラーで表示できなかった。
XREAにある2つのサイトは、問題なく表示されていた。

13時11分ごろの投稿には、停止していたお客様のサイトについて、修正版の適用を行い、10月22日の13時11分に再開した、とあった。
同じ投稿には、公式の修正版がない旧バージョンのPHPにも、ロリポップ!が独自に修正を適用している、とも書かれていた。

私が502を確認した12時20分は、この再開より前で、「お客様のサイトは、あと1時間程度で再開を予定」とされていた時間帯にあたる。
公式Xの投稿によると、お客様のサイトが停止されていたとのことだ。
そのため、表示できなかったのは、この停止の影響だった可能性があると考えている。
ただし、ロリポップ!は、個々のサイトが502になった原因までは、明らかにしていない。
私が15時8分に確認したときは、12のサイトすべてが表示できた。

その後、ロリポップ!のお知らせのページは、10月22日15時33分に更新された。
更新では、お客様のサイトも閲覧できる状況になった、と案内されていた。
ただし、一部のサービスは、引き続き停止していた。
ロリポップ!の案内では、PHP8系とPHP7.4は公式の修正版を適用し、それ以外のバージョンは、公式の修正内容に基づいて、ロリポップ!で独自に修正した、とされていた。
さらに、古いバージョンのPHPには、今後も新しい脆弱性への公式な修正が提供されない可能性があるとして、新しいバージョンへの切り替えを検討してほしい、とも案内されていた。
一部の機能を無効にしているとの案内もあるため、ロリポップ!を使っている方は、お知らせのページで詳細を確認してほしい。

どちらが良い、という話ではない。
ただ、使っているサーバー会社が、こうした緊急の脆弱性にどう対応するのかを、あらかじめ知っておくことには意味があると感じた。

おわりに

PHPのように、多くのホームページの土台になっている仕組みで、公式が最も高い区分の「Critical」とした脆弱性が、2つ同時に見つかった。
サイトの持ち主が何もしていなくても、土台の側で緊急の対応が必要になることがある。

今回のことで、あらためて、「サーバー会社のお知らせを見る場所を決めておくこと」と「お客様に先に伝えておくこと」が大事だと感じた。
同じようなことが起きたときに、少しでも落ち着いて動けるよう、この記事を残しておく。

参考

この記事が気に入ったら
いいね または フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

もくじ