IPAのPHP注意喚起は、10月22日の公開から11月2日までに2回追記された ── 追記の日付と中身を並べて読み、公式の保守が終わったPHPを担当サイトで見つける13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — IPAの注意喚起は、10月22日の公開から11月2日までに、2回追記された
   1. 更新履歴に書かれた3行
   2. 10月27日の追記が書いた中身
   3. 11月2日の追記が書いた中身
   4. CISAのページの更新も、日付がある
2. 02 なぜ・背景 — 追記のたびに、読む人の範囲が変わった可能性がある
   1. 追記のたびに、読む人の範囲が変わった可能性がある
   2. 初日に「当てはまらない」と判断した人が、見落とす
   3. 履歴が書いていないこと
   4. 公式の保守が終わった版の扱いが、もう1つの論点
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「更新履歴」と「最終更新日」は別の情報
4. 04 型別 — 適用範囲、書かれていないこと、追記を読む手順と、EOLを見つける手順
   1. 🅰 適用範囲 — 系統ごとの、公式の保守と今回の修正版
   2. 🅱 この表と、更新履歴が書いていないこと
   3. 🅲 手順1 — 注意喚起を、日付つきで控える
   4. 🅲 手順2 — 次に読むときは、足された行だけを読む
   5. 🅲 手順3 — 担当サイトの系統を、台帳に書く
   6. 🅲 手順4 — PHPの系統を読む5つの手がかり
   7. 🅲 手順5 — 表の色分けで、3つの群に分ける
   8. 🅲 手順6 — 機器の中のPHPは、提供元に決まった形で聞く
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — EOLのサイトと、更新できないサイトの扱い
   1. IPAが書いた6つの段階を、サイトの判断に置き換える
   2. 外から見られる範囲を、道具で補う
   3. WAFは追加の層であって、更新の代わりではない
7. 07 当サイトで確かめたこと — 外から版が読めるか、台帳の列
   1. 応答ヘッダーに、PHPの版は出ていなかった
   2. 系統の番号は、期限の管理に使い、修正の判定には使わない
   3. 期限の読み替えも、すでに書いた
8. 08 このテーマは、ここまで — PHPの注意喚起の流れ
   1. これまでの記事
   2. 今回の記事の位置
   3. 2026年11月4日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — IPAの注意喚起は、10月22日の公開から11月2日までに、2回追記された

IPAは2026年10月22日に、PHPの2つの脆弱性（CVE-2026-109618とCVE-2026-109619）と、その組み合わせである「PHP2shell」についての注意喚起を出した。ページの先頭には、公開日が2026年10月22日、最終更新日が2026年11月2日と書かれている。つまり、この注意喚起は、公開から11日の間に、中身が足された。この記事は、脆弱性の中身を繰り返さない。何が危ないか、どう更新するかは、当サイトの別の記事「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」にまとめてある。ここで扱うのは、追記の日付と中身を並べて読む方法と、公式の保守が終わったPHPを、担当サイトで見つける方法の2つである。

更新履歴に書かれた3行

ページの末尾の更新履歴は、新しい順に3行ある。2026年11月2日は、概要に、この脆弱性の影響を受けうる製品や機器についての記載を追加した、とある。PHPはVPN機器などのWebの管理画面にも使われているので、製品の開発元の対策情報に注意するよう求める内容である。2026年10月27日は、CISAのカタログへの登録についての記載を追加した、とある。2026年10月22日は「掲載」である。

10月27日の追記が書いた中身

現在の概要は、2026年10月26日（現地時間）に、2つの脆弱性がCISAの悪用が確認された脆弱性のカタログに載ったと書いている。IPAは、国内での攻撃の被害事例は把握していない、とも書いている。日付に「現地時間」と添えているのが特徴である。10月26日の出来事を、10月27日付けで追記した形で、日付が1日ずれて見えるのは、このためと読める。これは筆者の読みで、IPAがそう説明しているわけではない。

11月2日の追記が書いた中身

11月2日の追記は、概要に、VPN機器やセキュリティ機器のWebの管理画面でもPHPが使われているという具体例を足した。あわせて、自社・自組織で使うソフトウェア製品や機器については、製品開発者の脆弱性対策情報に注意し、対策が出たら適用するよう求めている。ただし、現在の概要には、10月27日の追記より上にも、PHPがさまざまなWebアプリケーションやソフトウェア製品で使われていて、使っている製品については開発者や提供元の情報を確認するよう求める、という趣旨の文がある。そのため、11月2日の追記で読む人の範囲が広がったのかは、筆者の読みであり、初版を読めていないので、確かめていない。どの製品が当てはまるかは、IPAのページは挙げていない。

CISAのページの更新も、日付がある

CISAの告知のページも、更新の日付が書かれている。公開は2026年10月21日で、2026年10月23日の更新は、疑わしい動きを見つけるための検知ルール（SIGMA）の提供と、協力先の資料の追加、既存の緩和策の補強だった。2026年10月26日の更新は、2つの脆弱性をカタログに加えたことの反映である。IPAの10月27日の追記と並べると、カタログへの追加が、両方のページの更新の理由だったことが分かる。カタログの行を読むと、追加日は2件とも2026年10月26日、対応の期限の欄は2026年10月29日、侵害の調査を求める欄は「Yes」、ランサムウェアの攻撃に使われたかの欄は「Unknown」だった。

02 なぜ・背景 — 追記のたびに、読む人の範囲が変わった可能性がある

追記のたびに、読む人の範囲が変わった可能性がある

3つの日付の中身を並べると、追記のたびに、読む人にとって意味が変わったと読める。10月27日は、悪用が確認されたと知らされたので、更新の優先順位が変わった。11月2日は、VPN機器やセキュリティ機器の管理画面という具体例が足された。この具体例で、機器を使う人が自分の件だと気づきやすくなった、というのが筆者の読みである。ただし、初版を読めていないので、範囲が実際に広がったのかは確かめていない。同じ注意喚起でも、初日に読んだ人と、1週間後に読む人では、自分に当てはまるかどうかの答えが変わりうる。

初日に「当てはまらない」と判断した人が、見落とす

10月22日に読んで、「うちはサーバーを自分で更新していないから関係ない」と判断した人は、11月2日の追記を読まないままだと、機器の中のPHPの具体例を見落とすことがある。更新履歴は、最後に読んだ日から、何が足されたかを見るための表である。最後に読んだ日を覚えていないと、更新履歴は使えない。そこで、04章の手順で、読んだ日を台帳に書く。

履歴が書いていないこと

更新履歴の3行は、追加した内容を書くだけで、直した内容は書いていない。影響を受ける版の番号や、修正版の番号が、途中で変わったかどうかは、更新履歴の文面からは読めない。現在の本文には、修正版が8.2.35、8.3.36、8.4.27、8.5.12と書かれている。初版に別の番号が書かれていたかは、確かめていない。

公式の保守が終わった版の扱いが、もう1つの論点

IPAのページは、対策の節の最初に、修正版へ上げることを挙げ、そのあとの節で、更新が難しい場合の考え方を6つの段階で書いている。その最初の段階が、サポート状況の確認である。PHP 8.1以前はサポート終了（EOL）で、修正プログラムは提供されない、と書かれている。CISAの告知も、8.1以前のサポートが終わった版を使い続ける場合の扱いを、別に書いていた。つまり、この件では、更新履歴の読み方に加えて、「うちのPHPは、そもそも修正が出る系統か」という問いが、もう1つの柱になる。

03 用語 — 出てくる言葉を、先にそろえる

「更新履歴」と「最終更新日」は別の情報

ページの先頭の「最終更新日」は、いちばん新しい追記の日付である。更新履歴は、その日までの追記を全部並べたものである。先頭の日付だけを見ると、前回との間に何回追記があったかは分からない。更新履歴の行数を、読んだ日の控えと比べて、足された行を探す。

04 型別 — 適用範囲、書かれていないこと、追記を読む手順と、EOLを見つける手順

🅰 適用範囲 — 系統ごとの、公式の保守と今回の修正版

次の表は、PHP公式の一覧に書かれた、各系統のセキュリティ保守の終了日と、IPAのページに書かれた修正版の番号を、並べたものである。

系統	セキュリティ保守の終了日	今回の修正版	読み方
8.5	2029年12月31日	8.5.12	保守中。修正版に上げる
8.4	2028年12月31日	8.4.27	保守中。修正版に上げる
8.3	2027年12月31日	8.3.36	保守中。修正版に上げる
8.2	2026年12月31日	8.2.35	保守中だが、年内に終わる
8.1	2025年12月31日に終了	なし	EOL。IPAは修正が提供されないと書く
8.0	2023年11月26日に終了	なし	EOL
7.4	2022年11月28日に終了	なし	EOL

8.1の終了日は、PHP公式のサポートが終わった版の一覧に載っていた日付である。8.0と7.4の終了日も、同じ一覧からの書き写しである。8.2の日付は、サポートされている版の一覧の「セキュリティ保守の終了」の列にあった。「今回の修正版」の列は、IPAのページが挙げた番号である。なお、IPAは、調査に関わった会社の報告として、PHP 5.4以降の版が少なくとも片方の脆弱性の影響を受ける、とも書いている。

🅱 この表と、更新履歴が書いていないこと

次の点は、読んだ範囲では書かれていなかった。書かれていないことは、推測で埋めない。

• IPAのページの初版の文面と、追記の前後の本文の差（更新履歴の3行だけが読めた）
• VPN機器やセキュリティ機器のうち、どの製品の、どの版が当てはまるか（IPAは例示に留めている）
• OSの配布元や事業者が、EOLの系統に独自の修正を入れているかどうか
• 国内での攻撃の件数（IPAは、被害事例は把握していないと書く）
• 7.4以前の系統が、今回の2件のどちらに当たるのか（IPAは、5.4以降が少なくとも片方、と書くのみ）

🅲 手順1 — 注意喚起を、日付つきで控える

読むたびに、ページの先頭の最終更新日と、更新履歴の行の数を、台帳に書く。ページそのものの保存は、画面の印刷（PDFの保存）で足りる。ファイルの名前に、読んだ日付を入れる。保存した形は、次に読むときの「前回」になる。

🅲 手順2 — 次に読むときは、足された行だけを読む

次にページを開いたときは、先頭の最終更新日を、台帳の日付と比べる。違っていたら、更新履歴の行を、台帳の行数と比べて、足された行を探す。そして、その行が、自分の台帳のどの列を増やすかを、1行で書く。たとえば11月2日の追記なら、「機器の中のPHP」の列を足す、と書く。

🅲 手順3 — 担当サイトの系統を、台帳に書く

担当サイトごとに、Webを動かしているPHPの系統を書く。当サイトの別の記事「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」で、台帳の列の作り方を書いた。今回足すのは、「系統」の隣の「公式の保守の終了日」の列だけでよい。終了日は、上の表から書き写す。

🅲 手順4 — PHPの系統を読む5つの手がかり

系統を知る手がかりは、5つある。管理画面（レンタルサーバーの設定の画面）に、PHPの版の選択がある場合は、そこに表示されている。サーバーに入れる人は、端末でPHPの版を出すコマンドが使えるが、端末のPHPと、Webを動かすPHPは、別のことがある。PHPの情報を出すページ（phpinfo）は、読んだら必ず消す。応答ヘッダーに版が出るサイトもあるが、隠している場合が多い。WordPressなら、管理画面のサイトヘルスに表示される。この確認は、当サイトの別の記事「WordPressの更新は要らないが、PHPの更新は要る。公式の記事が書いたこと ── サイトヘルスで版を見て、事業者に確かめる13項目（2026年10月時点）」に書いた。最後の手段は、事業者に聞くことである。

🅲 手順5 — 表の色分けで、3つの群に分ける

台帳の系統を、上の表と照らして、3つの群に分ける。保守中で修正版に上げられる群、保守中だが年内に終わる群（8.2）、EOLの群である。EOLの群には、IPAが書いた6つの段階を、1サイトずつ当てる。EOLのサイトは、更新ではなく、続けるかどうかの判断が要る、というのがIPAの書き方の趣旨である。

🅲 手順6 — 機器の中のPHPは、提供元に決まった形で聞く

11月2日の追記が例に挙げた機器の中のPHPは、自分では版を読めないことが多い。その場合は、機器の提供元に、3つのことを聞く。「PHPを使っているか」「今回の2件の影響を受けるか」「対策の版はいつ出るか」。返事は、日付つきで台帳に書く。JPCERT/CCの注意喚起の更新を並べた記事「JPCERT/CCはPHPの注意喚起を10月29日に更新し、ファイアウォール製品の特定の版で侵害の成功を示唆する痕跡が報告されたと追記した ── サーバーの外にあるPHP同梱の製品を台帳に足して確かめる13項目（2026年10月時点）」に、聞き方の例がある。

05 明日、担当サイトで確認できることチェックリスト

以下は、注意喚起の追記を読み、公式の保守が終わったPHPを見つける13項目である。1〜4番目は追記を読む確認、5〜10番目は系統を台帳に書く確認、11〜12番目はEOLと機器の確認、13番目は習慣である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• IPAの注意喚起のページを開き、最終更新日と、更新履歴の行の数を、台帳に書く
• CISAの告知のページを開き、公開日と、更新の日付（10月23日と10月26日）を、台帳に書く
• 更新履歴の3行を、日付の順に並べて、それぞれが「何を足したか」を1行ずつ書く
• 11月2日の追記が、自分の台帳のどの列を増やすかを、1行で書く
• 担当サイトを3つ選び、Webを動かすPHPの系統を、管理画面か事業者への質問で調べて書く
• 端末でPHPの版を出した場合は、その結果が、Webを動かすPHPと同じかを、1サイトだけ確かめる
• 台帳の隣に、「公式の保守の終了日」の列を足し、上の表から日付を3サイト分書き写す
• 終了日が2026年12月31日の8.2を使うサイトの数を数えて、台帳の隅に書く
• 終了日が過ぎている系統（8.1以前）を使うサイトの数を数えて、台帳の隅に書く
• PHPの情報を出すページが公開の場所に残っていないか、担当サイト1つで開いて確かめる
• 8.1以前のサイトが1つでもあれば、IPAが書いた6つの段階のうち、最初の2つを台帳に書く
• VPN機器やセキュリティ機器の提供元に、PHPを使っているかを聞く文を、3行で書いて送る
• 台帳を保存したファイルの名前に、読んだ日付を入れ、次に注意喚起を開く日を書く

06 代替・他の選択肢 — EOLのサイトと、更新できないサイトの扱い

IPAが書いた6つの段階を、サイトの判断に置き換える

IPAは、修正対応が難しい場合について、6つの段階を書いている。サポート状況の確認、暫定の対策（アクセス制限など。有効な対策が難しければ、外部からの遮断やサービスの停止の要否を判断する）、システムの役割と移行の難しさの把握、組織としての実現性の検討、今後の方針の決定、利用者や業務への影響への配慮である。方針の決定では、維持の体制が取れない場合に、保守できる製品への移行、機能の縮小、公開の終了、廃止も含めて検討する、と書かれている。

選択肢	特徴	気をつけること
保守中の系統へ移す	公式の修正が出る	プログラムの修正が要る場合がある。試験の環境で先に確かめる
対策済みの製品へ移す	IPAが書いた選択肢の1つ	データの移行を計画する
暫定の対策を入れて、期限を決める	更新までの間の手当て	期限を台帳に書く。書かないと暫定のまま残る
公開を終える	攻撃される面が無くなる	利用者への案内と、データの保存が要る

外から見られる範囲を、道具で補う

当サイトの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — URLを与えて外から取れる情報をまとめる（🔒会員限定）は、ページの説明によれば、CMSやフレームワークなどの検出を行う。ただし、PHPの系統そのものを出すとは、ページには書かれていない。🔧 【セキュリティ】IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール　★iLogツカウン — IPAのツールにアクセスログを渡して分析する（🔒会員限定）は、ログの圧縮ファイルにも対応すると説明されている。注意喚起の件で使える場面はあるが、この2件の攻撃を見つける道具だとは、ページには書かれていない。どちらも、サーバーの中のPHPの系統を直接は教えてくれない。

WAFは追加の層であって、更新の代わりではない

CISAの告知は、更新までの間の手当てとして、Webアプリケーションファイアウォール（WAF）を挙げていた。WAFの位置づけは、当サイトの別の記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」に書いた。EOLの系統は、更新ができないので、WAFへの期待が大きくなりがちだが、追加の層であって、修正の代わりではない。

07 当サイトで確かめたこと — 外から版が読めるか、台帳の列

当サイトでは、2026年10月22日の未明に、Webを動かすPHPを、修正の入ったものへ入れ替えた。その経緯は、記事「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」に書いた。この記事で足した確認は、読むだけのものに限る。サイトの内部の構成は、安全のため書かない。

応答ヘッダーに、PHPの版は出ていなかった

2026年11月4日の昼に、当サイトのトップページの応答ヘッダーを、外から取り直して読んだ。PHPで動いていることを示すヘッダー（X-Powered-By）は、返っていなかった。つまり、外から応答ヘッダーを見ても、当サイトのPHPの系統は読めない。04章の手がかりのうち、応答ヘッダーは、当サイトでは役に立たないことになる。

系統の番号は、期限の管理に使い、修正の判定には使わない

系統の番号を、期限の管理に使い、修正が入ったかどうかの判定には使わない、という使い分けは、記事「PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録」に書いた。この記事で足したのは、台帳の「追記を読んだ日」の列である。当サイトの系統の番号は、ここには書かない。

期限の読み替えも、すでに書いた

カタログの期限を、自分のサイトの期限に読み替える方法は、記事「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」に書いた。この記事の追記の読み方と合わせると、期限が決まった日と、注意喚起が広がった日を、別々の列に書くことになる。

08 このテーマは、ここまで — PHPの注意喚起の流れ

これまでの記事

• PHPの脆弱性の全体像と更新の順番は、「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」で書いた。
• 修正が入ったかを値で確かめる方法は、「PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録」で書いた。
• 期限の読み替えは、「CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）」と「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」で書いた。
• JPCERT/CC側の追記と、製品の中のPHPは、「JPCERT/CCはPHPの注意喚起を10月29日に更新し、ファイアウォール製品の特定の版で侵害の成功を示唆する痕跡が報告されたと追記した ── サーバーの外にあるPHP同梱の製品を台帳に足して確かめる13項目（2026年10月時点）」で書いた。
• 担当サイトの一覧の作り方は、「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」で書いた。
• 8.2系の保守が終わる日の準備は、「PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）」で書いた。

今回の記事の位置

これまでの記事は、脆弱性とその対応を扱っていた。今回は、注意喚起そのものが変わっていくことを扱った。更新履歴を読む手順は、PHPの件が終わっても、次の注意喚起で使える。

2026年11月4日 — この記事の確認日

IPAの注意喚起の最終更新日は2026年11月2日だった。この日以降の追記があれば、この記事の05章の最初の項目で、更新履歴の行の数を数え直すと分かる。8.2系のセキュリティ保守の終了日は2026年12月31日で、年内の移行の計画は、前の記事にまとめてある。