PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法

PHPの重大な脆弱性「php2shell」（CVE-2026-109618とCVE-2026-109619）が、10月26日に、アメリカのCISAが管理する悪用が確認された脆弱性の一覧（KEV）に載った。一覧には「期限」の欄があり、この2件の期限は10月29日。今日だ。

「期限が今日」と聞くと、日本の小さなサイトを担当するWEBディレクターは戸惑うと思う。この期限は、誰が、誰に向けて決めたものなのか。自分のサイトでは、いつまでに何をすればよいのか。この記事は、期限の日に当サイトで確かめたことを4つ書きながら、その読み替え方を整理する。

確かめたのは、動いているPHPの値、入れ替えた10月22日から今日までのログ、そして自分の記事の言い過ぎ（PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで書いたことの一部が、そのままでは他の版に通じなかった）、最後に、修正の部品が来たかを探す先を取り違えていたこと、の4つだ。安全のため、当サイトのPHPや部品の版の番号、サーバーの構成、ファイルの置き場所、設定の数値は書かない。書くのは、件数、数え方、順番、確かめ方までだ。

何が起きたか ── 3行で、そして日付の並べ方

3行で言うと

• PHPの2件の脆弱性は、認証なしで遠隔からコードを実行されうるもので、10月21日から22日にかけて修正版が出た。
• 10月26日、CISAはこの2件を、実際に悪用された脆弱性の一覧に加えた。一覧に書かれた期限は、3日後の10月29日だった。
• 期限の日に、当サイトで4つを確かめた。修正を入れた本体は動き続けていて、異常な応答の記録は無く、自分の記事には直すべき言い過ぎがあり、修正の部品が来たかを探す先も取り違えていた。

日付を並べると

順番が分かると、「期限」が何の期限かが見えてくる。公開されている日付を、当サイトの動きと並べた。

更新の順番や、更新の後に確かめることはPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でがまとめている。ここでは繰り返さない。

KEVとは何か ── そして「期限」は誰のための決まりか

一覧に載る3つの条件

KEVは、Known Exploited Vulnerabilities（悪用が確認された脆弱性）の略だ。CISAの説明ページによると、一覧に載せる条件は3つある。脆弱性の番号（CVE）が付いていること。実際に悪用されたという確かな根拠があること。そして、更新版のような、はっきりした対処があること。2つ目を、CISAはこう書いている。

"There is reliable evidence that the vulnerability has been actively exploited in the wild."
（日本語訳: その脆弱性が、実環境で実際に悪用されているという、確かな根拠がある。）

ここでいう悪用には、成功した悪用だけでなく、悪用の試みも含まれる、とCISAは書く。

「脆弱性が見つかった」と「悪用されている」は別の段階だ。KEVに載るのは後者で、これが、ふつうの脆弱性情報よりも優先して読む理由になる。

期限は、アメリカの連邦機関に向けた決まり

では、一覧の「期限」は誰のものか。CISAの説明ページは、こう書いている。

"All federal civilian executive branch (FCEB) agencies are required to remediate vulnerabilities in the KEV catalog within prescribed timeframes under BOD 26-04: Prioritizing Security Updates Based on Risk."
（日本語訳: 連邦政府の文民の行政機関は、すべて、KEVの一覧にある脆弱性を、BOD 26-04（リスクに基づいて更新を優先する指令）が定める期間内に直すことが求められている。）

BODは、Binding Operational Directive（拘束力のある運用指令）の略で、連邦機関に向けた指令だ。指令の本文にも、その位置づけが書かれている。つまり、一覧の期限が「守らなければならない決まり」として働くのは、アメリカの連邦の行政機関に対してだ。日本の民間のサイトに、この期限を守る義務があるわけではない。

ただし、CISAは民間にも読んでほしいと、はっきり書いている。

"Although not bound by BOD 26-04, every organization, including those in state, local, tribal, and territorial (SLTT) governments and private industry can significantly strengthen their security and resilience posture by prioritizing the remediation of the vulnerabilities listed in the KEV catalog as well."
（日本語訳: BOD 26-04に拘束されなくても、州・地方・部族・準州の政府や民間の企業を含むすべての組織は、KEVの一覧にある脆弱性の対処を優先することで、安全性と回復力を大きく高められる。）

義務ではないが、優先順位の材料としては使ってほしい。これが、一覧の期限の正しい読み方だと思う。

「3日」の意味を、確かめた範囲で

一覧のデータを取り直すと、2件とも追加日は10月26日、期限は10月29日で、ちょうど3日後になっている。同じ項目には、フォレンジックの確認（侵入されていないかの調べ）をする必要がある、という印も付いていた。指令の本文は、この印の意味をこう説明している。

"the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised."
（日本語訳: 機関は、その期間（3日）のうちに、修正または緩和の措置を終え、そのうえで、資産に対してフォレンジックの一次確認を行い、システムが侵害されていないかを評価しなければならない。）

ここで言えるのは、この2件について、期限は3日で、直すだけでなく「入られていないかの確認」も求められている、ところまでだ。指令の表にある細かい条件は、この記事では読み解いていない。

日本の小さなサイトでの読み替え方

期限を、自分で決める基準

義務ではないなら、期限は自分で決めることになる。決めるときに使う材料は、CISAの指令が優先順位の変数として挙げているものから、「外に公開されているか」「攻撃を自動で繰り返せるか」「乗っ取られたとき相手がどこまで支配できるか」の3つを借りる。ここから先の表は、この3つを小さなサイト向けに言い換えた、当サイトの考え方であって、CISAの決まりではない。

期限を決めたら、その場で記録に残してほしい。残すのは4つだけだ。誰が決めたか、決めた日、理由（この表のどの行に当たると判断したか）、見直す日。あとで誰かに「なぜ3日だったのか」「なぜ公開を止めなかったのか」と聞かれたとき、記録があれば、結果が良くても悪くても、判断の筋道を説明できる。記録が無いと、結果だけで判断が評価されてしまう。

「3日以内に更新」が難しい場合もある。更新で動かなくなる部品があるかもしれない。その場合も、期限は「更新を終える日」ではなく、「どう対処するかを決めて、手を打つ日」と読み替えるとよい。

更新できない場合に、CISAとIPAが書いていること

CISAの注意喚起は、更新できない場合について、こう書いている。

"Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated."
（日本語訳: すぐに更新できない組織、またはPHP 8.1以前のサポートが終わった版を使い続ける組織は、更新できるまで、PHPを使うシステムをオフラインにすべきだ。）

強い言い方だ。IPAのページも、更新が難しいときは、暫定の対策をとり、それも難しければ外部からのアクセスの遮断や、サービスの一時停止が必要かを判断するよう書いている。「公開を止める」を、最後の選択肢として持っておく、という考え方は、両者で一致している。

守りを足すことについては、CISAは次のように書いている。

"A web application firewall may provide some protection until systems are updated or patched."
（日本語訳: Webアプリケーションファイアウォールは、システムが更新されるまでの間、ある程度の守りになりうる。）

「ある程度」であって、更新の代わりではない。この点はPHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いたで詳しく書いた。IPAは、国内での被害の事例は把握していないとも書いているが、これは「被害が無い」という意味ではない。把握していない、というだけだ。

期限の日に確かめた1: 動いているPHPの値

3つ聞いた

期限の日の朝、当サイトのWebを受けているPHPの処理そのものに、次の3つを聞いた。コマンドで呼ぶPHPではなく、実際にページを返しているほうだ。この区別は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで書いたとおり、大事な前提になる。

• 修正で増えた設定の名前が、設定の一覧に、今も在るか。
• アップロードの進捗の機能（session.upload_progress.enabled）が、止めたまま（Off）か。
• 入れたパッケージが、10月22日に作り直した版のままか。配布元に、公式の新しい版が出ていないか。

結果は、3つとも期待どおりだった。設定の名前は今も一覧に在る。10月22日の入れ替えのあと、10月28日にサーバーが予定外に止まって起動し直された（その話は圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったに書いた）が、その後も残っている。アップロードの進捗は、10月22日から止めたままだ。パッケージは10月22日に作り直した版のままで、配布元の一覧には、公式の新しい版は、今日の時点でまだ出ていない。

この確認が示すことと、示さないこと

ここで、慎重に書いておきたい。設定の名前が在ることは、「入れ替えた本体が、巻き戻されずに動き続けている」ことの確認にはなる。ただし、それが「修正がすべて入っている」ことの証拠になるわけではない。この名前の扱いについては、次の節で、自分の言い過ぎを直す。

期限の日に、修正を確かめ直す意味は、2つある。1つは、更新のあとに、再起動や巻き戻しで元の状態に戻ることがあるからだ。もう1つは、暫定策として止めた機能が、別の作業のついでに戻っていないかを見るためだ。入れ替えた日に確かめても、1週間後に同じとは限らない。

期限の日に確かめた2: ログ

入れ替えた日から、日ごとの件数

10月22日から今日までの、HTTPSのアクセスの記録を、日ごとに数えた。日付は、記録の行の中に書かれた日付で分けている。

500は全日で0件、POSTでの500も0件だった。5xx全体では、10月27日に1件ある。この1件は、解説記事1本に対する503が1回だった（応答は339バイト）。PHPの処理の異常の記録ではない。原因は、確かめていないので書かない。10月28日は、約20分、サーバーが止まった日だ（圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった）。

PHPの処理の記録では、10月22日から29日にかけて、メモリの上限に達した記録（Allowed memory size）は0件で、処理が異常に終わった記録（シグナルでの終了）も0件だった。ウェブサーバーのエラーの記録でも、メモリの上限の記録は0件、「in Unknown on line 0」という記録も0件（10月23日から29日）。

今回の欠陥は、メモリの扱いの異常に関わるものだ。その種類の異常が、記録に出ていない、というのが、数えた結果になる。

数え方の失敗と、言えないこと

この表は、1回目の集計が間違っていた。最初に数えたとき、10月28日が、たった1行になった。記録は毎日まとめて圧縮される。ところが、いちばん新しい1日分だけは、圧縮される前の形で置かれている。圧縮されたファイルだけを数えると、その1日分を丸ごと落とす。数え直して、8,036行になった。

この失敗から、1つ決めた。「0件」や「1行」が出たら、結果を信じる前に、数えた範囲が正しいかを疑う。0が出るのは、本当に無いときと、見ていないときの2通りだからだ。同じ型の話は、PHPの脆弱性の「痕跡」は、ログに無いこともあるにも書いた。

もう1つ、言えないことを書いておく。アクセスの記録に残るのは、要求の行と、結果の番号だけだ。送られた中身は残らない。だから、「攻撃が来なかった」とは言えない。言えるのは、「500などの異常な応答の記録は無かった」までだ。侵入の有無の確認には、別の調べが要る。調べ方は、PHPの脆弱性の「痕跡」は、ログに無いこともあるとPHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でにまとめた。

期限の日に確かめた3: 自分の記事の言い過ぎ

何を書いていて、何が足りなかったか

PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで、俺は、修正が入ったかを値で確かめる方法として、ある設定の名前（max_multipart_body_parts）を挙げた。当サイトの入れ替えでは、入れ替える前の本体に0か所、後に2か所あり、前後の比較として使えた。記事には、どのサイトにも通じるとは限らないこと、いつの版で加わった設定かは公式の文書で確かめていないことも、書いてあった。

ところが、10月28日に、別の仕事で古いPHPを調べたとき、修正前のはずの古い版にも、この設定の名前が在った。気になって原典に当たると、この設定は、今回の2件の修正ではなく、2023年の別の修正で加わったものだった。

原典で確かめたこと

確かめたのは、3つの原典だ。

さらに、現在のソースの8.0、8.1、8.2、8.4の枝のどれにも、この設定が、初期値「制限なし」（-1）で登録されていることを見た。つまり、2023年の修正を持つ版には、今回の修正とは関係なく、この名前が在る。

では、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったの方法は、どこまで使えるのか。入れ替える前の本体が2023年の修正を持たず、入れ替えた後の本体が持つ台なら、前後の比較として目印になる。当サイトの台は、そうだったと読める。だから、当サイトでの比較は、間違いではない。しかし、他の版では、名前が在っても、今回の修正が入った証拠にならない。記事で「どのサイトにも通じるとは限らない」と書いたのは正しかったが、「目印になる」と書いた強さは、言い過ぎだった。そこで、10月29日に、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったに日付つきの追記を足した。

読者への学びは、2つある。1つ目。修正の目印にする設定の名前は、「いつの、どの修正で加わったか」を、変更履歴と勧告で確かめてから使う。2つ目。自分の記事の言い過ぎは、別の仕事のついでに見つかる。見つけたら、元の記事に、日付つきで足す。消さない。

期限の日に確かめた4: 配布元の取り違え

10月29日の朝、チームの仲間のサイトで、圧縮の部品（Brotli、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった）のOS側の直った版が、配布元から出た、と聞いた。当サイトの台でも探したが、まだ無かった。

理由は、当サイトの台の配布元が、仲間の台とは別のものだったからだ。自分の記録の中に、配布元を仲間の台と同じ名前で書いている所があった。公開した記事には無かったが、記録が間違っていたことに変わりはない。

学びは1つだ。「直った版が出たか」は、仲間の台や報道ではなく、自分の台の配布元の一覧で確かめる。配布元の名前は、記録に書く前に、台の中で確かめる。仲間の台で出ていても、自分の台に来ているとは限らない。逆に、自分の台で出ていないことを理由に、安心もできない。

担当サイトを任せている場合は、事業者に「更新の知らせは、どこの配布元の一覧で見ていますか」と聞くのがよい。答えが「ニュースで見た」「他のお客さんの台で出ていた」なら、その台の配布元で確かめる習慣は、まだ無い。ここは責める場面ではない。確かめる先を、一緒に決める場面だ。

この取り違えが怖いのは、間違いが静かに起きることだ。誤った配布元を見ていても、画面にエラーは出ない。「まだ出ていない」という正しい結果が返るだけで、見ている場所が違う、ということには、結果を見ただけでは気づけない。今回気づけたのは、仲間の台では出ているのに、自分の台では無い、という食い違いがあったからだ。食い違いが無い日は、気づく手がかりが無い。だから、配布元の名前を、確かめた日付つきで一覧に書いておく。

WEBディレクターが、期限の日にやること

自分で確かめられる場合

1. 担当サイトのうち、PHPを使い、外から届くものを一覧にする。PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るの8列の一覧が使える。
2. 一覧の各行に、PHPの系統が「修正版が出る系統」か「サポートが終わった系統」かを書く。
3. 修正を入れたサイトは、Webを動かしているPHPの設定の一覧に、公式の勧告に書かれた変化が出ているかを見る。目印の名前は、いつ加わったかを確かめてから使う。
4. 入れ替えたあと、再起動したか、動いているプロセスが新しい本体を使っているかを確かめる。
5. 暫定策として止めた機能（アップロードの進捗など）が、止まったままかを見る。使っていないことを、先に確かめる。PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めたに13項目がある。
6. 期限の日から今日までのログを、日ごとに数える。圧縮された記録と、まだ圧縮されていない最新の記録の両方を数える。
7. 「異常な応答の記録は無かった」と、「攻撃は無かった」を、分けて書く。
8. 更新できないサイトは、更新、公開の停止、守りの追加のどれにするかを決め、決めた日を記録に残す。
9. 外から見える範囲は、🔧 外からできるセキュリティ対策監査ツール（会員登録が必要）で見られる。ただし、修正の有無までは分からない。
10. 確認の前後の画面は、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールで、日付つきで残せる。

制作会社・サーバーの担当への聞き方

任せているサイトでは、「PHPの対応はしましたか」と聞くだけでは、「対応済みです」で終わってしまう。次のように、確かめられる形で聞く。

• 担当サイトのPHPは、サポート中の系統ですか。修正版、または移植の修正を、入れた日はいつですか。
• 入れたあと、再起動しましたか。動いている本体は、新しいものですか。
• どの目印で、修正が入ったと確かめましたか。その目印は、いつ、どの修正で加わったものですか。
• アップロードの進捗の機能は、止めてありますか。止める前に、使っていないことを確かめましたか。
• 10月22日から今日まで、異常な応答の記録はありましたか。数えた範囲（圧縮された記録を含むか）も教えてください。
• 配布元の更新を、自分の台の配布元の一覧で確かめていますか。

疑うための質問ではない。確かめる材料を、お互いに出し合うための聞き方だ。返事の読み方は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったの表にまとめてある。

期限の翌日以降にやること

期限の日は、終わりではなく、確認の始まりだ。翌日以降にやることを、3つに絞って書く。

• 1週間後に、同じ確認をもう一度やる。更新のあとの再起動や、別の作業のついでの巻き戻しは、数日たってから出ることがある。この記事の確認は、日をおいて繰り返す前提で書いた。
• KEVの一覧を、定期的に見る習慣をつける。CISAは、一覧に追加されたときのメールでの通知を用意している。自分の使う製品の名前（PHP、使っているCMS、サーバーのソフト、部品）が一覧に載っていないかを、週に1回、見る。載っていたら、この記事の表で期限を決める。
• 更新のたびに、「何で確かめたか」を一覧に書く。版の番号だけを書いた記録は、次に誰かが読んだとき、確かめた記録として使えない。

当サイトの現在地

✅ 当サイト実施済 期限の日に、動いているPHPの値で、修正の目印となる設定の名前が今も在ること、アップロードの進捗が止まったままであること、パッケージが10月22日に作り直した版のままであることを確かめた。

✅ 当サイト実施済 10月22日から29日のログを日ごとに数え、500などの異常な応答の記録（5xxは10月27日に1件。解説記事1本への503が1回）と、メモリや異常終了の記録を確かめた。「攻撃が無かった」とは言えない範囲も書いた。

✅ 当サイト実施済 PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったの言い過ぎを原典で確かめ、10月29日に日付つきで追記した。

🔧 当サイトこれから 圧縮の部品のOS側の直った版が、自分の台の配布元から出たら替える。替えたあとは、前後の応答と画面を比べる。

🔧 当サイトこれから 担当サイトの一覧に「配布元」と「修正が入ったかを何で確かめたか」の欄を足す。PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったで書いた約束の続きで、今日はまだ足していない。

まとめ

持ち帰ってほしいことは、5つだ。

1. KEVの期限は、アメリカの連邦機関に向けた決まりで、日本の民間のサイトに義務は無い。ただし、CISAは民間にも優先順位の材料として使うよう書いている。
2. 自分のサイトの期限は、「外から届くか」「修正版が出る系統か」で決める。3日という長さは、一覧の期限と同じ目安にできる。
3. 期限の日には、修正が残っているか、止めた機能が止まったままか、ログに異常が無いかを、値と件数で確かめる。
4. 修正の目印にする設定の名前は、いつ、どの修正で加わったかを原典で確かめてから使う。
5. 「直った版が出たか」は、自分の台の配布元で確かめる。仲間の台や報道では分からない。

確かめていないことも書いておく。10月27日の5xx1件は、解説記事1本への503が1回で、その原因は確かめていない。送られた中身を見ていないため、侵入の有無は、この記事では判断していない。10月21日の修正が、2件のすべての経路を塞いでいるかは、公式の勧告の範囲でしか言えない。

関連 archives（連載軸として読む）

• PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録 ── 版の表示は修正の証拠にならないという話。今回、一部を直した記事（10月26日）
• PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録 ── 更新の順番と、更新の後に確かめることをまとめた記事（10月22日〜23日）
• 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方 ── 圧縮の部品の脆弱性と、同じ日にサーバーが止まったあとの確かめ方（10月28日）
• 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 ── 公開の場所に残った控えを数えて外へ移した記録（10月23日）

解説記事では、CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった（米国の期限を、担当サイトの自分の期限に読み替える13項目）、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る、PHPの脆弱性の「痕跡」は、ログに無いこともある、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載ったもあわせて読める。

出典

• CISA: Known Exploited Vulnerabilities Catalog（CVE-2026-109618・CVE-2026-109619の項。追加日は2026年10月26日、期限は10月29日）
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: BOD 26-04 Prioritizing Security Updates Based on Risk（2026年6月10日）
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching（10月26日更新）
• IPA: PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)（10月27日更新）
• PHP.net: PHP 8 ChangeLog
• GitHub: php-src Security Advisory GHSA-54hq-v5wp-fqgv（CVE-2023-0662）
• GitHub: php-src commit 716de0cf「Introduce max_multipart_body_parts INI」