PHP の重大な脆弱性 2 件を「更新と再起動」で閉じる：CVE-2026-109618・109619 の仕組みと運用の備え

IT関連

自宅のサーバーでも、レンタルサーバーでも、Web サイトの裏側では PHP が黙々と働いています。その PHP に、ログインしていない第三者が外から Web サーバー上でプログラムを動かせてしまうおそれのある、重大な脆弱性が 2 件見つかりました。2026年10月21日に、PHP プロジェクトが修正版を公開しています。

このサイトも、Kubernetes 上の PHP で動いています。他人事ではありません。結論から言うと、やるべきことは「更新」と「再起動」の 2 つだけです。ただし、この 2 つを正しく終えるには、問題の中身を少し知っておく必要があります。この記事では、公式の情報を順にたどりながら、なぜ更新が最善の策なのかを説明します。確認日は 2026年10月30日です。

「設定を変えれば大丈夫」とは言えない理由

最初に、安心しすぎないための事実を整理します。今回の脆弱性は、楽観できない点がいくつもあります。

どちらも深刻度は 9.2（緊急）です

PHP プロジェクトの告知によると、2 件とも深刻度の指標である CVSS v4.0 で 9.2 と評価されています。10 点満点に近い値で、「認証なしの遠隔コード実行につながりうる」と明記されています。

サイトのコードを丁寧に書いても防げません

問題は、サイトのプログラムではなく PHP 本体にあります。たとえば WordPress や Laravel のような、PHP で動くアプリケーションを最新にしても、PHP 自体が古ければ解消しません。

とくに Apache に PHP を組み込む mod_php という方式では、公式のアドバイザリが、既定の制限のままで成立する攻撃の実証があると報告しています。

完全な設定の対策はありません

アドバイザリは、更新が「唯一の確実な対策」であり、一般的な設定だけで完全に防ぐ方法はないと述べています。暫定対処はありますが、あくまで更新までの時間稼ぎです。

更新を受けられない古い版があります

PHP 公式のサポート一覧には、いま載っているのは 8.2 以降だけです。8.1 以前は、公式の修正を受けられません。しかも 8.2 は、2026年12月31日にセキュリティサポートも終わります。

公式は前日に予告し、同日に 4 系統の修正版を出しました

ここからは、安心できる材料を並べます。最初は、対応の速さです。時系列で見ると、PHP プロジェクトの動きは整然としています。

公開の前日に予告があったことは、運用する側にとって大きな助けです。更新の段取りを、前もって組めるからです。

現行の 4 系統すべてに修正が出ました

修正版は、サポート中の 8.2 から 8.5 までの全系統に出ています。自分の系統に合わせて、次のバージョン以降へ上げれば足ります。

終了日は、PHP 公式のサポート一覧の記載です。8.2 を使っている場合は、今回の更新に加えて、次の系統への移行計画も立てておくと安心です。

問題の仕組みは「後始末の誤り」と「前の要求の残りもの」です

次に、仕組みを知っておく価値を説明します。仕組みが分かると、更新後に何をすべきかも自然に分かります。ここでは、PHP が Web の要求を 1 件ずつ受け付ける窓口に似ていると考えてください。詳しい解説は、PHP の重大な脆弱性を初心者向けに解説した記事にもまとめられています。

1 件目は、メモリ不足のときの後始末です（CVE-2026-109618）

PHP は、メモリが足りなくなると、longjmp() という仕組みで処理を一気に中断します。ところが、準備の途中で中断すると、要求用のメモリが半分しか整っていない状態になります。そのまま後片付けに進むと、壊れた内容を正しいものとして扱ってしまいます。

アドバイザリには、攻撃者がメモリ不足を起こす経路も挙げられています。たとえば、ファイルのアップロードに使うマルチパート形式で、1 つの部品に付けられるヘッダーの数に上限がありません。中身が空のファイル欄は、アップロード数の上限に数えられないのに、内部ではメモリを使います。そのため、見かけ上の制限内の通信でも、メモリ不足に追い込めるのです。

2 件目は、前の要求の状態が残ることです（CVE-2026-109619）

PHP の作業員は、次の要求でも使い回されます。ところが、エラーやセッションなど、本来は要求ごとに片付けるはずの状態が、片付け後も残ることがあります。次の要求の準備より前に動く処理が、その古い情報を読むと、解放済みのメモリを使うことになります。

アドバイザリが確認した経路は、主に 2 つです。1 つは、PHP 8.5 の fatal_error_backtraces が有効なときです。もう 1 つは、既定で有効な session.upload_progress です。後者は、mod_php と PHP-FPM の両方で攻撃の成立が確認されたと書かれています。

「PHP-FPM なら安心」とは言えません

Nginx と PHP-FPM の組み合わせは、1 件目では影響が限られるとされています。起動の失敗で、作業員が終了するためです。ただしアドバイザリは、完全な攻撃が実証されていないだけで、影響を受けうるとも述べています。さらに 2 件目は、PHP-FPM でも攻撃の成立が確認されています。構成だけで安全と判断するのは、避けたほうがよいでしょう。

更新と再起動で、確実に閉じられます

修正の中身は、問題の根本を断つものです。アドバイザリによると、メモリ不足のときに longjmp() で中断する方式をやめ、次の安全な地点で止める方式と、即座にプロセスを終了する方式に置き換えています。つまり、壊れた状態のまま後片付けに進む経路自体がなくなります。

版数の確認は 1 行です

サーバーに入れるなら、次のコマンドで確認できます。

php -v

Web 経由で動く PHP は、コマンドラインのものと版が違うことがあります。コンテナなら、使っているイメージのタグを確認します。レンタルサーバーなら、管理画面に表示される PHP のバージョンが目安です。

再起動までが更新です

更新しても、動いているプロセスが古いままなら、修正は効きません。PHP-FPM や Apache を再起動する、コンテナなら再デプロイする、というところまでを作業に含めてください。

私のように Kubernetes で動かしている場合は、PHP のイメージのタグを新しい版に変えて、Pod を作り直せば、更新と再起動が同時に済みます。この種の入れ替えは、慣れた手順にしておくと、緊急時にも落ち着いて動けます。

すぐ更新できないときの暫定対処と、その限界

事情があってすぐに更新できない場合も、手がまったくないわけではありません。アドバイザリには、危険を下げる設定が示されています。

php.ini の例は、次のようになります。設定後は、PHP のプロセスの再起動が必要です。

memory_limit = -1
session.upload_progress.enabled = 0

暫定対処で大切なのは、「入れたから安全」と考えないことです。アドバイザリも、設定による対策は完全ではなく、ログの確認でも安全の証明にはならないと明言しています。更新までの数日を乗り切る手段として使い、更新の日程を同時に決めてください。

土台の脆弱性は、PHP だけではありません

今回の PHP の更新と同じ時期に、サーバーの土台に関する情報がほかにも出ています。更新の機会に、あわせて見直すと効率的です。

• Brotli: 圧縮ライブラリの重大な脆弱性（CVE-2026-111497）です。PHP プロジェクトは 10月26日に、Windows 向けのビルドを Brotli 1.2.1 入りで再公開しました。cURL で自動の展開を有効にしている場合に関わると説明されています。詳しくは、Brotli の重大な脆弱性の解説が参考になります。
• Linux カーネル: 10月に公表された TCP 処理の脆弱性があります。Linux カーネルの TCP の脆弱性の解説では、競合状態という種類の問題が説明されています。

こうした情報は、PHP・サーバーのセキュリティの解説をまとめたページで、同じ型に沿って読み比べられます。問題の箇所、影響の大きさ、対応方法の順に並んでいるため、自分の環境に関係するものを探しやすくなっています。

通知を受け取る体制が、いちばんの備えです

今回、PHP プロジェクトは公開の前日に予告を出しました。予告を見た時点で、更新の準備を始められた人は、当日のうちに対応を終えられたはずです。更新の通知を受け取る手段を、あらかじめ決めておくことが、いちばん費用のかからない対策です。

サポート期間から逆算すると、移行の時期を決められます

PHP 公式のサポート一覧を見ると、各系統の寿命には決まった型があります。公開から約 2 年は「アクティブサポート」で、不具合もセキュリティの問題も修正されます。その後の約 2 年は「セキュリティサポート」で、重大なセキュリティの問題だけが修正されます。

たとえば 8.2 は、アクティブサポートが 2024年12月31日に終わり、いまはセキュリティサポートだけの時期にあります。今回のような緊急の修正が出ても、2026年12月31日を過ぎれば、同じ対応は受けられません。8.3 は 2027年12月31日、8.4 は 2028年12月31日が期限です。

この型を知っていると、移行の時期は逆算できます。セキュリティサポートの終了日の半年から 1 年前を目安に、次の系統での動作確認を始めておけば、期限の直前に慌てることはありません。今回のように、公式が前日に予告する緊急の更新が出たときも、同じ系統の最新版へ上げるだけで済みます。系統をまたぐ大きな移行と、同じ系統の中の小さな更新を、分けて考えておくことが大切です。

更新を終えた後に確認すること

作業が終わったら、次の点を確かめましょう。

1. 実際にサイトを動かしている PHP が、修正版以降になっていること。
2. PHP-FPM や Apache、コンテナを、再起動または再デプロイしたこと。
3. 暫定対処を入れていた場合、意図した値が反映されていること。
4. 使っていない機能は、更新後も無効のままにしておくこと。たとえばセッションのアップロード進捗は、使わないなら無効にしておく、とアドバイザリも勧めています。

異常な兆候があれば、サイトのファイルが改ざんされていないかを調べ、データベースの接続情報などを変更します。攻撃が成功した場合、実行されるのは Web サーバーのアカウントの権限です。そのアカウントが読めるものは、すべて危険にさらされたと考えるのが安全です。

今日のうちに、版数の確認から始めましょう

ここまでを整理します。

• 2026年10月21日に、PHP の重大な脆弱性 2 件（CVE-2026-109618・109619）の修正版が出ました。
• どちらも CVSS v4.0 で 9.2 の緊急で、認証なしの遠隔コード実行につながりえます。
• 原因は、メモリ不足の後始末の誤りと、前の要求の状態が残ることです。
• 確実な対策は、8.5.12・8.4.27・8.3.36・8.2.35 以降への更新と、再起動です。
• 暫定対処は時間稼ぎで、完全な対策ではありません。
• 8.2 は 2026年12月31日にサポートが終わるため、次の系統への移行も計画します。

最初の一歩は、とても小さなものです。php -v を実行して、いまの版を確かめる。それだけで、自分の環境が安全な側にあるのか、今日動くべきなのかが分かります。修正版になっていれば、再起動の有無を確認して終わりです。まだなら、今日のうちに更新の段取りを決めてください。更新と再起動という、地味で確実な作業が、サイトとその先の利用者を守ります。