COLUMN
PHP脆弱性のセキュリティ更新｜深刻度9.2の修正版が公開。添付フォームの無いサイトも対象です
PHPに、深刻度9.2（CVSS v4.0）の脆弱性が2件見つかりました。
修正版の8.5.12・8.4.27・8.3.36・8.2.35が、日本時間の2026年10月21日23時に公開されています。
Webのリクエストを処理するPHPはすべて対象で、ファイルを添付するフォームが無いサイトも含まれます。
PHPの公式は、完全な回避策は無く、更新だけが安全だとしています。
この記事では、Webサイトを持つ企業・団体の担当者と、サーバーを管理する方に向けて、何が起きたかと、版の確認から本番の更新までの順番をまとめます。
私たちもCMSを作って運用する立場として、10月21日の夜に、管理しているサーバーの確認を始めました。
CVE-2026-109618・109619で起きていること
2件とも、認証なしで、外からサーバー上の任意のコードを実行される恐れがあるものです。
対象は、Webのリクエストを処理するすべてのPHPです。
PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedのどれで動かしていても当てはまります。
修正版より前の版は、すべて影響を受けます。
CVE-2026-109618は、メモリ不足で処理を打ち切ったときの後片付けの問題です。
作りかけの内部データが残り、終了の処理がそれを正しいデータとして扱ってしまいます。
送られてきたデータを読み取る途中でメモリ不足を起こさせることで、この状態が作られます。
CVE-2026-109619は、1回のリクエストのための内部の状態が、解放された後もワーカーに残る問題です。
同じワーカーが次のリクエストを処理するとき、初期化の前にその残りを参照してしまいます。
入口のひとつは、初期設定で有効になっているアップロードの進み具合の機能（session.upload_progress）で、アプリが session_start を呼んでいなくても通ります。
いちばん危ないのはmod_phpです。
認証のないリクエストで、アプリのコードが動く前に攻撃が成り立つことが、研究者の検証で示されています。
PHP-FPMでも、アプリ側の条件つきで、任意のコードの実行まで確かめられています。
実際に悪用されているかどうかは、公式のページには書かれていません。
悪用されたとも、されていないとも書いていないので、私は「まだ分からない」ものとして扱っています。
ファイル添付のフォームが無いサイトも対象です
「うちのサイトにはファイルを送るフォームが無いから関係ない」と考えたくなりますが、そうではありません。
狙われるのは、PHPがアプリより前に受け付ける、リクエストの読み取りの部分です。
アプリにアップロードの機能があるかどうかとは別に、Webに公開されているPHPがあれば対象になります。
CVE-2026-109618の公式の案内でも、ファイル送信の形式（multipart）を使わないアプリは、PHPの手前でその形式のリクエストを止めるよう書かれています。
お問い合わせフォームだけのサイトも、会社案内だけのサイトも、CMSでお知らせを更新しているサイトも同じです。
既製のCMSでも、自社で作ったシステムでも、PHPで動いていれば当てはまります。
修正版の番号と、8.1以前・レンタルサーバー・remiの扱い
修正版は次の4つです。
8.5系は8.5.12、8.4系は8.4.27、8.3系は8.3.36、8.2系は8.2.35です。
同じ系列でこれより前の版を使っている場合は、修正版への更新が要ります。
8.1以前を使っている場合
8.1以前には、公式の更新版は出ません。
公式は、7.4・8.0・8.1向けに、最小限の修正をソースコードの差分としてGitHubのブランチで出しています。
自分でPHPを組み立てて入れ直せる体制がなければ、8.2以上へ上げる計画を急ぐことになります。
8.2も2026年12月31日でサポートが終わるので、上げるなら8.3以上を選ぶほうが、次の入れ替えまでの時間を取れると私は思います。
OSに付いてくるPHPを使っている場合
Linuxの配布元（ディストリビューション）や長期サポートの事業者には、公式から事前に修正が渡されています。
PHPの公式も、配布元の更新パッケージを確認するよう案内しています。
配布元のパッケージは、修正を取り込んでも版の番号が上の4つと違うことがあります。
配布元の更新情報で、今回の2つのCVE番号が直っているかを確かめてください。
remiのパッケージを使っている場合
有志が運営しているremi（rpms.remirepo.net）のパッケージを使っている場合は、注意が要ります。
PHP公式の告知には、remiは公開の当日には更新を出さないと書かれていました。
公式は、配布元のパッケージへ切り替えるか、ソースから組み立てることを勧めています。
レンタルサーバーを使っている場合
レンタルサーバーでは、PHP本体の更新は事業者が行います。
利用者ができるのは、事業者のお知らせを確かめることと、管理画面でPHPの版を選べる場合に、どの版が選べるようになっているかを見ることです。
8.1以前を選んだままのサイトは、事業者の対応とは別に、版を上げる計画が要ります。
更新の順番：版の確認、バックアップ、検証、本番の更新
1. 動いているPHPの版を確かめる
サーバーに入れる場合は、php -v で版を確かめます。
ただ、コマンドで動くPHPと、Webのリクエストを処理しているPHPが、別の版のことがあります。
PHP-FPMやApacheが使っている版も、サービスの設定から確かめておきます。
確かめるために phpinfo() のファイルを公開フォルダに置く方法は、消し忘れると別の穴になるので、私たちは使っていません。
複数のサーバーを持っている場合は、サーバーごとに「今の版」「上げる先の版」「担当者」を1行ずつの表にします。
私たちも10月21日の夜に、管理しているサーバーのPHPの版の一覧を作り直し、どこまで上げるかを書き足しました。
一覧があると、「配布元の更新を待てば直るサーバー」と「待っても直らないサーバー」を分けて考えられます。
2. バックアップを取る
更新の前に、データベースとファイルのバックアップを取ります。
PHPの版を上げると、古い書き方のコードが動かなくなることがあります。
戻せる状態を作ってから触ることは、急ぐ時ほど大事だと私は思います。
3. 検証の環境で動かしてみる
検証用のサーバーやローカルの環境があれば、先に同じ版へ上げて、主なページとフォームの送信、管理画面のログインを確かめます。
同じ系列の中の更新（8.3系から8.3.36へ、など）は、系列をまたぐ更新より影響が小さいのが普通です。
系列をまたぐ場合は、確認の範囲を広げます。
4. 本番を更新して、ワーカーを再起動する
本番を更新したら、PHP-FPMやApacheを再起動して、新しい版が実際に動いていることを確かめます。
パッケージを入れ替えただけでは、古いプロセスが動き続けていることがあるからです。
最後に、サイトの表示、フォームの送信、管理画面のログインをもう一度確かめます。
更新までの公式の暫定策（更新の代わりにはなりません）
すぐに更新できないサーバーのために、公式は攻撃の入口を減らす設定を案内しています。
ただし、公式自身が「完全な回避策は無い」としています。
次の設定は時間を稼ぐためのもので、更新を先送りしてよい理由にはなりません。
session.upload_progress.enabled=0を、php.ini、PHP-FPMのプールの設定、サーバーの設定のいずれかで入れ、すべてのワーカーを再起動する。ini_set()や.user.iniでは効きません。post_max_sizeを、アップロードが要らなければ8M、要るなら32Mにする。upload_max_filesizeはpost_max_sizeより小さくする。memory_limit=-1をphp_admin_valueで固定し、下の階層の設定で戻されていないか確かめる。cgroupなど、ワーカー単位のメモリの上限と組み合わせる。- PHP 8.5では
fatal_error_backtraces=0にして、すべてのワーカーを再起動する。 - リクエストのたびに当たる、誤った設定や非推奨の設定（初期化の前に警告を出すもの）を取り除く。
error_reporting・display_errors・@では防げません。 - Webサーバーやプロキシで、リクエストの大きさ、入力項目の数、multipartの部品の数、ヘッダーの数、入れ子の深さを制限する。Content-Lengthの無いリクエストにも効くようにする。
ファイルを受け取る機能が無いURLなら、multipart形式のPOSTをWebサーバーの段階で止めるのが、効き目の分かりやすい対策だと私は思います。
mod_phpで動かしている場合は、.htaccess の php_value などで、リクエストのたびに警告が出ていないかも見ておきます。
私たちが管理しているサーバーで、10月21日の夜にしたこと
私たちが管理しているサーバーでは、10月21日の夜に次のことをしました。
特別な道具は使っていません。
どれも、上の公式の案内と、普段の点検の延長です。
- PHPの版の一覧を作り直し、サーバーごとにどこまで上げるかを書き足した。
- ファイルを受け取る機能が無いURLへの、multipart形式のPOSTを、PHPに渡る前にWebサーバーで止めた。
- 管理用のAPIのファイル受け取り口を、認証が無いと使えないようにした。アップロード先のフォルダでは、スクリプトを実行させない設定にした。
- 公開フォルダに残っていたPHPの控えファイルを外し、控えファイルを配信しない設定にした。
修正版は、配布元の修正パッケージが出たものから順に入れていきます。
私たちが管理しているサーバーにも、サポートの終わったOSで、通常の更新では修正版が入らないものがありました。
そのサーバーは、暫定策で入口を減らしながら、新しい環境への切り替えを前倒しにしています。
今回あらためて感じたのは、緊急の時に効くのは、普段から持っている版とサポート期限の一覧だということです。
一覧が古いと、どのサーバーから手を付けるかを決める前に、調べ直す時間がかかります。
コンテナを使っている方へ
私たちが作っているCMS「コンテナ」も、PHPで動いています。
今回の脆弱性はPHP本体にあるので、直すにはCMSではなく、サーバーのPHPを更新します。
コンテナで作ったサイトを運用している方は、サーバーのPHPの版を確かめ、修正版への更新をお願いします。
コンテナの「DB・バックアップ」の機能を使っている場合は、更新の前のバックアップをそこから取れます。
版の確かめ方や更新の順番で分からないことがあれば、お問い合わせからご相談ください。
コンテナのセキュリティ機能を見る
DB・バックアップの機能を見る
お問い合わせ
※ この記事は、一次資料の調査と下書きをAI（Claude）が行い、内容の確認と公開の判断は人が行っています。