PHPの重大な脆弱性(CVE-2026-109618/CVE-2026-109619)の確認方法と対策

この記事の要点

  • PHPに、ログイン不要で外部から攻撃される恐れのある重大な脆弱性が2件公表されました(深刻度:緊急)。
  • PHP 8.2.35/8.3.36/8.4.27/8.5.12 より前のバージョンが影響を受けます。WordPressなど、PHPで動くサイト全般が対象です。
  • 対策は、PHPを修正済みのバージョンに更新することです。PHP 8.1以前には修正版がないため、移行が必要です。

2026年10月21日、Webサイトやシステムで広く使われているプログラミング言語「PHP」に、重大な脆弱性が2件公表されました。この記事では、ご自身のサイトが影響を受けるかの確認方法と、環境別の対策をまとめています。

※ 本記事は2026年10月22日時点の情報です。新しい情報が公開された場合は、随時更新します。

脆弱性の概要

  • CVE-2026-109618:メモリ不足時の処理の不具合により、遠隔からプログラムを実行される恐れがあります。
  • CVE-2026-109619:リクエスト間に残る内部状態の不具合により、遠隔からプログラムを実行される恐れがあります。
  • 深刻度:いずれも CVSS v4.0 で 9.2(緊急)。ログイン不要で、外部からの通信のみで攻撃される恐れがあります。発見者は、WordPressに対してログインなしでプログラムを実行できることを実証しています。

まず確認:あなたのサイトは影響を受けるか

次のいずれかの方法で、Webサイトで使われているPHPのバージョンを確認してください。

方法1:WordPressの管理画面で確認する

管理画面の「ツール」→「サイトヘルス」→「情報」タブ →「サーバー」を開くと、「PHPバージョン」が表示されます。

方法2:レンタルサーバーの管理画面で確認する

多くのレンタルサーバーでは、管理画面の「PHPバージョン設定」などのメニューで、ドメインごとのPHPバージョンを確認・変更できます。

方法3:サーバー上で確認する

サーバーにログインできる場合は、php -v で確認できます。ただし、コマンドで使われるPHPと、Webサイトで使われるPHPが異なる場合があります。正確に確認するには、phpinfo() を表示するファイルを一時的に設置して確認し、確認後は必ず削除してください(サーバーの情報が外部に見えてしまうため)。

判定の目安

お使いのPHP修正済みのバージョン判定
8.5系8.5.12 以降8.5.11 以前は要更新
8.4系8.4.27 以降8.4.26 以前は要更新
8.3系8.3.36 以降8.3.35 以前は要更新
8.2系8.2.35 以降8.2.34 以前は要更新
8.1系以前修正版なし8.2以降への移行が必要

※ Linuxディストリビューションのパッケージは、バージョン番号が異なる場合があります(下の「よくある質問」を参照)。

環境別の対策方法

どの環境でも、作業の前にサイトのバックアップを取ってください。PHPのバージョンを変えると、古いプラグインやプログラムが動かなくなることがあります。

レンタルサーバーの場合

  1. ご利用中の事業者から、今回の脆弱性についてのお知らせが出ていないか確認します。
  2. 管理画面のPHPバージョン設定で、修正済みのバージョンが選べる場合は切り替えます。
  3. 切り替え後、サイトの表示や問い合わせフォームなど、主な機能が動くことを確認します。

WordPressの場合

  1. サイト全体(ファイルとデータベース)のバックアップを取ります。
  2. WordPress本体・プラグイン・テーマを最新にし、新しいPHPに対応しているか確認します。
  3. サーバー側でPHPを修正済みのバージョンに更新します(レンタルサーバー・自社サーバーの手順を参照)。
  4. 「サイトヘルス」でPHPバージョンが更新されたことと、サイトが正常に動くことを確認します。

※ WordPress本体の更新だけでは、今回の脆弱性は解消されません。

自社サーバー(VPS・クラウドなど)の場合

  1. OSのパッケージ管理(apt、dnf など)で、PHP関連のパッケージをセキュリティ更新します。
  2. PHPを動かしているWebサーバー(Apache、PHP-FPMなど)を再起動します。再起動しないと、古いPHPが動き続けます。
  3. phpinfo() などで、Webサイト側のPHPが更新されたことを確認します。

例えば Debian 12 では、セキュリティ更新で修正済みのパッケージ(8.2.35-1~deb12u1)が配布されています。

※ Bitnamiなど、アプリケーションとPHPがひとまとめになったイメージでは、PHPだけを個別に更新できない場合があります。その場合は、修正済みのPHPを含む新しいイメージ(または別の構成)への移行が必要です。

Dockerの場合

公式のPHPイメージなどを使っている場合は、修正済みのバージョンのイメージ(例:8.3系なら 8.3.36 以降のタグ)に更新して、コンテナを作り直してください。latest などのタグを使っている場合も、イメージを取得し直して再作成しないと、古いPHPが動き続けます。

すぐに更新できない場合の応急処置

PHPの公式勧告では、更新までのつなぎとして、受け付けるリクエストの大きさや入力項目の数を制限する、マルチパート形式(ファイルアップロードなど)を使わないサイトではそれを受け付けない、などの緩和策が挙げられています。

ただし、これらはいずれも部分的な対策で、完全な防御にはなりません。設定を誤るとサイトが動かなくなる恐れもあるため、できるだけ早くPHPを更新してください。詳しくは、下の「参考情報」にあるPHPの公式勧告をご確認ください。

よくある質問

Q. WordPress本体やプラグインを最新にすれば対策になりますか?
A. なりません。今回の脆弱性はWordPressではなく、その土台であるPHP本体にあります。PHPそのものを修正済みのバージョンに更新する必要があります。
Q. PHP 8.1以前を使っている場合はどうすればよいですか?
A. PHP 8.1以前には修正版が提供されません。PHP 8.2以降の修正済みバージョンへの移行が必要です。移行前に、プラグインやテーマ、独自のプログラムが新しいバージョンで動くかを確認してください。
Q. レンタルサーバーなら、事業者が自動で対応してくれますか?
A. 事業者によって異なります。自動で更新される場合もあれば、利用者が管理画面でバージョンを切り替える必要がある場合もあります。ご利用中の事業者のお知らせや公式ヘルプを確認してください。
Q. コマンドで表示されたバージョンが古いままですが、修正されていないのですか?
A. LinuxディストリビューションのPHPは、元のバージョン番号のまま修正だけを取り込む(バックポートする)ことがあります。その場合は、ディストリビューションのセキュリティ情報や更新履歴で、今回のCVEへの対応状況を確認してください。
Q. 攻撃されたかどうかを確認する方法はありますか?
A. 発見者の解説では、メモリ上限エラーを伴う不審なマルチパート形式のリクエスト、HTTP 500エラーの繰り返し、異常に大きい・不正な形式のセッションCookie(PHPSESSID)、説明のつかないPHPプロセスの再起動などが兆候として挙げられています。不審な点があれば、ログを保全したうえで専門家にご相談ください。

当社の対応支援について

当社では、以下の対応を承っております。

  • お使いの環境が影響を受けるかの調査
  • PHPの更新作業と、更新後の動作確認
  • 更新が難しい環境の移行(新しいサーバーへの移行、静的サイト化など)

PHPに限らず、深刻度の高い脆弱性への一連の対応(調査・更新・移行・継続的な監視)は「脆弱性対応サービス」をご覧ください。ご相談はお問い合わせフォームよりお気軽にご連絡ください。

参考情報

更新履歴

  • 2026年10月22日:確認方法、環境別の対策、応急処置、よくある質問を追加
  • 2026年10月21日:公開
PAGE TOP