WEBサイト
2026年10月21日の夜に修正版が出たPHPの重大な脆弱性（通称php2shell）について、10月23日、PHPの公式サイトが3本目の知らせを出した。1本目と2本目は、10月21日に修正版と一緒に出た、2件の重大な欠陥（CVE-2026-109618とCVE-2026-109619）の勧告だ。今回は修正版そのものではなく、「次の通常のリリースが出るまで、アップロードの進捗を扱う設定を止めておくとよい」という、情報提供の形の注意だった。番号はCVE-2026-115560で、詳しい勧告は次のリリースと一緒に出す、と書かれている。
当サイトは、10月22日の未明に、修正の入ったPHPへ入れ替えている。その経緯はPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でに書いた。3本目の知らせが出たので、週明けの10月26日の朝に、当サイトを確かめ直した。そのとき気づいたのは、知らせの中身より手前の、もっと基本的なことだった。入れ替えた後のPHPが名乗る版の番号と「作った日」は、入れ替える前と同じ文字だったのだ。
この記事は、その記録だ。書くのは、版の表示が何を示し、何を示さないのか。修正が入ったかを、版の表示ではなく値で確かめる4つの方法。そして、3本目の知らせを当サイトで確かめた結果だ。読み終えたら、担当サイトの事業者や制作会社に「修正は入っていますか」と聞くとき、何を見せてもらえばよいかが分かるようにしたい。更新の順番や、更新の後に確かめることはPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でが受け持つので、ここでは繰り返さない。安全のため、当サイトのPHPの版の番号、サーバーの構成、ファイルの置き場所、設定ファイルの中身は書かない。書くのは、件数、確かめ方、順番、表示がどう見えたかまでだ。
何が起きたか ── 3行で、そしてなぜ10月26日の朝に確かめ直したか
3行で言うと
- PHPの公式サイトは、10月21日に重大な欠陥2件の修正版を出し、10月23日に3本目の知らせ（CVE-2026-115560）を出した。3本目は「ごくまれな条件がそろったときだけ起きうる」問題で、公式は設定を1つ止めることを勧めている。
- 当サイトは10月22日に、修正の入ったPHPへ入れ替えた。ところが、入れ替えた後のPHPの版の番号も「作った日」の表示も、入れ替える前と同じ文字だった。修正が入ったかどうかは、この2つの表示からは分からない。
- 分かったのは、設定の名前を中身の文字で比べたときだ。ある設定の名前（max_multipart_body_parts）が、入れ替える前は0か所、入れ替えた後は2か所あった。これは当サイトの入れ替えで分かった目印で、どのサイトにも通じるとは限らない。当サイトはこの方法を含む4つの確かめ方を使い、3本目の知らせの条件も確かめた。結果は、設定の値（③が止めた状態、①が既定）で条件がそろわず、追加の作業は無かった。
なぜ10月26日の朝に確かめ直したか
3本目の知らせは、10月23日（金）の日付で出ている。当サイトで確かめ直したのは、週明けの26日（月）の朝だ。知らせが出ること自体は想定していなかったので、出てから確かめた。
確かめる前に、すでに分かっていたことが2つあった。1つは、当サイトでは10月22日の未明に、アップロードの進捗を扱う設定をすでに止めていたこと。PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でに書いたとおり、これは2本目の欠陥への暫定策として入れたもので、3本目の知らせが勧める設定と同じものだ。もう1つは、修正の入ったPHPへ入れ替えた後も、それを止めたままにしていたこと。つまり、3本目の知らせに対して、すぐに何かが必要になる状態ではなさそうだった。ただ、「なさそう」は確認ではない。公式が書いた条件を、当サイトのプログラムと設定に当てて、一つずつ確かめることにした。
確かめる途中で、冒頭の「版の表示が前と同じ」に気づいた。修正が入ったかを聞かれたとき、版の番号で答えようとすると答えられない。それが分かったので、この記事の主題は後者になった。
版の表示は、入れ替えの前後で変わらなかった
PHPが名乗る2つの表示 ── 版の番号と、「作った日」
PHPをコマンドで呼んで版を尋ねると、1行目に版の番号と、「built:」で始まる作った日が出る。多くの人が「このPHPは新しいか」を見るのは、この行だ。ただし、これはPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でで書いたとおり、コマンドから呼ばれるPHPの表示にすぎない。Webの要求を処理しているPHPは別のことがあるので、確かめるのは、Webを動かしている側のPHPでなければならない。当サイトで見たのは、入れ替えたPHP、つまりWebを動かしているPHPの表示だ。
見た結果は、次のとおりだ。入れ替えた後のPHPの1行目は、版の番号も、「built:」の日付も、入れ替える前に控えておいたものと、同じ文字だった。「built:」の日付は、実際に入れ替えた2026年10月22日より前の日付を名乗っている。一方で、プログラムのファイルの日付も、パッケージの記録に残る「作った日」も、実際に入れ替えた10月22日になっていた。
つまり、表示は古いまま、中身は新しくなっている。版の表示だけを見て「まだ古い版のままだ」と読むと、修正済みなのに未修正と判断してしまう。逆に、表示が新しい日付なら安心できるかというと、そうとも言えない。表示は、中身が何かを直接示すものではないからだ。
中身の文字で比べると、違いが見えた
そこで、入れ替える前に控えておいたPHP本体と、今動いているものを、ファイルに書き出さずに、中身の文字だけで比べた。比べたのは「作った日の文字」「前後で差が出た設定の名前」「どちらにも在るはずの設定の名前」の3つだ。3つ目は、比べ方そのものが効いているかの確かめで、必ず在ると分かっている名前が前後で見つかれば、探し方は壊れていない。結果は次の表のとおりだ。
| 見たもの | 入れ替える前 | 入れ替えた後 | 読み方 |
|---|---|---|---|
| 版の番号の表示 | 表示された | 前と同じ文字 | 変化なし。修正の有無は示さない |
| 「作った日」の表示 | 表示された | 前と同じ文字 | 変化なし。実際に入れ替えた日とは別の日付のまま |
| 実際に入れ替えた日（ファイルの日付と、パッケージの記録） | ― | 2026年10月22日 | 表示とは別に、記録には新しい日付が残っている |
| 「作った日」の文字が中身にある数 | 2か所 | 2か所 | 同じ。表示が前と同じ文字であることとは、矛盾しない |
| 入れ替えの前後で差が出た設定の名前（max_multipart_body_parts）が中身にある数 | 0か所 | 2か所 | 前と後で違う。当サイトの入れ替えでは、ここに差が出た（他のサイトにも通じる目印とは限らない） |
| どちらにも在るはずの設定の名前が中身にある数（比べ方が効いているかの確かめ） | 1か所 | 1か所 | 同じ。探し方は壊れていない |
| 中身から計算する目印（指紋） | ― | 前と違う | ファイルの大きさの差は208バイト |
表のとおり、版の番号と「作った日」は完全に同じなのに、中身の指紋は違い、設定の名前（max_multipart_body_parts）だけが、前は0か所で、後は2か所あった。表示は同じでも、中身は違う。ここから、次の考えが出てくる。
なぜ、修正が入っても版の番号が変わらないことがあるのか
PHPの公式が出す「最小限の修正」と、配布元の取り込み
理由は2つある。1つ目は、公式の側の事情だ。PHPの公式は、サポートの終わった古い系統には、新しい版を出さない。今回の件でも、公式は告知にこう書いている。
"Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version."
（日本語訳: 一部のディストリビューションと長期サポートの提供元は、修正を移植して提供している。詳細は提供元に問い合わせるか、サポート中の版に移ること。）
古い系統を使い続けているサイトは、実際に多い。そのためか、10月21日の告知は、サポートの終わった古い系統のうち3つの系統向けに、公式が最小限のソースの修正（移植）を用意したと書いている。その目的を、公式はこう説明している。
"to help people building from source or without access to an LTS vendor."
（日本語訳: ソースから作る人や、長期サポートの提供元を使えない人を助けるため。）
ここで言う「最小限のソースの修正」は、新しい版へ上げるのではなく、古い系統のソースに、修正の部分だけを足したものだ。足した後も、系統の番号はそのままで、版の番号を新しくするとは限らない。公式の告知を、この範囲で読むと、「古い系統には修正が出ない」わけではなく、「新しい版の番号としては出ない」と言うのが近い。この読みは、公式の告知が書いている範囲をもとにした、当サイトの読みだ。
JVN（JPCERT/CCとIPAの脆弱性情報の窓口）のページ（JVNVU#99905564）も同じ構図になる。公開日は2026年10月22日、最終更新日は10月23日だ。影響を受けるバージョンの欄には、サポート中の4つの系統の、修正前の版だけが並んでいる。これは、公式がその4つの系統にしか新しい版を出していないからだと読める。古い系統が欄に載っていないことは、対象外という意味ではない。そう読むと、古い系統を使っているサイトが、自分は関係ないと誤って判断してしまう。
配布元の移植（バックポート）
2つ目の理由は、Linuxを配るRed Hatのような、配布元が取る方法だ。バックポートとは、最新版に入った修正の部分だけを取り出して、配布済みの古い版に適用することを指す。Red Hatの公式ページは、その目的を説明したうえで、版の番号について次のように書いている。
"Customers need to be aware that just looking at the version number of a package will not tell them if they are vulnerable or not."
（日本語訳: 利用者は、パッケージの版の番号を見るだけでは、脆弱かどうかは分からないことを知っておく必要がある。）
同じページは、点検の道具にも触れている。
"some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes."
（日本語訳: 一部のセキュリティの点検・監査の道具は、見つけた部品の版の番号だけで脆弱性を判断する。その結果、移植された修正を考慮せず、誤検知になる。）
誤検知は「入っているのに、未修正と出る」向きの誤りだ。担当サイトの点検の報告書に「古い版のPHPが動いています」と出ていても、それだけでは未修正と決まらない。逆に、新しい版の番号が出ていても、設定や再起動が済んでいなければ、動いている本体は古いままのこともある。版の番号は、どちらの向きにも間違えうる。
仲間の1人が、版の一覧だけを見て「打つ手が無い」と結論しかけた
当サイトのチームでも、これに近いことが起きた。仲間の1人が、配布元の版の一覧だけを見て、「この版は対象外のため、打つ手が無い」と結論しかけた。実際には、公式が古い版のための修正を出していて、それを組み込んだPHPに入れ替える道があった。配布元の一覧だけを見て判断すると、道が1つ見えなくなる。
修正が入ったかを、値で確かめる4つの方法
版の表示が使えないなら、何で確かめるか。当サイトが使った4つを、確かさの順に並べる。まず表で全体を見て、そのあと一つずつ説明する。
| 順位 | 方法 | 分かること | 分からないこと |
|---|---|---|---|
| 1 | 公式の知らせに書かれた修正の変化を、動いているPHPの値で見る | 当サイトの入れ替えでは、前後の差として現れた目印があるか | その脆弱性の修正がすべて入ったとまでは言えない |
| 2 | パッケージの名札 | 配布元が修正を入れた版として出したか | 名札は手でも付けられるので、名札だけでは決められない |
| 3 | 入れ替えの前後で、作るときの指定の一覧の指紋が同じか | 指定の一覧が、前後で余計に変わっていないか | 修正の有無は分からない。「指定の一覧が同じ」を確かめるもの |
| 4 | 版の番号と「作った日」の表示 | 表示の文字 | 修正の有無の証拠にならない |
1番目: 修正による変化を、動いているPHPの値で見る
当サイトで、いちばん決め手になったのがこれだ。入れ替える前と後の本体を比べたとき、設定の名前（max_multipart_body_parts）が、前は中身に0か所、後は2か所だった。動いているPHPの設定の一覧に、この名前が出るかを見れば、入れ替えが効いたかが分かる。ここまでは、当サイトで前後を比べて分かった事実だ。
ここから先は、読者が自分のサイトに当てはめるときの注意になる。まず、この設定が、今回の修正で新しく生まれたものだとは、確かめられていない。PHPマニュアルの設定の一覧のページ（2026年10月26日に確かめた）にも、10月21日のPHP公式の知らせにも、2本の勧告にも、この名前は見つからなかった。GitHubで公開されているPHPのソースを見ると、8系の枝（8.4と8.3）では、この設定が「制限なし」を表す初期値ですでに登録されている。いつの版で加わったかは、確かめていない。したがって、お使いの版によっては、この名前が出ても、今回の修正の証拠にはならない可能性が高い。公式が「この設定があれば修正入り」と言っているわけでもない。
では、いつ使えるのか。当サイトのように、修正を取り込んだPHPに入れ替えた場合だ。このときは、入れ替える前の本体にこの行が無く、入れ替えた後にあった。その前後の差が、目印になった。つまり、これは「当サイトの入れ替えで、前後を比べて分かった目印」であって、どのサイトにも通じる目印ではない。目印の名前は、系統や版によって違う。
読者のサイトでは、お使いの版で、次のように一般化して使ってほしい。お使いの版で、今回の修正によって何が変わったかを、公式の知らせと勧告で確かめる。そこに書かれた設定や挙動を、動いているPHPで、値として見る。公式に書かれていない目印は、探しても決め手にならない。さらに、設定が在ることと、効いていることは別だ。初期値が「制限なし」なら、在っても何も制限していない。「在る」は、その脆弱性の修正がすべて入ったことの保証にもならない。
確かめるときは、Webを動かしているPHPに対して、設定の一覧を出す。コマンドのphpに対して出すと、別のPHPの一覧を見てしまうことがある。自分で出せない契約なら、事業者に出してもらう。出してもらうときの頼み方は、後の節にまとめた。
2番目: パッケージの名札
配布元が修正を入れて出したパッケージは、配布の名前に、修正の番号を入れていることがある。当サイトで入れ替えたものも、そのようにした。入れた後にパッケージの一覧で名前を見ると、「どの修正を入れたものか」が、名前から分かる。
名札は便利だが、名札だけでは決め手にならない。名前は、手でも付けられるからだ。付けた人が間違えれば、名札と中身は食い違う。だから、名札は「中身の確かめに進む前の目印」として使う。1番目の方法で名札どおりの中身かを確かめて、はじめて意味が出る。
3番目: 入れ替えの前後で、作るときの指定の一覧の指紋が同じか
作るときの指定の一覧が手元にある場合は、もう1つ確かめることがある。PHPは、作るときの指定の一覧（どの機能を入れるか、など）に従って組み上がる。この指定の一覧から指紋を計算して、入れ替える前のものと比べると、「余計な変更が入っていないか」が分かる。当サイトでは、入れ替える前と後で、作るときの指定の一覧の指紋が一致した。
この確かめ方が答えるのは「指定の一覧が前後で同じか」であって、「修正が入っているか」ではない。指定の一覧が同じでも、修正が入っていなければ、未修正のままだ。1番目の方法の代わりにはならず、組み合わせて使うものだ。数字の指紋は、何を計算した値かを隣に書いておかないと、あとで食い違う。PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でにも書いたが、改行を1つ含めるかどうかだけで、指紋の値は変わる。
4番目: 版の番号と「作った日」の表示 ── 証拠にならない
最後の4番目は、ふだん最も見られる、版の番号と「作った日」の表示だ。先の表のとおり、当サイトでは、修正の前後でどちらも変わらなかった。したがって、この表示は、修正の有無の証拠にならない。見るなとは言わない。ただ、「新しく見える」「古く見える」から結論を出さないほうがよい。
表示が役に立つ場面もある。サポートが終わる日を調べるときや、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るのような一覧で、系統ごとの期限を管理するときだ。期限の管理には、系統の番号を使う。ただし、修正が入ったかの判定には、使わない。
3本目の知らせ（CVE-2026-115560）を、当サイトで確かめた
公式が書いたこと
PHPの公式サイトは、10月23日の日付で、次のように書いている。
"We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector."
（日本語訳: ありそうにない遠隔のコード実行の経路から完全に守るために、次の通常のバグ修正リリースが出るまで、session.upload_progress.enabled=0にすることを勧める。）
続けて、起きる条件を書いている。
"The issue can only occur under an unusual combination of configuration and application code."
（日本語訳: この問題は、設定とアプリケーションのコードの、ふつうではない組み合わせのときにだけ起きうる。）
"An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled."
（日本語訳: アプリケーションが、設定で session.serialize_handler を php_binary か php_serialize にしたうえで、session_start() を呼ぶ前に、実行中に ini_set() で php に切り替えている必要がある。セッションのアップロード進捗も、まだ有効になっていなければならない。）
読み取れる条件は3つだ。①設定で、セッションの保存の形式（session.serialize_handler）をphp_binaryかphp_serializeにしている。②プログラムの中で、実行中にその形式をphpに切り替えている（ini_set()を使う）。③アップロードの進捗の機能（session.upload_progress.enabled）が有効のままになっている。3つがそろったときだけだ。公式は、次の一文も添えている。
"Applications that never change the serialize handler at runtime can keep the feature enabled."
（日本語訳: 実行中に保存の形式を変えないアプリケーションは、この機能を有効にしたままでよい。）
公式は、この設定が10月21日の2本目の勧告（GHSA-6wmf-4rv5-p3rp）で、すでに暫定策として挙げられていたとも書いている。そのとき止めた人は、そのままでよい。そうでない人は、今回あらためて止めるのが勧めだ。なお、次のリリースで詳しい勧告が出る予定なので、今回の記述は、最終版ではない。
当サイトで確かめた結果 ── 3つの条件はそろわない
10月26日の朝、当サイトで3つの条件を一つずつ確かめた。結果は次のとおりだ。
- ①セッションの保存の形式（session.serialize_handler）: php。既定のままで、php_binaryにもphp_serializeにもなっていない。
- ②実行中に保存の形式を切り替える書き方（ini_set()でserialize_handlerを変える）: 文字の検索では、当サイトのプログラムの中に0件だった。ただし、サイトの土台の仕組みが、設定の名前を変数で渡して、セッションを始める前に保存の形式をphpに設定する処理を持っている。元の値がもともとphpなので、切り替えにはならない。
- ③アップロードの進捗の機能（session.upload_progress.enabled）: 止めた状態（Off）のまま。10月22日に止めてから、変えていない。
決め手は、①と③だ。保存の形式は元からphpで、アップロードの進捗は止めてある。①と③のどちらか1つが欠ければ、公式が書いた条件にはならない。②は、文字の検索では見つからなかったが、土台の仕組みにphpを設定する処理があった。ただし、元がphpなので切り替えにならず、条件を満たさない。したがって、3本目の知らせについて、追加の作業は無かった。
ここには、書いておくべき限界と、自分の見落としがある。最初は、プログラムの中の文字を検索するだけで②を「0件」と数えていた。公開前の確認の段階で、サイトの土台の仕組みが値を設定していることが分かった。設定の名前を変数で渡す書き方は、文字の検索では探せない。読者への教訓は、コードの検索だけで済ませず、動いている値そのものを見ることだ。当サイトでは、①の設定の値と③の値を見て決めた。0件は「見つからなかった」までで、「絶対に無い」とは言い切れない。また、確かめたのは当サイトのプログラムだ。担当サイトでは、使っている部品やプラグインの中に、このような書き方があるかを、事業者に聞く必要がある。
もう1点。公式は「次の通常のリリースまで止めておく」と書いている。10月21日の勧告（GHSA-6wmf-4rv5-p3rp）にも、修正を当てた後の話として、次の一文がある。
"It might be prudent to set session.upload_progress.enabled=0 if you don't need this feature even after applying the patch, as more attackers try to find flaws in this hardly-used and hardly-tested feature."
（日本語訳: この機能が不要なら、修正を当てた後でも session.upload_progress.enabled=0 にしておくのが賢明かもしれない。ほとんど使われず、ほとんど試験されていないこの機能の欠陥を、より多くの攻撃者が探そうとするからだ。）
この2つの文を並べると、10月21日の修正版では、3本目は直らないと読める。php.netは、次の通常のリリースまで設定を止めておくと書いているからだ。これは公式の文を読んだ当サイトの読みで、公式がそう言い切っているわけではない。修正版に上げた後も、機能を使っていなければ、止めたままにしておくのがよい。
事業者・制作会社に「修正は入っていますか」と聞くとき、見せてもらうもの
担当サイトを、事業者や制作会社に任せている場合、「PHPの修正は入っていますか」と聞くだけでは、返事が「最新です」「対応済みです」で終わってしまうことがある。その返事が正しいかを、あなたが確かめられる形にするには、見せてもらうものを決めておくとよい。
見せてもらうものは、次の6つだ。
- Webを動かしているPHPが、どれか（コマンドから呼ばれるPHPではなく）
- 修正の入った版（またはパッケージの名前）と、入れた日時
- 入れた修正の出どころ（公式のどの修正か、配布元のどの告知か。CVEの番号があればその番号）
- 入れ替えた後に再起動したか、動いているプロセスが新しい本体を使っているか
- 公式の知らせに書かれた修正の変化が、動いているPHPの値に出ているところ
- 入れ替えの前後で、ページの応答や中身を比べた記録
3本目の知らせについては、さらに2つ聞く。アップロードの進捗の機能が止まっているか。そして、サイトのプログラムが、実行中にセッションの保存の形式を切り替えていないか。後者は、事業者が自分で確かめて答えるのが現実的だ。聞くときは、公式の条件をそのまま渡すとよい。
返事の読み方は、次の表のとおりだ。
| 返ってきた答え | 読み方 | 次に聞くこと |
|---|---|---|
| 「最新の版です」 | 版の番号の話にすぎない。修正の有無は分からない | 修正の出どころと、入れた日時 |
| 「版は変わっていませんが、修正は入れました」 | 移植の形ではありうる。ただし、そう言うだけでは確認にならない | 設定の一覧に出る修正の目印と、パッケージの名前 |
| 「ホスティングの会社が対応済みです」 | 誰が、いつ、何を入れたかが分からない | 会社の告知のページと、対応した日 |
| 「古い版なので対象外です」 | 古い系統向けの修正が出ている。対象外と決めるのは早い | 古い系統向けの修正の有無と、提供元の対応 |
| 「再起動はこれからです」 | 動いている本体は、古いままの可能性がある | 再起動の予定日と、再起動したあとの確認 |
事業者を疑うために聞くのではない。確かめる材料を、お互いに出し合うための聞き方だ。見せてもらうものが決まっていれば、事業者の側も答えやすくなる。点検の道具で外から見る方法もある。当サイトの🔧 外からできるセキュリティ対策監査ツール（会員登録が必要）は、外から見える範囲の情報を集める。ただし、外から見える範囲では、修正の有無までは分からない。この記事の話と、同じ限界がある。
WEBディレクターが担当サイトで明日やること
自分で確かめられる場合
- 担当サイトの一覧に、「修正が入ったかを、何で確かめたか」を書く欄を足す。書き方の例は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るの列の考え方に沿うとよい。
- Webを動かしているPHPを特定する。コマンドの
phpの表示で済ませない。 - 自分の版で、今回の修正が何を変えたかを公式の知らせで確かめ、その設定や挙動を、動いているPHPの値として見る。目印の名前は版で違う。
- パッケージの名前を見て、入れた修正の番号が入っているかを見る。名札だけで決めない。
- 入れ替えた後に再起動したか、動いている本体が新しいかを確かめる。更新と再起動の順番はPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でを見る。
- session.upload_progress.enabled の値を見る。使っていなければ、止める。止める前に、サイトのプログラムが使っていないことを確かめる。
- 修正の前後で、ページの応答と中身を比べる。応答の200だけで終わらせず、複数のページの中身まで見る。ページの見た目を日付つきで残すなら、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールがまとめて撮れる。
自分では確かめられない場合
- 事業者に、前の節の6つを見せてもらう。返事の読み方の表を手元に置く。
- 点検の報告書に「古い版」と出ていたら、版の番号だけで結論を出さない。移植の有無を、事業者に聞く。
- 修正の出どころを、公式の告知（PHP.net: News Archive 2026（10月21日の勧告と、10月23日の「Informational advisory: Session upload progress」））と、事業者の告知の両方で確かめる。
関連して、痕跡の調べ方はPHPの脆弱性の「痕跡」は、ログに無いこともある、WAFがあっても更新が要る理由はPHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた、WordPressの更新とPHPの更新が別であることはWordPressの更新は要らないが、PHPの更新は要る。公式の記事が書いたことが受け持つ。ここでは、「版の表示を当てにしない」ための項目に絞った。
当サイトの現在地
✅ 当サイト実施済 3本目の知らせ（CVE-2026-115560）の3つの条件を、10月26日に、当サイトの設定とプログラムで確かめた。アップロードの進捗の機能は止めたまま、保存の形式は既定のまま、実行中に切り替える書き方は、文字の検索では見つからなかった。ただし土台の仕組みにphpを設定する処理があり、元がphpなので切り替えにならない。決め手は、保存の形式がphpであることと、アップロードの進捗がOffであることだ。追加の作業は無かった。
✅ 当サイト実施済 修正が入ったかを、版の表示ではなく値で確かめた。入れ替える前後の本体を中身の文字で比べ、設定の名前（max_multipart_body_parts）が0か所から2か所に変わったことを確かめた。これは当サイトの入れ替えで分かった目印で、公式がそう言っているわけではない。
🔧 当サイトこれから 担当サイトの一覧（PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るの考え方）に、「修正が入ったかを何で確かめたか」の欄を足す。今日はまだ足していない。
🔧 当サイトこれから 配布元の公式な更新が出たら、そちらに切り替える。いつ出るかは決まっていない。切り替えるときは、この記事の4つの方法で確かめる。
まとめ
持ち帰ってほしいことは5つ。
- 版の番号と「作った日」の表示は、修正の有無を示すものではない。当サイトでは、修正を入れても表示は前と同じ文字だった。
- 修正の入った作りかは、公式の知らせに書かれた変化を値で見る、パッケージの名札、作るときの指定の一覧の指紋（入れ替えの前後）、の3つを組み合わせて確かめる。いずれも単独では決め手にならない。
- 点検の報告書の「古い版」は、移植された修正を数えていないことがある。版の番号だけで、未修正とも修正済みとも決めない。
- 3本目の知らせは、3つの条件がそろったときだけ起きうる。当サイトでは、設定の値（保存の形式がphp、アップロードの進捗がOff）で条件がそろわなかった。コードの文字の検索だけで「無い」と決めず、動いている値を見る。担当サイトでは、使っている部品の中に該当する書き方がないかを、事業者に聞く。
- 事業者には、「修正は入っていますか」ではなく、「Webを動かしているPHPで、何を、いつ入れたか」を、見せてもらう。
確かめていないことも書いておく。表示の「作った日」が古いままの理由は、確かめていない。表示の日付がどこで決まるかは、確かめていない。設定の名前（max_multipart_body_parts）が、いつの版で加わったかも、公式の文書では確かめられていない。3本目の詳しい勧告は、まだ出ていない。出たら、この記事の内容を見直す。
関連 archives（連載軸として読む）
- PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録 ── この記事の前提。更新の順番、更新の後に確かめること、攻撃の痕跡の調べ方は、こちらが受け持つ（10月22日〜23日）
- 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 ── 同じ週に、公開の場所に残った控えを数えて外へ移した記録（10月23日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── 記事のチェック項目を、公開した日に自分のサーバーに当てた記録
- 認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録 ── 知らせを、自分のサーバーで測り直した記録
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた ── 外から取った表示は、目当てのものとは限らないという話
解説記事では、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る、PHPの脆弱性の「痕跡」は、ログに無いこともある、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いたもあわせて読める。
出典
- PHP.net: News Archive 2026（10月21日の勧告と、10月23日の「Informational advisory: Session upload progress」）
- GitHub: php-src Security Advisory GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- GitHub: php-src Security Advisory GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- JVN: JVNVU#99905564 PHPにおける複数の任意のコードが実行可能な脆弱性（CVE-2026-109618、CVE-2026-109619）
- Red Hat: Security Backporting Practice（Backporting Security Fixes）
- GitHub: php/php-src PHP-8.4の枝 main/main.c（設定の登録）
- PHP Manual: Description of core php.ini directives
