PHP の脆弱性（2026年10月）：自分の PHP は当たる？確かめ方と上げる版

日本時間の2026年10月21日23時ごろ、PHP の開発元が、重大な脆弱性2件を直した新しい版を出しました。脆弱性とは、悪用されると困ることが起きうる、ソフトウェアの弱点のことです。2件とも、ログインなしで、外から機械を好きに動かされる恐れがあると書かれています（ここでの「機械」は、PHP が動いているサーバーのことです。専門の言葉では「リモートコード実行」、略して RCE と呼びます）。

先に答えを書きます。当たるかどうかは、PHP の版で決まります。直った版は、8.5 系が 8.5.12、8.4 系が 8.4.27、8.3 系が 8.3.36、8.2 系が 8.2.35 です。自分の PHP がそれより前なら、上げます。ただし版の見方は、入れ方で変わります。

公式のソース・Docker・Homebrew で入れた PHP: php -v の番号をそのまま比べます
OS のパッケージ（Ubuntu などの OS が配る PHP）: 番号が古いままでも直っていることがあります。OS の告知に書かれた「パッケージの版」を見ます
レンタルサーバーで WordPress を動かしている: 管理画面の「ツール」→「サイトヘルス」で番号を見られます。直ったかどうかは提供元のお知らせで確かめます（→「レンタルサーバー（WordPress など）・製品の中の PHP：提供元のお知らせを見る」）

この記事は、PHP で動くサイトやアプリを持っている人、サーバーを借りて WordPress などを動かしている人に向けて、「何があったか → 自分の PHP は当たるか → 確かめ方 → すぐ上げられないときの手立て → 古い PHP」の順に書きました。書いてあることは、PHP の公式の告知、GitHub の告知、各 OS の告知などを、2026年10月22日（日本時間の昼）に開いて確かめたものです。悪用の状況は日々変わるので、時刻を添えました。脆弱性を突く操作は、していません。

この記事でわかること

10月21日に出た2件は何か（外から機械を好きに動かされる恐れ）。点数は誰が付けたものか。悪用は確認されているか（2026年10月22日時点）
自分の PHP が当たるかは、版で決まること。直った版（8.5.12・8.4.27・8.3.36・8.2.35）と、動かし方の違いの読み方
入れ方ごとの確かめ方（php -v で足りる入れ方と、OS のパッケージの版を見る入れ方、レンタルサーバー）
すぐ上げられないときの、公式の手立てと、それが「つなぎ」でしかないこと
8.1 以前の古い PHP はどうなるか、8.2 のサポート（直しが出る期間）の期限（2026年12月31日）、9月24日の直しとの関係

10月21日に、PHP に何があった？
自分の PHP は当たる？版で決める
どうやって確かめる？入れ方ごとの見方
すぐ上げられないときは？公式の手立て
8.1 以前の古い PHP と、サポート（直しが出る期間）の期限は？
9月24日の直しは、どうなっている？
よくある質問
まとめ
参考資料

10月21日に、PHP に何があった？

PHP の公式サイト（php.net）は、2026年10月21日に、PHP 8.5.12・8.4.27・8.3.36・8.2.35 を出しました。ニュースの見出しは「Security advisory: Critical remote code execution vulnerabilities, update now」（セキュリティの注意。重大な、遠隔でコードを実行されうる脆弱性。今すぐ更新を）です。本文は、2件の重大な脆弱性が、認証なしの遠隔からのコード実行につながりうると書き、すべての PHP の利用者に、すぐ更新するよう強く勧めています。4つの版の告知は、どれも「security release（セキュリティの修正のための版）」で、2件の CVE 番号（脆弱性に付ける世界共通の番号）を挙げ、「完全な手立ては無く、更新するのが唯一の安全な選択」とも書いています。

下の表の GHSA は、GitHub の告知につく番号です。

	1件目	2件目
CVE 番号	CVE-2026-109618	CVE-2026-109619
GitHub の告知の番号	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
告知の見出し	RCE via OOM corruption	RCE via stale global state
見出しの意味	メモリ不足の処理で、内部のデータが壊れる	古い状態が残る
告知の重大度	critical	critical

OOM は Out Of Memory の略で、メモリ（作業に使う場所）が足りなくなることです。

1件目（CVE-2026-109618）：メモリ不足のときの扱い

まず、たとえ話で壊れている場所を見ます。

料理店の厨房で、仕込みの途中で材料が足りなくなり、作業が途中で打ち切られました。台の上には、準備が半分のままの物が残っています。ところが、あとから来た片付けの係は、それを「準備が済んだ物」だと思い込んで、いつもどおりに扱ってしまいます。壊れているのは、この「準備が半分の物を、済んだ物と思い込む」ところです。

告知の言い方では、こうなります。メモリが足りなくなったとき、PHP が、1回分の要求（Web サイトに届いた 1 回のアクセス）の内部のデータを、半分だけ準備した状態のまま打ち切ってしまうことがあります。そのあとの後始末の処理が、壊れたデータを、正しいものとして扱ってしまいます。たとえ話の、準備が半分の物は1回分の要求の内部のデータ、片付けの係は後始末の処理に当たります。PHP Foundation（PHP の開発を助ける団体）は、同じ件を、PHP のメモリの上限の設定（memory_limit）に、ちょうど悪いときに達すると起きる、と書いています。この壊れ方がもとで、外から機械を好きに動かされる恐れがあります。

2件目（CVE-2026-109619）：古い状態が残る

こちらも、たとえ話で壊れている場所を見ます。

お店のレジで、前のお客さんの用事が途中で止まり、そのお客さんの品物の置き場所を書いたメモが、レジに残りました。その品物は、もう片付けてあって、そこにはありません。次のお客さんを同じ店員が受けるとき、店員はメモを書き直す前に、古いメモを見て動いてしまいます。壊れているのは、「片付けたはずの品物の置き場所を書いた、古いメモが残る」ところです。

ここで worker とは、要求を順に受け持つ PHP のプロセス（動いている 1 つの PHP）のことで、たとえ話の店員に当たります。告知の言い方では、こうなります。1回分の要求が持っている内部の状態が、その元になっていたメモリが解放されたあとも、残ってしまうことがあります。同じ worker が次の要求を受けるとき、通常の初期化（状態を書き直す処理）が済む前に、その古い状態を使ってしまうことがあります。解放したあとのメモリを使ってしまう弱点は、use-after-free（解放後の使用）と呼ばれます。

PHP Foundation は、まずい場所で fatal error（続けられない重大なエラー）が起きると、前の要求のメモリを指したままの状態が残る、と説明しています。GHSA は、worker を増やしたり入れ替えたりすると、1回ごとの成功は減るが、条件は消えない、と書いています。この壊れ方も、外から機械を好きに動かされる恐れにつながります。

2件とも、直すのが難しい場所にありました

PHP Foundation は、2件とも、ほとんどの要求が通る場所（メモリの管理とエラーの処理）にあるため重大で、今までの動きや速さを壊さずに直すのが難しかった、と書いています。GHSA によると、1件目は、メモリ不足のときに途中から飛び出す仕組みをやめ、安全な場所で止まるようにしました。2件目は、要求をまたいで残る状態を、メモリを解放する前にきちんと戻すようにしました。

点数は、誰が付けたもの？

点数は、見る場所で違います。CVSS は、脆弱性の深刻さを点数で表す共通の方式で、4.0 や 3.1 は方式の版です。どちらかに揃えず、「誰が、どの版で付けた点か」を並べます。

出どころ	付け方	2件とも
PHP（GitHub の告知）	CVSS 4.0	9.2（critical）
NVD（アメリカの脆弱性のデータベース）	CVSS 3.1	9.8（NVD 自身が付けた点。PHP の 4.0 の 9.2 も並べて載せている）
Red Hat	CVSS 3.1	8.1。重大度は「Important」
Ubuntu	優先度	critical

違いの一つは、ベクター（点数の中身を並べた文字列）の AC（攻撃の複雑さ）で、PHP と Red Hat は H（高）、NVD は L（低）です。

出回った噂の点数「10.0」は間違いで、本当は 9.2 だと PHP Foundation は書いています。10月20日に CVE 番号と間違った点数 10.0 が出回ったため、PHP は公開を予定より1日早い10月21日にした、と PHP Foundation は書いています。点が高いことと、自分が受ける被害の大きさは別です。読み方は、脆弱性の知らせの読み方にまとめています。

悪用は確認されている？（2026年10月22日時点）

2026年10月22日 13時20分〜13時50分ごろ（日本時間）に確かめた範囲では、悪用が確かめられた、という文は見つかりませんでした。CISA（アメリカの政府機関）の KEV（悪用が確認された脆弱性の一覧。版 2026.10.21、1754件）に2件とも載っておらず、CVE の記録に CISA が付けた「悪用の状況」の欄（SSVC という評価の一部）も、2件とも「なし」（none）です。IPA（情報処理推進機構）は、10月21日の文書で「現時点でIPAが悪用した攻撃を確認しているわけではありません」と書き、予防のために発信すると説明しています（10月22日の文書には、悪用の有無の文はありません）。

JPCERT/CC（日本のセキュリティの情報を扱う組織）は10月22日に注意喚起（JPCERT-AT-2026-0033）を出し、国内で広く使われていることを確かめたうえで、速やかな対策と、侵害を受けていないかの調査を勧めています。悪用を確かめた、という文はありません。侵害を受けていないかの調べ方は、注意喚起の「V. 侵害調査」にあります（痕跡が見つからなくても、攻撃を受けていないとは言い切れない、とも書いています）。JVN（JPCERT/CC と IPA の脆弱性情報）の JVNVU#99905564（10月22日）にも、悪用についての文はありません。

一方で、PoC（弱点が本当にあることを示すための試しのコード）の話があります。PHP Foundation（2026年10月21日付のブログ）は、報告した会社の1つが誤って PoC の動画を出し、その写しが出回り、動画をきっかけに PoC づくりが早まって、10月21日に出回りが増えたと書き、PHP のセキュリティチームは出回った PoC を調べたが、公開の時点では使える攻撃は見つけていなかった、とも書いています（報告者が示した攻撃とは別の話です）。

PoC が出回っていることと、悪用が確認されていることは、別です。脆弱性の知らせの読み方にあるとおり、PoC は悪用に数えません。また、KEV に無いことは、悪用されていない証明ではありません。上に書いたのは、この時刻までに見つかった範囲です。

出典: php.net のニュース（2026年）・GitHub の告知（GHSA-w8hw-w9fx-j79w・GHSA-6wmf-4rv5-p3rp）・PHP Foundation のブログ・NVD: CVE-2026-109618・CVE の記録・CISA: KEV・JPCERT/CC: 注意喚起 JPCERT-AT-2026-0033・JVNVU#99905564・IPA: 10月21日の文書・IPA: 10月22日の文書

自分の PHP は当たる？版で決める

当たる版と、直った版

CVE の記録（番号を付けたのは PHP 自身）と IPA の書き方に合わせると、次の表になります。

系統	当たる版	直った版
8.5 系	8.5.12 より前の 8.5 系	8.5.12
8.4 系	8.4.27 より前の 8.4 系	8.4.27
8.3 系	8.3.36 より前の 8.3 系	8.3.36
8.2 系	8.2.35 より前の 8.2 系	8.2.35

読み方は「同じ系統の中で、直った版より前なら当たる」です。たとえば 8.3.35 は 8.3 系なので、8.3.36 より前で当たります。8.2.35 は 8.2 系の直った版なので、当たりません。GitHub の告知の欄は「8.3.36 より前」のように、系統の下の端を書いていません。そのまま読むと 8.2.35 も入るように見えますが、8.2 系は 8.2.35 で直っています。系統ごとに読んでください。

8.1 以前は、この表にありません。「8.1 以前は当たらない」という意味ではありません。理由は、あとの「8.1 以前の古い PHP と、サポート（直しが出る期間）の期限は？」の節で書きます。

上げる先は、表の「直った版」です（php.net の告知が「PHP 8.5.12・8.4.27・8.3.36・8.2.35 のどれかに更新する」と書いています）。ソースは php.net の downloads のページにあり、Windows のソースとバイナリ（すぐ動かせる形に作ってある物）も同じページです。

動かし方の違いは、急ぐ度合いで見る

PHP は、Web の要求を受ける動かし方がいくつかあります。この動かし方の種類を SAPI（Server API。PHP が外とやり取りする入り口の種類）と呼びます。この記事によく出てくるのは次の 2 つです。mod_php は、Apache（Web サーバーのソフト）の中に PHP を組み込む形です。FPM は FastCGI Process Manager の略で、PHP を別のプロセスとして動かし、Web サーバーから要求を渡す形です。

php.net の「誰が危ないか」の文は、次のとおりです。

"Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed."

訳すと、「Web の要求を受ける PHP は、すべて危ない。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を含む」です。つまり、動かし方で当たる・当たらないを分けてはいません。当たるかは版で決めます。

そのうえで、php.net は「いちばん危ないと見ているのは mod_php」と書いています。アプリのコードが動き出す前に、認証なしの要求で起こせる、動く攻撃が示されたからです。GitHub の告知も、動かし方ごとの見立てを書いています。

動かし方	GitHub の告知などの見立て
mod_php	1件目は、アプリ固有のコードが動き始める前に起こる。HTTP 越しの完全なコード実行が、PHP の既定の入力とメモリの上限のまま、確かめられた。2件目も、fatal error のときの backtrace（エラーの記録）の経路で、コード実行が確かめられた
FrankenPHP	1件目の告知は、mod_php に近く、アプリに関係なく狙われやすいと見ている（ソースの分析による）
LiteSpeed	1件目の告知は、FPM に近く、アプリごとの攻撃はありそうだが、確かめられてはいない、と書く
PHP-FPM	次の表のとおり。書き方が食い違っている

PHP-FPM は、文書によって書き方が違います。原文のまま並べます。

出どころ	1件目（CVE-2026-109618）について	2件目（CVE-2026-109619）について
php.net の告知	動かし方の一覧に FPM を含める	同じ
GitHub の告知	FPM は「当たりうる」。ただし、FPM では完全な攻撃はまだ示されていない（"no complete FPM exploit has been demonstrated for this SAPI"）	セッションの経路でのコード実行が、mod_php と FPM の両方で確かめられた（"Session lifecycle RCE was validated against mod_php and FPM."）。ふつうの動的な FPM のプール（FPM が用意する worker のまとまり）で動くが、適したアプリの操作にも左右される
PHP Foundation のブログ	FPM でも、アプリの経路を通して、コード実行が確かめられた（"Remote code execution was also confirmed on PHP-FPM through application-level code paths."）	mod_php の上で動く実際のアプリを使った例を書き、FPM のことは書いていない
Red Hat	説明文では、FPM でもアプリの段階の経路でコード実行に至りうると書く（"against FPM through application-stage paths"）。一方、評価の注（Statement）では、一般の RHEL（Red Hat の Linux）の構成は FPM で、早い段階の失敗で子プロセスが終わるため、コード実行は現実的には難しく、ふつうは既定でない動きが要る、と書く	FPM は、アプリの段階の経路を通して、条件つきで当たる（"FPM is conditionally affected through application-stage paths."）

FPM で確かめられた件が、文書によって違います（GitHub の告知は 2 件目、PHP Foundation は 1 件目）。Red Hat は、1件目について、RHEL の普通の構成（FPM）では現実的には難しいと見ていますが、FPM も当たりうるとも書いています（2件目は「条件つきで当たる」）。どれが正しいかは、この記事では決めません。「FPM なら安全」とは読めません。かといって、「FPM でも 2 件とも動く攻撃がある」とも書けません。 FPM も当たる対象に入っているので、版で決めて上げます。動かし方の違いは、「どれくらい急ぐか」の目安としてだけ使ってください。mod_php を使っているなら、最優先です。

自分の PHP の動かし方は、php_sapi_name()（定数 PHP_SAPI）で分かります。値の例は、apache2handler（Apache の mod_php）、fpm-fcgi、cgi-fcgi、cli、litespeed などです。ただしコマンドラインで呼ぶと cli と出るだけです。Web サーバーの中の動かし方を確かめる手順は、この記事では確かめていません。分からなくても、やることは版を上げることです。

コマンドラインだけの PHP は？

コマンドラインで動かす PHP（定期的に動かす処理など）が当たるかは、どの文書にも書かれていません（php.net の告知・2件の GitHub の告知・PHP Foundation のブログを見ました）。php.net が書いているのは「Web の要求を受ける PHP」です。念のため版を比べ、直った版より前なら上げておくのが無難です。

出典: php.net のニュース（2026年）・CVE の記録・IPA: 10月22日の文書・GitHub の告知（GHSA-w8hw-w9fx-j79w・GHSA-6wmf-4rv5-p3rp）・PHP Foundation のブログ・Red Hat のデータ（CVE-2026-109618・CVE-2026-109619）・PHP マニュアル: php_sapi_name

どうやって確かめる？入れ方ごとの見方

PHP は、入れ方によって、版の見方が変わります。いちばん大事な違いは、「php -v の番号をそのまま本家の番号と比べてよいか」です。自分の入れ方の行を見つけたら、その節だけ読めば足ります。

入れ方	見るもの	比べる相手
公式のソース、Windows の公式のバイナリ	`php -v` の番号	8.5.12・8.4.27・8.3.36・8.2.35 以上か（同じ系統で）
公式の Docker イメージ（`php`）	イメージを `docker pull` し直したあとの、コンテナの中の `php -v`	同じ
Homebrew	`php -v` の番号	同じ
OS のパッケージ（Ubuntu・Debian・RHEL・Alpine）	パッケージの版	その OS の告知に書かれたパッケージの版（USN・DSA・RHSA は、どれも各 OS の告知の名前）
レンタルサーバー、製品の中の PHP	提供元のお知らせ	提供元が書く「対応済みか」

公式のソース・Windows・Docker・Homebrew：php -v の番号を見る

この入れ方は、版の番号が本家の番号と同じです。php -v の番号が、自分の系統の直った版以上かを見ます。

公式の Docker イメージ php:8.3-cli の中で php -v を流した出力は、次のとおりです（2026年10月22日の13時台に、macOS 14.4.1 の Docker 28.3.2 のコンテナの中で取りました）。

$ php -v
PHP 8.3.36 (cli) (built: Oct 21 2026 16:02:39) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.36, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.36, Copyright (c), by Zend Technologies

1行目の 8.3.36 が版です。8.3 系の直った版は 8.3.36 なので、この PHP は直っています。(cli) は、動かし方の名前（コマンドラインの PHP）です。同じイメージで、動かし方を2通りの方法で見た出力も載せます。php -i は、PHP の設定を全部表示する命令（phpinfo()）で、grep で 1 行に絞っています。

$ php -r "echo php_sapi_name(), PHP_EOL;"
cli
$ php -i | grep -i "^Server API"
Server API => Command Line Interface

コマンドラインで見た結果は cli です。Web の要求を受ける FPM や mod_php の動かし方は、これでは分かりません。

Docker: 公式の php イメージの定義のファイル（docker-library の official-images）は、2026年10月21日15:16 UTC（日本時間では10月22日の0時16分）に、8.5.12・8.4.27・8.3.36・8.2.35 に変わりました。定義のファイルでは、php:8.3（と 8.3-apache・8.3-fpm）は、それぞれ 8.3.36 の同じ種類の物を指しています。8.5・8.4・8.2 も同じで、php:latest は 8.5.12 です。手元に前から置いてあるイメージは、docker pull し直すまで古いままかもしれません。pull し直してから、動かしているコンテナの中で php -v を見て、番号を比べてください。

Homebrew: 2026年10月22日の13時台に見た式（formula）の版は、php が 8.5.12、php@8.4 が 8.4.27、php@8.3 が 8.3.36、php@8.2 が 8.2.35 でした。4つとも直った版です。

公式のソースと Windows: 上げる先は php.net の downloads のページです。Windows のソースとバイナリも、同じページにあります。

有志が運営する RPM の配布元: php.net の告知は、有志が運営する RPM（Red Hat 系の Linux で使われるパッケージの形式）の配布元（rpms.remirepo.net）を使っている人に、OS の配布元のパッケージか、ソースからのビルドに移るよう強く勧めました。php.net の告知は、この配布元には告知の日（10月21日）には更新が出ない、とも書いていました。その後の更新は、確かめていません。

OS のパッケージ：番号ではなく、パッケージの版を見る

Ubuntu・Debian・Red Hat などの OS は、PHP を自分たちで管理して、パッケージとして配ります。新しい版に上げる代わりに、本家の直しを配っている古い版に取り込む（backport）のが、それぞれの文書に書かれた基本のやり方です（Ubuntu は、ふつうは新しい機能は入れません）。Red Hat は、ときには版を上げることもある、とも書いています。

ここで大事なことがあります。「OS のパッケージは、番号が古いまま」とひとくくりにはできません。 今回の 2 件でも、本家の新しい番号を入れた OS と、古い番号のまま直した OS がありました。だから、番号ではなく、OS の告知に書かれた「パッケージの版」と比べます。

Ubuntu 24.04 の例を見ます。ubuntu:24.04 のコンテナ（上と同じ環境）に、apt で php8.3-cli を入れて流した出力です。

$ php -v
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies
$ dpkg -l php8.3-cli
ii php8.3-cli 8.3.6-0ubuntu0.24.04.13

dpkg -l の出力は、列を詰めて、名前と版だけにしてあります。php -v は 8.3.6 と出ます。本家の番号では、8.3.36 より前です。ところが、パッケージの版 8.3.6-0ubuntu0.24.04.13 は、Ubuntu の告知 USN-8948-1 が「直った」とする版と同じです。本家の番号は 8.3.6 のままでも、直っているのです。php -v が 8.3.36 より下だから当たる、と決めつけないでください。

OS ごとの告知と、直ったパッケージの版は次のとおりです（2026年10月22日の13時台に見た内容です）。自分の OS の所だけ見てください。

Ubuntu（告知 USN-8948-1。2026年10月21日。ESM の古い Ubuntu は別の告知 USN-8948-2）。告知は、ふつうのシステムの更新で、必要な変更が全部入ると書いています。

Ubuntu	パッケージ	直った版
26.10	php8.5	8.5.9-0ubuntu2.1
26.04 LTS	php8.5	8.5.4-0ubuntu1.5
24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
22.04 LTS	php8.1	8.1.2-1ubuntu2.28
20.04（ESM）	php7.4	7.4.3-4ubuntu2.29+esm5
18.04（ESM）	php7.2	7.2.24-0ubuntu0.18.04.17+esm14
16.04（ESM）	php7.0	7.0.33-0ubuntu0.16.04.16+esm22
14.04（ESM）	php5	5.5.9+dfsg-1ubuntu4.29+esm18

ESM は、延長されたセキュリティ保守のことです。26.04 の標準の PHP は 8.5 です（Ubuntu 26.10 と 26.04 LTS の記事でも紹介しています）。

Debian（2026年10月21日の告知）。今回は、本家の新しい番号を入れています。

Debian	告知	パッケージ	直った版
13（trixie）	DSA-6574-1	php8.4	`8.4.27-1~deb13u1`
12（bookworm）	DLA-4848-1	php8.2	`8.2.35-1~deb12u1`

Red Hat（RHSA-2026:87070 など 7 つ。直ったパッケージの例は、Red Hat のデータ（VEX）から取りました）。

RHEL	パッケージ	直った版（例）
10.2	php	8.3.36-1.el10_2
9	php:8.3（モジュール）	8.3.36-1.module+el9.8.0+…（「…」は省略）
9	php:8.2（モジュール）	8.2.35-1.module+…（省略）
9	php（8.0 系）	8.0.30-8.el9_8.1（番号は 8.0.30 のまま）
8	php:7.4（モジュール）	7.4.33-8.module+el8.10.0+…（省略。番号は 7.4.33 のまま）

RHEL 9 の php:8.4 は、「known_affected（影響を受ける）」のままで、直しがまだありません（Red Hat のデータの更新は 2026年10月22日 01:57 UTC）。いつ出るかは、書かれていません。RHEL 6 と 7 は、1件目（CVE-2026-109618）は「調べている」、2件目（CVE-2026-109619）は「影響を受けない」（脆弱なコードが無い、という扱い）になっています（Red Hat のデータ、2026年10月22日 01:57 UTC／00:17 UTC 更新）。

Alpine: セキュリティのデータ（secdb）に、3.24 と edge（開発中の版）で、php83 の 8.3.36-r0、php84 の 8.4.27-r0、php85 の 8.5.12-r0 で 2 件が直った、と載っています。3.23 には、この 2 件の行がありません（3.23 の php83 の最後の直しは 8.3.31-r0）。3.23 にいつ載るかは、分かりません。

RHEL 系や Alpine で、パッケージの版を見るコマンドは、この記事では確かめていません。それぞれの OS の文書で確かめてください。

レンタルサーバー（WordPress など）・製品の中の PHP：提供元のお知らせを見る

WordPress を使っているなら、いまの PHP の番号は WordPress の管理画面でも見られます。左のメニューの「ツール」→「サイトヘルス」を開き、上の「情報」を押して、「サーバー」の行を開くと「PHP バージョン」の行があります（WordPress の文書によると、この画面は見るだけで、ここから設定は変えられません）。ただし、ここに出るのも PHP が名乗る番号なので、php -v と同じく、提供元が直しを取り込んでいる場合は番号だけでは決められません。番号が 8.1 以前なら、あとの「8.1 以前の古い PHP と、サポート（直しが出る期間）の期限は？」の節も読んでください。対応済みかどうかは、提供元のお知らせで確かめます。

借りているサーバーや、使っているサービスの PHP は、自分で入れていません。IPA は、自分の組織で開発・利用している製品などの影響は、その製品の開発者やサービスの提供元からの情報で確認するよう書いています。PHP は WordPress などの CMS（サイトを管理するソフト）の下でも動いているので、そうしたサイトを借りたサーバーに置いているなら、サーバーの提供元が出すお知らせ（PHP の更新のお知らせ）とマニュアルを見ます。この記事では、特定の会社の画面の手順は書きません。

IPA は、PHP が Web アプリだけでなく、ソフトウェア製品やネットワーク機器の内部でも使われていることがあり、使う側からは見えないことがある、とも書いています。その場合は、まず製品のマニュアルや、開発元・提供元のセキュリティ情報を見るよう勧めています。

出典: PHP のダウンロード（php.net のニュース）・PHP マニュアル: コマンドラインのオプション・Docker: 公式イメージの更新（PR #22541）・Docker: php の定義・Homebrew: php・Ubuntu: セキュリティ更新の考え方・USN-8948-1・USN-8948-2・Debian: セキュリティ FAQ・Debian: CVE-2026-109618・Debian: DSA-6574-1・Red Hat: backport とは・Red Hat のデータ（CVE-2026-109618・CVE-2026-109619）・Alpine: 3.24 のセキュリティのデータ・IPA: 10月21日の文書・IPA: 10月22日の文書・WordPress: サイトヘルス画面

すぐ上げられないときは？公式の手立て

この節は、php.ini（PHP の設定ファイル）や FPM の設定を自分で書き換えて、PHP を再起動できる人向けです。

先に、いちばん大事なことを書きます。上げるのだけが、完全な解決です。 php.net の告知は、次のように書いています。

"If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe."

訳すと、「すぐ更新できないなら、完全な解決は更新だけだが、次の手立ては特定の攻撃の道を減らす。ただし、安全にはしない」です。GitHub の告知も、1件目は「パッチの入った版に上げるのが、唯一の完全な緩和策」、2件目は「状態をすべて戻すパッチの入った版に上げるのが、唯一の確かな緩和策」と書いています。2件目の告知は、設定だけで完全に防ぐ方法は無い、とも書いています。

以下は、上げるまでの「つなぎ」です。やっても、安全になったとは言えません。設定を変えたら、全部の worker を再起動します。

1件目（CVE-2026-109618）への手立て

手立て	内容	注意
メモリの上限を外す	`memory_limit=-1`。アプリが上書きできない形（FPM のプールや Apache の設定の `php_admin_value`）で書く。どのプール・ディレクトリ・アプリの設定も、有限の上限を戻していないか確かめる	「PHP の上限に達して失敗する」場合を無くすだけ。その下で（OS からのメモリの確保そのものが）割り当てに失敗したときは、まだ起きうる、と告知は書く
`post_max_size` を小さくする	ファイルのアップロードが要らないなら 8M、要るなら 32M。`upload_max_filesize` は `post_max_size` より下にする	上限を下げるので、それより大きな送信は受けられなくなる
Web サーバーやプロキシで制限する	デコードしたあとの要求の大きさ・入力項目の数・multipart（ファイルなどを分けて送る形）の部品の数・ヘッダーの数・入れ子の深さ。`Content-Length` が使えない要求にも効くように	告知が挙げた項目のとおり
コンテナや cgroup の上限	サーバー全体が止まらないようにする仕切りとして使う。できれば、影響を受けた worker だけを終わらせる方針で	`RLIMIT_AS` や `RLIMIT_DATA` を代わりに使ってはいけない。脆弱な割り当ての失敗を、かえって起こしうる
入力を絞る（GitHub の告知）	`max_input_nesting_level` を減らす。入力変数の数・multipart の部品・各部品のヘッダー・アップロードの数に上限を置く	下の「設定の名前と、既定の値」の表を参照

2件目（CVE-2026-109619）への手立て

手立て	内容	注意
アップロードの進み具合の機能を止める	`session.upload_progress.enabled=0` にして、すべての worker を再起動する。php.ini・FPM のプール・サーバーの設定など、要求を読む前に効く場所で	`ini_set()` や FPM の `.user.ini` に頼らない。確かめられたセッションの道を塞ぐが、ほかの変形は塞がない
PHP 8.5 だけ	`fatal_error_backtraces=0` にして、すべての worker を再起動する	確かめられた backtrace の道だけを塞ぐ
要求ごとに当てている、無効・非推奨の設定を消す	初期化の前に診断のメッセージを出してしまう設定を、消します	`error_reporting`・`display_errors`・`@` でメッセージを隠しても効きません
攻撃者が届く場所の fatal error と、実行時間切れを直す	コールバック、アップロードや取り込みの処理、後始末での失敗も含めて直します	観察できたエラーを直せば減りますが、ログにエラーが出ないことは、安全の証拠ではありません
性能を気にしないなら	worker 1 つが受ける要求の数を `pm.max_requests=1` にする（GitHub の告知が挙げる）	残りの危険を減らす手立ての 1 つとして挙がる。上げる代わりにはならない

GitHub の2件目の告知は、直したあとでも、アップロードの進み具合の機能を使っていないなら、session.upload_progress.enabled=0 にしておくのが賢明かもしれない、と書いています。ほとんど使われず、ほとんど試験されていないこの機能の欠陥を、探す攻撃者が増えるからだそうです。この機能は、既定で有効です。

どれも、特定の道を減らすだけです。「設定を入れたから大丈夫」とは読まず、できるだけ早く、版を上げてください。

PHP の更新に限らない、サイトの守りの点検全体は、Web 開発のセキュリティの基本にまとめています。

設定の名前と、既定の値

設定	何の設定か	既定の値	使える版
`memory_limit`	1回の要求で使えるメモリの上限（`-1` は上限なし）	128M	版の注なし
`post_max_size`	POST（フォームなどで送るデータ）の大きさの上限。ファイルのアップロードにも関わる	8M	版の注なし
`upload_max_filesize`	アップロードできるファイル 1 つの大きさの上限	2M	版の注なし
`session.upload_progress.enabled`	アップロードの進み具合を、セッションの変数 `$_SESSION` に入れる機能	1（有効）	版の注なし
`fatal_error_backtraces`	fatal error に backtrace（エラーが起きるまでの呼び出しの記録）を付けるか	1（有効）	PHP 8.5.0 から
`max_input_nesting_level`	入力の入れ子の深さの上限	64	版の注なし
`max_input_vars`	入力の変数の数の上限	1000	版の注なし

既定の値と使える版は、PHP マニュアルの表のとおりです。fatal_error_backtraces は PHP 8.5 の新しい機能なので、8.4 以前には無い設定です。

出典: php.net のニュース（2026年）・GitHub の告知（GHSA-w8hw-w9fx-j79w・GHSA-6wmf-4rv5-p3rp）・PHP マニュアル（memory_limit などの表・ini の一覧・セッションの設定・fatal_error_backtraces）

8.1 以前の古い PHP と、サポート（直しが出る期間）の期限は？

8.1 以前は、PHP の開発元からは直しが出ない

php.net の告知は、8.1 以前について、次のように書いています。

"PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version."

訳すと、「8.1 以前は、PHP プロジェクトからもう更新が出ない。配布元や LTS（長期サポート）の会社が、直しを取り込んで（backport）出していることがあるので、問い合わせるか、サポート中の版に上げる」です。

CVE の記録が名前を挙げているのは 8.2〜8.5 だけです。ところが php.net は 7.4・8.0・8.1 にも直しを用意し、Ubuntu は 22.04 の php8.1 や ESM の古いパッケージも、Red Hat は 7.4.33 や 8.0.30 のパッケージも直しています。ですから、「8.1 以前は当たらない」とは決めないでください。IPA は、調査に関わった会社の話として、PHP 5.4 以降はどちらかの影響を少なくとも受ける、と伝えています（IPA が伝える二次の情報です）。

自分でビルドする人向けの、最小限の緩和

PHP のセキュリティチームは、7.4・8.0・8.1 について、ソースの直しを用意しました。php.net の告知は "minimal source-backports"（最小限のソースの移植）と書き、コミットの説明も "Minimal mitigation for EOL version"（サポートの終わった版への最小限の緩和）です。JPCERT/CC も「EOLバージョンに対する最小限の緩和策」と呼んでいます。名前のとおり「最小限」で、完全に直った物とは読めません。

誰向けかは、告知が「ソースからビルドする人と、LTS の会社のサポートを受けられない人」と書いています。置かれた場所は、php-src の GitHub の PHP-7.4-CVE-… など 3 つのブランチで、どれも「Avoid state corruption via bailout」という 1 つの変更です。新しい版の番号（7.4.34 など）は付いていません。つまり、リリースではありません。ブランチの中身（9月の直しが入っているかなど）は、この記事では開いていません。

IPA は、次の 3 つを書いています。

PHP 8.1 以前は「End of life（サポート終了）」で、今回の修正が出ない。その版を使っているなら、サポート中の PHP への更新や、対策済みの製品・サービスへの移行を考える
有効な手立てが難しいときは、被害や仕事への影響を踏まえて、外部からのアクセスの遮断やサービスの一時停止が必要かを判断する
サポートの終わった古い PHP を使い続けているサイトも見られる。攻撃者がこの脆弱性を悪用して、極めて短い時間で攻撃する可能性もあるので、パッチが出たら、できるだけ早く当てられるよう準備する

いつまで直しが出る？サポートの期限

PHP の各系統は、出てから 2 年間は全部の直しが出ます。その後の 2 年間は、重大なセキュリティの直しだけが出ます。4 年たつと、サポートが終わります（EOL。End Of Life）。表は、php.net の Supported Versions のページのとおりです。

系統	全部の直しが出る期限	セキュリティの直しが出る期限	今回の直し
8.2	2024-12-31	2026-12-31	8.2.35
8.3	2025-12-31	2027-12-31	8.3.36
8.4	2026-12-31	2028-12-31	8.4.27
8.5	2027-12-31	2029-12-31	8.5.12

8.2 は、2026年12月31日でセキュリティの直しも終わります。8.2.35 の告知にも、「8.2 は2026年12月31日にサポートが終わり、それ以降はセキュリティの直しが出ない。サポート中の版への更新を計画してほしい」という一文があります。8.2 を使っているなら、今回の 8.2.35 に上げたうえで、年内に次の系統へ移る計画を立ててください。

出典: php.net のニュース（2026年）・PHP: Supported Versions・CVE の記録・JPCERT/CC: 注意喚起 JPCERT-AT-2026-0033・IPA: 10月21日の文書・IPA: 10月22日の文書

9月24日の直しは、どうなっている？

9月24日にも、PHP のセキュリティの版（8.5.11・8.4.26・8.3.35・8.2.34）が出ています。10月21日の版（8.5.12・8.4.27・8.3.36・8.2.35）は、その続きの版なので、9月24日の直しも含みます。ChangeLog でも、8.3.36 は 8.3.35 の次の版です。つまり、9月24日の版に上げていなくても、10月21日の版に上げれば、一緒に直ります。9月24日の直しの一覧は、PHP の ChangeLogで読めます。

出典: php.net のニュース（2026年）・PHP の ChangeLog

よくある質問

PHP-FPM を使っています。安全ですか？

「安全」とは読めません。php.net の告知は FPM も当たる動かし方に含め、FPM で確かめられた件の書き方は、文書によって食い違っています（→「動かし方の違いは、急ぐ度合いで見る」）。

コマンドラインだけで使っている PHP（定期的に動かす処理など）は、当たりますか？

どの文書にも書かれていません。念のため版を比べ、直った版より前なら上げておくのが無難です（→「コマンドラインだけの PHP は？」）。

Docker の `php:8.3` は、もう直っていますか？

公式の php イメージの定義のファイルでは、php:8.3 は 8.3.36 と同じ物を指しています（2026年10月22日の13時台に見ました）。手元のイメージは docker pull し直して、コンテナの中で php -v の番号を比べてください（→「公式のソース・Windows・Docker・Homebrew：php -v の番号を見る」）。

Ubuntu で `php -v` が 8.3.6 と出ます。当たっていますか？

番号だけでは決まりません。Ubuntu 24.04 では、パッケージの版 8.3.6-0ubuntu0.24.04.13 以上なら、本家の番号が 8.3.6 のままでも直っています（Ubuntu の告知 USN-8948-1）。dpkg -l php8.3-cli などでパッケージの版を見て、告知の版より前なら更新が要ります（→「OS のパッケージ：番号ではなく、パッケージの版を見る」）。

RHEL 9 の php:8.4 や、Alpine 3.23 の PHP は、いつ直りますか？

分かりません（→「OS のパッケージ：番号ではなく、パッケージの版を見る」）。出るまでは、公式の手立てが「つなぎ」になります（→「すぐ上げられないときは？公式の手立て」）。

自分のサーバーで確かめること（チェックリスト）

自分の PHP の入れ方（公式のソース・Docker・Homebrew・OS のパッケージ・レンタルサーバー）を、分かっているか（→「どうやって確かめる？入れ方ごとの見方」）
入れ方に合った方法で、版を比べたか。公式のソース・Docker・Homebrew は、php -v の番号が自分の系統の直った版（8.5.12・8.4.27・8.3.36・8.2.35）以上か（Docker は docker pull し直したあとで見る）（→「公式のソース・Windows・Docker・Homebrew：php -v の番号を見る」）。OS のパッケージは、php -v の番号ではなく、告知に書かれたパッケージの版と比べる（→「OS のパッケージ：番号ではなく、パッケージの版を見る」）。レンタルサーバーや製品の中の PHP は、提供元のお知らせで確かめる（→「レンタルサーバー（WordPress など）・製品の中の PHP：提供元のお知らせを見る」）
mod_php を使っているなら、最優先で上げる予定を立てたか。「FPM だから安全」と読んでいないか（→「動かし方の違いは、急ぐ度合いで見る」）
すぐ上げられないときの手立てを、「つなぎ」と分かって入れたか。設定をアプリが上書きできない場所に書き、全部の worker を再起動したか（→「すぐ上げられないときは？公式の手立て」）
8.1 以前を使っていないか。8.2 なら、2026年12月31日までに次の系統へ移る計画があるか（→「8.1 以前の古い PHP と、サポート（直しが出る期間）の期限は？」）
侵害を受けていないかを、JPCERT/CC の注意喚起の「侵害調査」の節で確かめたか（→「悪用は確認されている？（2026年10月22日時点）」）

まとめ

2026年10月21日に、PHP 8.5.12・8.4.27・8.3.36・8.2.35 が出た。重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619）の直しで、どちらも、ログインなしで、外から機械を好きに動かされる恐れがある
点数は、PHP が CVSS 4.0 で 9.2（2件とも）、NVD が CVSS 3.1 で 9.8、Red Hat が 3.1 で 8.1（Important）。どこが、どの版で付けた点かを見る（出回った噂の 10.0 は間違い）。悪用の確認は、2026年10月22日 13時20分〜13時50分ごろ（日本時間）に見た範囲では見つからなかったが、PoC の話はある。PoC は悪用に数えず、KEV に無いことは悪用されていない証明ではない。JPCERT/CC は侵害を受けていないかの調査を勧めている
当たるかは版で決める。同じ系統の中で、直った版より前なら当たる。mod_php は最優先。FPM は文書で書き方が食い違っていて、「FPM なら安全」とは読めない。コマンドラインだけの PHP は、書かれていない
確かめ方は入れ方で違う。公式のソース・Docker・Homebrew は php -v の番号。OS のパッケージは、告知のパッケージの版（Ubuntu 24.04 は、番号が 8.3.6 のままでも直る）。レンタルサーバーは、提供元のお知らせ
上げるのだけが完全な解決。公式の手立て（memory_limit=-1、post_max_size を小さく、session.upload_progress.enabled=0、PHP 8.5 の fatal_error_backtraces=0 など）は、特定の道を減らす「つなぎ」でしかない
8.1 以前は、PHP の開発元からの直しが出ない。7.4・8.0・8.1 には、ソースからビルドする人向けの最小限の緩和（完全な直しではない）がある。8.2 は2026年12月31日で、セキュリティの直しも終わる。10月21日の版は 9月24日の直しも含むので、9月24日の版に上げていなくても、一緒に直る
この記事で確かめていないこと：Web サーバーの中の PHP の動かし方を確かめる手順、RHEL や Alpine でパッケージの版を見るコマンド、RHSA のページ、レンタルサーバーの会社の画面の手順、7.4〜8.1 のブランチの中身、9月24日の分の1件ごとの中身

同じ時期の話として、10月14日には React と Next.js の脆弱性の告知も出ています。そちらはReact・Next.js の脆弱性に書きました。