CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — CISAの悪用確認リストに、PHPの2件が10月26日に載り、期限の欄は10月29日だった
   1. カタログの3つの行
   2. 一覧に載る条件
   3. 同じ週の、公式の発表
   4. 国内の事例と、一覧への言及
2. 02 なぜ・背景 — 「期限は今日」という言葉だけが、先に届く
   1. 期限の欄は、日付だけが目に入る
   2. 一覧の掲載と、危険度の点数は別
   3. 期限を、自分で決める必要がある理由
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 悪用が確認された脆弱性のカタログ（KEV）
   2. 期限の欄（Due Date）
   3. BOD 26-04と、連邦機関
   4. 修正版と、緩和策
   5. 侵害の調査の列（Forensic Triage）
4. 04 型別 — 一覧の読み方と、期限の読み替え方
   1. 🅰 適用範囲 — この記事が向いているサイト
   2. 🅱 この記事が確かめていないこと
   3. 🅲 手順1 — 一覧の行を、列ごとに読む
   4. 🅲 手順2 — 期限の欄を、自分の期限に読み替える
   5. 🅲 手順3 — 該当するかを、版の表示ではなく、値で確かめる
   6. 🅲 手順4 — 事業者への聞き方
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 更新の優先順位を決める、ほかの材料
   1. 一覧のほかに、優先順位の材料は4つある
   2. 更新できない事情があるとき
   3. 更新が間に合わない場合の、公式の助言
7. 07 当サイトで確かめたこと — 一覧に載る前の更新の日付と、外から見える応答
   1. 更新は、一覧に載る前に済んでいた
   2. 応答のヘッダーに、PHPの版は出ていなかった
   3. 当サイトで確かめていないこと
8. 08 このテーマは、ここまで
   1. PHPの脆弱性そのものの説明
   2. 修正が入ったかを、値で確かめる
   3. 担当サイトの一覧と、事業者への確認
   4. WAFや、攻撃の痕跡の話
   5. 同じ一覧に載った、別の件
   6. 2026年10月29日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — CISAの悪用確認リストに、PHPの2件が10月26日に載り、期限の欄は10月29日だった

2026年10月29日は、CISAの「悪用が確認された脆弱性」の一覧で、PHPの2件に付けられた期限の日である。2件は、10月26日に一覧へ加わった。期限の欄は、追加日の3日後に置かれている。この記事は、PHPの脆弱性そのものの説明ではなく、この一覧の「期限」の欄が誰のための決まりなのかを確かめ、日本の小さなサイトの更新期限に読み替える方法に絞る。PHPの脆弱性の中身や、修正が入ったかの確かめ方は、既存の解説記事とブログに任せて、リンクで済ませる。

カタログの3つの行

CISAのカタログのページで、PHPの2件とBrotliの1件の行を、2026年10月29日に読んだ。表に並べる。

3行に共通する「必要な対応」の欄は、ベンダーの指示に沿って緩和策を適用すること、と書く。あわせて、BOD 26-04と、CISAの侵害調査の手引きに従うことにも触れている。期限の欄の長さは、行によって違う。PHPの2件は追加日から3日、Brotliの1件は追加日から14日である。BOD 26-04のページは、期限の日数が、資産が外に公開されているか、攻撃者が手順を自動化できるか、技術的な影響の大きさ、などの組み合わせで決まると書く。侵害の調査が付く行は、期限が3日になる、とも書く。ただし、一覧のページには、行ごとの理由までは書かれていなかった。

一覧に載る条件

CISAの説明のページによれば、脆弱性が一覧に加わるのは、3つの条件がそろったときである。1つ目は、共通の識別番号（CVE番号）が付いていること。2つ目は、実際に悪用された（成功したものだけでなく、悪用の試みも含む）という、信頼できる証拠があること。調べるための走査、研究、公開された試験用のコードだけでは、条件を満たさない、とも書く。3つ目は、ベンダーの更新のような、はっきりした対処があること。つまり、一覧に載ったことは、「悪用の証拠がある」ことの印であり、「危険度の点数が高い」という印とは別である。

同じ週の、公式の発表

一覧に載るまでの経緯を、日付で並べると、次のようになる。

• 2026年10月20日 — PHP公式が、重大なセキュリティの更新の予告を出した
• 2026年10月21日 — PHP 8.5.12、8.4.27、8.3.36、8.2.35が出て（php.netのニュースは10月21日、変更履歴は22日の日付）、遠隔のコード実行を伴う2件の脆弱性について、更新を促すアドバイザリが出た。WordPressと、英国のNCSCも、同じ日に注意を出した
• 2026年10月22日 — IPAとJPCERT/CCが、注意喚起を出した
• 2026年10月23日 — PHP公式が、セッションのアップロード進捗に関する情報のアドバイザリを出した
• 2026年10月26日 — 2件がCISAの一覧に載った。PHP公式は、Windows版の作り直し（Brotliの修正を取り込むもの）も出した
• 2026年10月27日 — IPAが、一覧への掲載を、注意喚起に追記した

修正版の公開（10月21日）から一覧への追加（10月26日）までが5日、そこから期限の欄の日付（10月29日）までが3日である。修正版が出た日から数えると、期限の欄の日付は8日後にあたる。

国内の事例と、一覧への言及

IPAの注意喚起は、国内での攻撃の被害の事例は把握していないと書いている（2026年10月27日の更新の時点）。JPCERT/CCの注意喚起は、悪用を試みる通信の観測の報告と、実証用のコードの公開が相次いでいる、と追記している。筆者が読んだ範囲では、JPCERT/CCのページ（10月26日の更新）には、CISAの一覧への言及は見当たらなかった。

02 なぜ・背景 — 「期限は今日」という言葉だけが、先に届く

期限の欄は、日付だけが目に入る

一覧の表では、「期限」の欄に日付が1つ書かれているだけである。ニュースで「期限は10月29日」と伝えられたとき、読む人は、自分のサイトにもその日までの義務があるように受け取りやすい。ところが、一覧のページ自体は、この日付が誰に向けたものかを、書いていない。誰向けの決まりかは、別のページ（CISAの説明のページ）にある。

一覧の掲載と、危険度の点数は別

脆弱性の優先順位を決める材料には、危険度の点数（CVSSなど）もある。点数は、条件がそろったときにどれだけ深刻かを表す。一方、一覧への掲載は、実際に悪用された証拠があるかを示す。CISAは、一覧を、脆弱性の管理で優先順位を決めるときの入力として使うよう勧めている。点数が高いのに掲載されていない件と、点数がそれほど高くないのに掲載されている件が、ありうる。

期限を、自分で決める必要がある理由

日本の小さなサイトでは、ホスティング事業者や制作会社が更新する場合が多い。担当者は、一覧を毎日見ているわけではない。10月26日の追加を、27日にニュースで知り、28日に事業者へ聞き、29日に答えが返る、という流れは、十分にありうる。期限の日に、更新が済んでいるかを答えられる状態にするには、一覧の期限の欄を待たず、自分の期限を、自分で先に決めておく必要がある。

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

悪用が確認された脆弱性のカタログ（KEV）

期限の欄（Due Date）

一覧の表にある列で、「必要な対応」を終える日付が書かれている。誰がその日までに終える決まりかは、一覧のページの表そのものには書かれていない。

BOD 26-04と、連邦機関

つまり、期限の欄を義務として受けるのは、米国の連邦の行政機関である。州や地方の政府、民間の事業者は、この指令に拘束されない。ただしCISAは、これらの組織にも、一覧の脆弱性への対応を優先するよう、強く勧めている。

修正版と、緩和策

修正版は、脆弱性そのものが直った版で、基本の対策である。緩和策は、修正版が使えないとき、攻撃の届く経路を狭める暫定の手である。JPCERT/CCの注意喚起は、PHPの2件の緩和策は特定の攻撃経路への対処にとどまり、根本的な対策は更新だけだ、と書いている。

侵害の調査の列（Forensic Triage）

一覧の表に、BOD 26-04に基づく、侵害の痕跡を調べる手続きが必要かを示す列がある。PHPの2件はYes、Brotliの1件はNoだった。BOD 26-04のページは、この印が付く行の期限を3日とし、侵害の確認も求める、と書く。詳しい基準は、実施の手引きに書かれており、この記事では確かめていない。

04 型別 — 一覧の読み方と、期限の読み替え方

🅰 適用範囲 — この記事が向いているサイト

この記事は、PHPで動くサイトを、1つ以上担当している人に向いている。WordPressのサイトも、PHPで動く。WordPress公式は、今回のPHPの問題について、WordPress側の更新は要らず、必要なのはPHPの更新だと書いている。担当サイトが、PHPを使わない静的なサイトなら、PHPの2件は当てはまらない。ただし、一覧の読み方は、ほかの脆弱性にも使える。

🅱 この記事が確かめていないこと

• BOD 26-04の実施の手引きの全文（期限の表の細かい中身と、行ごとの理由）。ページ本体は開いて確かめた
• 期限の長さが、PHPの2件で3日、Brotliで14日と違う、行ごとの理由（一覧のページには書かれていない）
• 国内で、実際に被害が出ているかどうか（IPAは、把握していないと書いている）
• 修正が入ったかを、各サイトで確かめる具体的な手順（既存の記事とブログに書いてある）
• 日本の事業者ごとの、更新の運用の違い

🅲 手順1 — 一覧の行を、列ごとに読む

一覧の行は、追加日、期限の欄、ランサムウェアでの利用、侵害の調査の列、短い説明の順に読む。まず追加日と期限の欄の差を、日数で書く。次に、説明が、認証なしで遠隔からコードを実行できる、という趣旨になっているかを見る。最後に、必要な対応の欄で、更新か緩和策かを確かめる。

🅲 手順2 — 期限の欄を、自分の期限に読み替える

読み替えの案を、表にした。日数は筆者の案であり、公式の基準ではない。サイトの運用に合わせて、書き換えてよい。

最初の行の「3日」は、PHPの2件の期限の欄が、追加日から3日だったことを参考にした数字である。Brotliのように、期限の欄が14日の行は、14日を目安にしてよい。ただし、外から届く場所なら、短くする。いずれも、期限の欄を、そのまま自分の義務として採用する、という意味ではない。

🅲 手順3 — 該当するかを、版の表示ではなく、値で確かめる

PHPの版を、サーバーの表示（php -vなど）で見て「修正版だから大丈夫」と判断するのは、危ない。修正を入れても、版の表示が、入れる前と同じ文字のままのことがあるからである。当サイトの確かめ方は、ブログの記事に書いた。担当サイトの一覧に「修正が入ったかを、何で確かめたか」の欄を足す方法は、既存の解説記事に書いた。この記事では、その確かめ方を繰り返さず、リンクで案内する（08章）。

🅲 手順4 — 事業者への聞き方

事業者へは、3行のメールを1通送る。1行目に、「PHPの2件が、CISAの一覧に10月26日に載った」と、確認した日付を書く。2行目に、担当サイトのPHPが、修正版に更新済みか、更新した日はいつかを聞く。3行目に、更新できない事情があるなら、公式が示す暫定策を入れているかを聞く。返事の日付と、更新した日を、表に書き写す。返事が3営業日以内に来ないときは、電話で聞く。

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

以下は、CISAの一覧の読み方を確かめ、担当サイトの更新期限を決める13項目である。1〜3番目は一覧と説明のページの読み取り、4〜8番目は担当サイトの該当の確認、9〜11番目は事業者への確認、12〜13番目は期限と見直しの決め方である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• CISAの悪用確認リストのカタログを開き、CVE-2026-109618の行の「追加日」と「期限の欄」の2つの日付を、メモ帳に書き写す
• 同じカタログで、CVE-2026-109619とCVE-2026-111497の行の2つの日付を書き写し、3行それぞれの、追加日から期限の欄までの日数を数えて書く
• CISAの説明のページを開き、期限が義務になる相手として書かれている組織の種類を探し、その1文を日本語に直して、メモ帳に書き出す
• 担当サイトを、メモ帳か表計算に1行ずつ書き出し、各行に、PHPを使うか使わないかを「使う」「使わない」「不明」で書く
• PHPを使う各サイトのPHPの版を、ホスティングの管理画面か事業者への問い合わせで確かめ、表の「PHPの版」の列に書き写す
• IPAの注意喚起を開き、影響を受ける版と修正版の表（8.2.35、8.3.36、8.4.27、8.5.12）を見て、各サイトの版が修正版より前の行に印を付け、印の数を数える
• PHPの版が8.1以前のサイトの行に「サポート切れ」と書き、PHP公式のサポート期間の表で、8.2の系列のセキュリティ対応の終わりの日付を、表の上に1行書く
• 各サイトが、インターネットから誰でも開けるか、社内だけかを、「外から届く」「社内だけ」「不明」で、表の「公開の範囲」の列に書く
• 事業者に、3行のメールを1通送る。2026年10月26日にPHPの2件が一覧に載ったこと、更新済みかと更新した日、更新できない場合に公式の暫定策を入れているか、の3点を書く
• 事業者の返事の日付と、返事に書かれた更新の日を、各行の「更新日」の列に書き写す。返事が3営業日来ない行には「催促」と書く
• JPCERT/CCの注意喚起にある、侵害の調査の3つの観点（異常に長いPHPSESSIDのCookie、不審なmultipartのリクエストと前後のエラー、PHPのワーカーの異常終了）を、事業者へのメールに1行で足し、ログを見られるかを聞く
• 期限の案の表に従って、各行の「期限日」の列に日付を書き、日付の隣に、確かめる担当者の名前を書く
• CISAのカタログを開く日を、週に1回、カレンダーに繰り返しで登録し、開いたら、新しく追加された行のうち、担当サイトの製品名がある行を数える

06 代替・他の選択肢 — 更新の優先順位を決める、ほかの材料

一覧のほかに、優先順位の材料は4つある

一覧への掲載は、優先順位を決める材料の1つにすぎない。ほかの材料と、どう組み合わせるかを、表に並べた。

4つのうち、開発元の告知は、一覧より早い。今回、PHPの修正版が出たのは10月21日で、一覧に載ったのは26日である。一覧を待って動くと、5日遅れる。一覧を、「期限を短くする理由」として使い、更新そのものは、開発元の告知の日に始める形のほうが、早く動ける。これは筆者の考えである。

更新できない事情があるとき

サイトの事情で、すぐに更新できないことがある。そのときは、公式が示す暫定策を入れる。PHPでは、セッションのアップロード進捗の設定を0にする方法が、JPCERT/CCの注意喚起（10月26日の追記）で案内されている。ただし、JPCERT/CCは、緩和策は特定の攻撃経路への対処にとどまり、根本的な対策は更新だけだ、とも書いている。暫定策を入れた日と、更新する予定の日を、同じ行に書く。

Cloudflareが10月27日に出した記事は、WAF（Webアプリケーションファイアウォール）は、脆弱なソフトウェアを直すことの代わりにならない、と書いている。また、すでにサーバーの側で行われた操作は、WAFでは取り消せない、とも書いている。暫定策や、WAFで守っていても、更新の期限は消えない。

更新が間に合わない場合の、公式の助言

英国のNCSCは、更新が、すぐにできないときの選択肢を挙げている。公式の暫定策を入れる。それも難しいときは、システムをいったん止めることを検討する。更新も止めることもすぐにできないときは、更新の前に、侵害の痕跡やバックドアがないかを調べる。担当サイトで、この判断を、担当者の側ですぐに決めるのが難しいときは、事業者に、止める判断を誰がするかを、先に聞いておく。

07 当サイトで確かめたこと — 一覧に載る前の更新の日付と、外から見える応答

当サイトは、PHPで動いている。したがって、PHPの2件の更新の対象である。2026年10月29日に、当サイトの記録と、外から見える応答を確かめた。

更新は、一覧に載る前に済んでいた

当サイトの記録では、PHP公式の告知（10月21日）の翌日の10月22日の未明に、PHPを、公式の修正を当てて作り直したものに入れ替えた。一覧に加わったのは、その4日後の10月26日である。入れ替えの手順と、修正が入ったかを値で確かめた方法は、ブログに書いた（08章のリンク）。この記事の読み方に当てはめると、当サイトは、「一覧に載った後に動いた」のではなく、「告知の翌日の未明までに動いた」側にあたる。

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

トップページ、AI Ronのブログの一覧と記事、解説記事の一覧と記事、無料ツールの一覧、運営者ブログの一覧、お問い合わせの画面の、8ページの応答ヘッダーを取った。PHPの版を示すX-Powered-Byの行は、8ページすべてで、0件だった。ヘッダーに版が出ていないことは、外から版を知られにくいという意味である。ただし、修正が入った証拠にはならない。証拠は、別の方法（ブログに書いた）で確かめた。

当サイトで確かめていないこと

• BOD 26-04の実施の手引きの全文（期限の表の細かい中身は確かめていない）
• 一覧に載った後の、悪用を試みる通信が、当サイトに届いたかどうか（この記事では数えていない）
• 他の事業者が運用するサイトの、更新の状況

当サイトの記録が言えるのは、当サイトの更新は10月22日に済んでいた、ということまでである。担当サイトも同じとは、限らない。それぞれのサイトで、05章の4〜8番目を、自分で確かめる。

08 このテーマは、ここまで

PHPの脆弱性については、これまでにも、観点を分けて書いてきた。この記事は、一覧の期限の欄の読み方に絞った。

PHPの脆弱性そのものの説明

PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録は、脆弱性の中身と、更新の順番を、1本にまとめた記事である。この記事は、その中身に入らない。

修正が入ったかを、値で確かめる

PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録は、04章の手順3で触れた、版の表示だけでは分からない理由を書いた。PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）は、暫定策の設定を扱った。

担当サイトの一覧と、事業者への確認

PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）は、サイトを一覧にする方法を書いた。WordPressの更新は要らないが、PHPの更新は要る。公式の記事が書いたこと ── サイトヘルスで版を見て、事業者に確かめる13項目（2026年10月時点）は、WordPressのサイトで、PHPの版を見る場所と、事業者への確かめ方を書いた。

WAFや、攻撃の痕跡の話

WAFの限界は、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）で書いた。ログの痕跡の見方は、PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）に書いた。

同じ一覧に載った、別の件

同じ一覧に載ったBrotliの件は、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）と、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方で扱った。同じ一覧でも、行ごとに、期限の欄の長さが違った。

2026年10月29日 — この記事の確認日

この記事の内容は、2026年10月29日に、CISAのカタログと説明のページ、IPAとJPCERT/CCの注意喚起、PHP公式のページ2本、WordPress公式、英国NCSC、Cloudflare、Brotliのリリースページを開いて確かめた時点のものである。期限の欄や、IPAの注意喚起が更新されたときは、日付つきで追記する。