PHPの緊急脆弱性(CVE-2026-109618/109619)への対応手順　まだ更新できていないサイトへ

要約： 2026年10月21日、PHPの開発チームは、認証なしで遠隔からコードを実行される恐れのある脆弱性2件(CVSS v4.0で9.2)を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。完全な対策は更新だけです。すぐに更新できない場合は、PHPにリクエストが届く手前でサイトを止めるのが、もっとも確実なつなぎの手段です。

目次

1. 2026年10月21日に公開されたPHPの脆弱性は、何が危ないのか
2. 自社のPHPが影響を受けるかは、どう確認するか
3. すぐに更新できない場合は、どうすればよいか
4. VAONは、お客様のPHPシステムをどう更新したか
5. 更新が終わったあとに、確認しておきたいことは何か
6. この手順で足りないのは、どのような場合か
7. よくあるご質問

1. 2026年10月21日に公開されたPHPの脆弱性は、何が危ないのか

2026年10月21日(日本時間23時ごろ)にPHPの開発チームが公開した修正は、2件の脆弱性を対象にしています。どちらも深刻度はCVSS v4.0で9.2(Critical)です。認証のない外部からのリクエストで、Webサーバーの実行ユーザーの権限のままコードを実行される恐れがあります。

PHP 8.1以前には、PHPの開発チームからの更新が出ません。ディストリビューションや長期サポート(LTS)の事業者がバックポートを出している場合があるので、使っている提供元に確認する必要があります。

日本では、状況がもう一段切迫していました。ITmedia NEWSの報道によると、修正版の公開前に脆弱性の情報とPoC(攻撃の概念実証コード)がネット上に出回り、攻撃の試みも観測されていました。高市首相はXで当日夜の対応を呼びかけ、すぐに適用できない場合はサイトの一時停止も有効な策の一つだと述べています。国内のネットサービスでも、緊急メンテナンスに入るところが相次ぎました。

2. 自社のPHPが影響を受けるかは、どう確認するか

影響の確認には、バージョンの数字だけでは足りません。次の3点を合わせて見ます。

1. Webで動いているPHPのバージョン。 サーバーでphp -vを実行して表示されるのは、コマンドライン用(CLI)のPHPです。Webのリクエストを処理しているのはPHP-FPMやmod_phpなので、php-fpm8.3 -v(RHEL系ではphp-fpm -v)のようにFPM本体を確かめるか、管理者だけが開ける場所でphpinfo()を表示して確認します。CLIとFPMで別のバージョンが入っているサーバーは、珍しくありません。
2. パッケージの入手元。 UbuntuやDebian、RHEL系の公式パッケージは、バージョン番号を上げずに修正だけを取り込むことがあります。その場合、php -vが8.3.36より古い番号を返しても、修正は入っています。番号だけで「対象外」と決めるのも、「危険」と決めるのも誤りのもとです。判断の根拠は、提供元のセキュリティ情報と更新履歴に置きます。PHPの公式発表では、有志が運営するrpms.remirepo.netは公開当日の更新がないとされていました。このリポジトリを使っているサーバーは、ディストリビューションのパッケージに切り替えるか、ソースからビルドする必要があります。
3. SAPI(PHPとWebサーバーのつなぎ方)。 phpinfo()の「Server API」の欄で分かります。「Apache 2.0 Handler」ならmod_phpで、今回もっとも危険な構成です。「FPM/FastCGI」なら、Webサーバーの設定でPHP_VALUEなどを渡していないかも確かめます。

共有のレンタルサーバーやマネージドの環境では、PHPの更新を利用者側でできないことがあります。この場合は、事業者の告知を確認し、対応の時期が分からなければ問い合わせるのが先です。

3. すぐに更新できない場合は、どうすればよいか

PHPの更新がすぐにできないなら、最初に決めるのは、サイトを一時的に止めるかどうかです。PHPの公式発表は「完全な緩和策はなく、更新だけが安全な選択」としています。設定でリスクを下げる方法も示されていますが、どれも部分的な効果にとどまります。

止めるときに気をつけたいのは、止める場所です。アプリケーションのメンテナンスモード(Laravelのphp artisan downなど)は、PHPが動いたうえで「メンテナンス中」を返す仕組みです。CVE-2026-109618はアプリのコードが動く前に攻撃が成立する例が示されているので、この方法では守れません。メンテナンス画面は、ロードバランサーやCDN、Webサーバーの設定から静的なHTMLとして返し、PHPにリクエストを届けないようにします。

止められない事情がある場合に、公式の発表が示している暫定の設定は次のとおりです。

• session.upload_progress.enabled=0をphp.ini、FPMのプール設定、またはサーバーの設定で指定し、すべてのワーカーを再起動する(ini_set()や.user.iniでは効かない)
• memory_limit=-1をphp_admin_valueで指定し、アプリから上書きできないようにする
• post_max_sizeを下げる(公式の例は8M、ファイルのアップロードが必要なら32M)。upload_max_filesizeはそれより小さくする
• PHP 8.5ではfatal_error_backtraces=0を指定し、すべてのワーカーを再起動する
• multipartのリクエストを使わないアプリなら、前段で遮断する

memory_limit=-1は、メモリの上限そのものをなくす設定です。今回の脆弱性を避けるための指定ですが、サーバーのメモリを使い切られる危険と引き換えになります。公式の発表は、代わりにRLIMIT_ASやRLIMIT_DATAで制限すると脆弱な処理を呼び出してしまうとして、使わないよう注意しています。

4. VAONは、お客様のPHPシステムをどう更新したか

VAONは、修正版が公開された日本時間23時ごろの直後から、保守をお預かりしているお客様のPHPシステム5件の作業に入り、約1時間でPHPの更新を終えました。全体のテストには、そのあと別に時間を取っています。どのシステムも、次の6つの手順を同じ順番で進めています。

1. メンテナンス表示に切り替える。 お客様の担当者に停止する時間帯をお伝えしたうえで、Webサーバーやロードバランサーから静的なメンテナンス画面を返すようにしました。前の章で書いたとおり、PHPを通さない形です。
2. サーバーの構成を洗い出す。 OS、Webサーバー、SAPI、PHPのパッケージの入手元、Dockerイメージを使っているかどうかを、システムごとに一覧にしました。同じ「PHP 8.3」でも、入手元によって更新の方法が変わるからです。
3. 動いているPHPのバージョンを確かめる。 php -vに加えて、FPM本体のバージョンとphpinfo()のServer APIを見て、CLIとWebで食い違いがないかを確認しました。拡張モジュールの一覧(php -m)も、更新前の記録として残しています。
4. PHPを更新する。 提供元の修正済みパッケージ、または修正版で作り直したイメージに入れ替えました。そのあとPHP-FPMやApacheを再起動し、すべてのワーカーを新しいものにしています。設定ファイルを変えただけでは、古いワーカーが動き続けるためです。session.upload_progress.enabled=0は、アプリで使っていないことを確かめたうえで、更新後もそのまま残しました。
5. 全体をテストする。 自動テストのあるシステムはテストを流し、自動テストで見られない部分は、ログイン、検索、ファイルのアップロード、決済など、お客様の業務で止まると困る操作を手で確かめました。更新後のphp -mを更新前の記録と比べ、拡張モジュールが欠けていないことも見ています。エラーログに、更新前にはなかった警告が出ていないかも確認しました。
6. メンテナンスを解除し、様子を見る。 表示を元に戻したあとも、しばらくはエラーログとアクセスの状況を見続け、そのうえでお客様に完了をご報告しました。

6つの中でいちばん手間がかかったのは、更新の前後の確認でした。PHPのバージョンを上げると、プロジェクトが使っているライブラリの中に、新しいバージョンのPHPでは動かないものが出ることがあります。そこで、どのライブラリのどのバージョンが影響を受けうるかを先に洗い出し、そのうえでプロジェクト全体をテストし直しました。PHPの更新そのものより、この確認のほうに時間を使っています。

5. 更新が終わったあとに、確認しておきたいことは何か

PHPの更新で防げるのは、これから来る攻撃です。修正版の公開前から攻撃の試みが観測されていたので、更新前にサイトを公開していた場合は、すでに入り込まれていないかを確かめておく必要があります。

• Webサーバーの公開ディレクトリに、見覚えのないPHPファイルが増えていないか
• 更新の前後のアクセスログに、大きなmultipartのリクエストが集中していないか
• Webサーバーの実行ユーザーで、知らないプロセスが動いていないか

疑わしい点が一つでもあれば、サーバーを作り直す前提で、専門の調査を受けてください。

今回で終わりにしないための確認もあります。PHP 8.2のセキュリティ修正は、2026年12月31日で終わります。8.1以前で動いているシステムは、すでに公式の修正を受けられない状態です。次に緊急の修正が出たとき、その日のうちに更新できるようにしておくには、バージョンアップの計画を今のうちに立てておくほうが安全です。

6. この手順で足りないのは、どのような場合か

この記事の手順は、修正版のパッケージやイメージが手に入り、サーバーを自分たちで操作できることを前提にしています。次の場合は、別の対応が必要です。

• PHP 8.1以前で動いていて、新しいPHPでアプリが動くか確かめられていない場合。 バージョンを上げると、アプリが動かなくなることがあります。提供元のバックポートを使うか、止めたまま移行を進めるかの判断になります。
• 共有のレンタルサーバーなど、PHPの更新を事業者が行う環境の場合。 利用者側でできるのは、止めるかどうかの判断と、事業者への確認です。
• すでに侵害の痕跡がある場合。 更新しても、入り込まれた状態は元に戻りません。

VAONが行った対応も、更新より前に侵害がなかったことまでを保証するものではありません。どこまで確認するかは、お客様と相談して決めています。

7. よくあるご質問

php -vで表示されるバージョンが古いのですが、危険ですか。 番号だけでは判断できません。php -vはコマンドライン用のPHPのバージョンで、Webで動いているPHPとは別のことがあります。OSの公式パッケージは、番号を変えずに修正だけを取り込むこともあります。FPM本体のバージョンと、パッケージ提供元のセキュリティ情報を合わせて確認してください。

アプリのメンテナンスモードにすれば、攻撃を防げますか。 防げないと考えてください。Laravelのphp artisan downのような仕組みは、PHPが動いてから「メンテナンス中」を返します。CVE-2026-109618は、アプリのコードが動く前に攻撃が成立する例が示されているので、メンテナンス画面はPHPを通さない場所から返す必要があります。

PHP-FPMを使っていれば、影響はありませんか。 影響はあります。PHPの公式発表は、mod_phpをもっとも危険としながらも、PHP-FPMを含め、Webのリクエストを処理するすべての環境を対象にしています。nginxなどからPHP_VALUEやPHP_ADMIN_VALUEを渡している構成は、CVE-2026-109619の条件に当てはまるため、とくに注意が必要です。

暫定の設定変更だけで、しばらく様子を見てもよいですか。 おすすめしません。PHPの公式発表は、完全な緩和策はなく、更新だけが安全な選択だとしています。設定の変更は更新までのつなぎと考え、更新する日時を先に決めておいてください。

PHP 8.1を使っています。何から始めればよいですか。 まず、OSやLTSの提供元が修正を出しているかを確認します。出ていなければ、更新できるまでサイトを止めるか、前段でmultipartのリクエストを遮断するなどの対策を取りながら、サポート中のバージョンへ移行することになります。アプリの改修が必要かどうかは、ソースコードを見てからでないと判断できません。

PHPの更新が、まだ終わっていないサイトはありませんか。 サーバーの構成が分からない、引き継いだ担当者がもういない、といった状況でも構いません。無料相談でお話を伺い、止めるかどうか、どの順番で更新するかを一緒に整理します。お急ぎの場合は、luan.dang@vaon.com.vn まで直接メールでご連絡ください。無料相談

参考資料

• PHP「News Archive 2026」(Security advisory: Critical remote code execution vulnerabilities, update now、2026年10月21日)：https://www.php.net/archive/2026.php(2026年10月22日確認)
• php-src「GHSA-6wmf-4rv5-p3rp：RCE via stale global state」(CVE-2026-109619)：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp(2026年10月22日確認)
• ITmedia NEWS「高市総理「大至急、PHPパッチ適用を」Xで異例の要請　エンジニアは評価「経営層に伝わる」」(2026年10月22日)：https://www.itmedia.co.jp/news/article/2610/22/2000002483/(2026年10月22日確認)