WebサイトのPHPのバージョンを今日確認する、遠隔コード実行の2つの脆弱性に修正版が出たため

あなたのWebサイト、あるいはお店が人に任せて作っているサイトは、PHP（WordPressやMagento、多くの販売サイトやニュースサイトの裏で動くプログラミング言語）で動いている可能性が高いでしょう。2026年10月21日、PHPチームは、見知らぬ人がログインなしでサーバー上でコードを実行できてしまう深刻な脆弱性2件について、セキュリティ勧告を修正版とともに公開しました。今日あなたがやることは、サイトがどのバージョンで動いているかを知り、適切な相手に修正済みかどうかを尋ねることです。

週刊まとめweekly-roundup-2026-w44（10月26日）は、PHPのパッチと10月23日の設定の1行にすでに触れています。この記事では、バージョンの確認手順と、提供元に送る文面の例を加えます。

順番に行う5つの手順

この記事のために作った例です。ホアさんは家庭用品をWordPressのサイトで売っていて、サイトは外部のWeb制作者トゥアンさんが管理し、共用ホスティングのプランに置かれています。

1. サイトの管理者に尋ねるか、ホスティング提供元の管理画面を開いて、サイトがどのバージョンのPHPで動いているかを確認します。WordPressでは、この数字がサイトヘルス（情報タブ）に表示されます。SSH（サーバーへのコマンドラインでのログイン）が使えるなら php -v と入力します。このコマンドが示すのはコマンドラインで使われるバージョンで、Webが使うものとは違うことがあるため、管理画面と照らし合わせてください。
2. 見えた数字を、PHPチームの発表にある修正済みバージョン（8.5.12、8.4.27、8.3.36、8.2.35、または同じ系列のそれより新しいもの）と比べます。それより低い場合、または8.1以前の場合は、手順3に進みます。
3. ホスティング提供元かサイトの管理者に、短いメッセージを送ります。「私のサイトはどのバージョンのPHPで動いていますか？ CVE-2026-109618とCVE-2026-109619の修正はもう入っていますか？ PHP 8.1以前の場合、古いバージョン向けにバックポートされた修正はありますか。それとも新しいバージョンに上げる必要がありますか？ 更新後、10月23日にPHPチームが勧めたとおり、session.upload_progress.enabled=0 を設定済みですか？」3つ目の質問が大切なのは、古いバージョン番号のまま、すでに修正が当てられていることがあり、それは提供元にしか答えられないからです。
4. 回答と受け取った日付を記録します。更新を約束されたら、具体的な日付を尋ね、更新前にサイトのバックアップを取るよう頼みます。古いプラグイン（WordPressに追加する部品）は、新しいPHPでは動かないことがあるからです。
5. 更新後、手順1をやり直します。合格の目安は、新しいバージョン番号が手順2の一覧に入っていること、トップページ、カート、ログインページがこれまでどおり開くこと、そして提供元が session.upload_progress.enabled をオフにしたと確認する、またはアプリケーションが実行時に session.serialize_handler を変更しないと確認することです。

これらの手順の背景です。php.netの発表によると、2つの脆弱性はCVE-2026-109618（CVEは個々のセキュリティ上の欠陥につける共通の識別番号で、提供元に尋ねるときにこの番号を使います。これはメモリ不足でリクエストのデータが中途半端に初期化され、その後の後始末が壊れたデータを有効なものとして扱うことによる欠陥です）と、CVE-2026-109619（あるリクエストが持つ状態データが、メモリが解放されたあとも残り、後のリクエストが誤って使ってしまう欠陥）です。どちらも認証なしでRCE（remote code execution、遠隔コード実行）が可能です。PHPチームは、Webリクエストを処理するすべてのPHP環境が危険にさらされており、PHP-FPM、Apache上のmod_php、php-cgi、FrankenPHP、LiteSpeed（サーバーがPHPを動かすさまざまな方式）が含まれると書いています。リスクが最も高いのはmod_phpで、認証なしのリクエストがアプリケーションのコードが動く前に攻撃を引き起こせることを実証した攻撃コードがある、としています。

PHP 8.1以前は、プロジェクトからの更新が出なくなっています。PHPチームによると、一部のLinuxディストリビューションや長期サポートの提供元は、古いバージョン向けに自前で修正を当てており、チームは、ソースからビルドする人のために、PHP 7.4、8.0、8.1向けの最小限のソース修正も用意しました。

ベトナムの新聞Tuoi Treは、ロイターとサウス・チャイナ・モーニング・ポストを引用して、多くの政府機関が修正を待つ間にサイトをネットワークから外し、2つの脆弱性はサイバーセキュリティ企業がAIの支援を受けて見つけたと伝えています。そのうちの1社であるWizは、PHPが世界のWebサイトの約70%で動いていると見積もっています。

10月21日、PHPチームは、完全な解決策は更新だけで、暫定的な対策は攻撃経路を減らすにすぎないと述べました。10月23日には、次の定例のバグ修正リリースまで、session.upload_progress.enabled をオフにするよう勧めました。修正済みのバージョンでも起こりうる、まれな遠隔コード実行の経路をふさぐためです。この欠陥が起きるのは、アプリケーションが session.serialize_handler を php_binary か php_serialize に設定し、そのあと session_start() の前に ini_set() で実行時に php へ切り替え、しかもセッションのアップロード進捗がまだオンのときだけです。10月21日からオフにしている場合は、そのままにして、追加の作業は要りません。サーバーの管理者は、アプリケーションが上書きできないよう、サーバー側で memory_limit=-1 を設定し、post_max_size を低く（サイトがファイルのアップロードを受け付けないなら8M、受け付けるなら32M）設定し、session.upload_progress.enabled をオフにして、すべてのPHPプロセスを再起動できます。Webサーバー側の制限を含む完全な一覧は元の勧告にあります。サーバーの管理者でなければ、自分で変更しないでください。

提供元がその日のうちに返事をくれない場合、またはあなたのプランがPHP 8.1以前で、バックポートされた修正もないと言われた場合は、更新の方法か提供元の乗り換えについて尋ね、待つ間はログインや支払いのあるページを一時的に閉じることも検討してください。これはこの記事独自の提案であり、PHPチームの助言ではありません。

参考資料

1. php.net, “Security advisory: Critical remote code execution vulnerabilities, update now”（2026年10月21日） — 2つのCVE、修正済みバージョン、影響範囲、暫定対策の一次情報です。同じページにある2026年10月23日の「Informational advisory: Session upload progress」も含みます。PHPプロジェクトの公式発表です。
2. Tuoi Tre, “Lỗ hổng bảo mật do AI phát hiện khiến loạt website chính phủ nhiều nước ngừng hoạt động”（2026年10月22日） — 機関がサイトを外したこと、AIの支援による脆弱性の発見、Wizの70%という見積もりを、ロイターとサウス・チャイナ・モーニング・ポストを引用して伝えています。
3. Wiz Research blog, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”（2026年10月21日） — Wiz Researchのブログのページに、Sagi Tzadik、Shir Tamari、Nir Ohfeld、Tomer Schwartzによる2026年10月21日のPHP2Shellの記事が掲載されています。70%という見積もりの出典です。

Nguồn tham khảo

1. php.net
2. Tuổi Trẻ
3. wiz.io