JPCERT/CCはPHPの注意喚起を10月29日に更新し、ファイアウォール製品の特定の版で侵害の成功を示唆する痕跡が報告されたと追記した ── サーバーの外にあるPHP同梱の製品を台帳に足して確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — 10月29日の更新で、被害の話が「サイトのPHP」から「製品の中のPHP」へ広がった
   1. 注意喚起の経過を、改訂の日付で並べる
   2. 2026年10月29日に足されたこと（要旨）
   3. もともとの本文が書いていた、製品についての一文
   4. 原文が書いていないこと
2. 02 なぜ・背景 — サイトのPHPと、製品の中のPHPは、更新の持ち主が違う
   1. 担当サイトのPHPは、自分たちか事業者が更新できる
   2. 製品の中のPHPは、持ち主が提供元になる
   3. 境界の機器が足がかりにされると、何が変わるか
   4. 日付を、開いたページごとに並べる
   5. 修正版は、サイトのPHPに出ている
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「同梱」と「組み込み」
   2. ファームウェアとアドバイザリ
   3. 境界の機器
   4. バックポート
   5. 台帳の「状態」の区分
4. 04 型別 — PHP同梱の製品が、会社の中にいる5つの場所
   1. サーバーだけを見ても、足りない
   2. 5つの場所の整理
   3. 場所1と場所2は、外から見える場合がある
   4. 場所3は、事業者の告知を探す
   5. 場所4は、制作会社の資産も含める
   6. 場所5は、サーバーの台帳と重なる
   7. 聞く相手は、3つに分かれる
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 提供元の更新を待つ間の、扱いを決める
   1. 台帳の欄を、先に決める
   2. 選択肢を、4つに分ける
   3. 提供元に尋ねるメールの例
   4. 分かれ道を、図に書いておく
   5. 更新できない間の手当ては、提供元の案内に従う
   6. 「調査中」を放っておかない
   7. 侵害を疑うときに、原文が挙げた確認先
7. 07 当サイトで確かめたこと — この記事の台帳は、これから作る
   1. サーバーのPHPの確かめは、別の記事に書いた
   2. サーバーの外の製品の台帳は、まだ作り終えていない
   3. サーバーの中身は、ここには書かない
8. 08 このテーマは、ここまで
   1. この記事で扱った範囲
   2. この記事で扱っていないこと
   3. 関連する、これまでの記事
   4. 2026年10月30日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — 10月29日の更新で、被害の話が「サイトのPHP」から「製品の中のPHP」へ広がった

JPCERT/CCは、PHPの重大な脆弱性についての注意喚起を、2026年10月22日に公開し、その後に更新を重ねている。2026年10月29日の更新では、PHPを組み込んだ製品、とくにファイアウォール製品に話が及んだ。この記事は、その部分だけを取り上げる。PHPそのものの更新や、サーバーの設定の確かめ方は、すでに書いた記事に任せ、ここでは担当サイトのサーバーの外側にあるPHPを主題にする。攻撃の手順や、攻撃に使われた技術の細部は書かない。守る側が確かめることだけを書く。

注意喚起の経過を、改訂の日付で並べる

注意喚起の末尾にある改訂履歴は、次の4回の変更を示している。

• 2026年10月22日: 公開。
• 2026年10月22日: 「侵害調査」の節の表現を一部修正。
• 2026年10月26日: 「概要」と「緩和策」に情報を追記。
• 2026年10月29日: 「概要」と「参考情報」に情報を追記。

履歴からは、日付ごとにどの節が変わったかまでが分かる。10月26日の追記の中身は、この記事では取り上げない。取り上げるのは、10月29日の「概要」と「参考情報」の追記である。

2026年10月29日に足されたこと（要旨）

10月29日の追記の要旨を、4つに分ける。

• ファイアウォール製品の特定の版で、侵害の成功を示唆する痕跡が報告されたと書かれている（出どころは外部の報告で、JPCERT/CCが注意喚起に書いている）。侵害されたとみられる機器から、内部のネットワークへ広げようとした形跡があるとも書かれている。
• 攻撃者が、今回のPHPの脆弱性と、Linuxカーネルの権限を上げる脆弱性を組み合わせて使った形跡があると読める記述がある。どのカーネルの脆弱性かは、筆者が開いた範囲では確かめられなかった。
• 「参考情報」に、NCSC-NLが公開している、影響を受ける製品の一覧が加わった。どの行が10月29日の追加かまでは、改訂履歴からは分からない。
• 一部の製品の提供元も、悪用の観測を受けてアドバイザリを更新したと書かれている。

もともとの本文が書いていた、製品についての一文

製品の話は、10月29日に突然出てきたわけではない。注意喚起の「II. 対象」の節は、PHPを組み込んだ製品や、Linuxのディストリビューションが提供するPHPも影響を受けうるので、それぞれの提供元の情報も確認するよう求めている。10月29日の追記は、この一文を、実際に痕跡が報告された事例で裏づけた形になる、と筆者は読む。

原文が書いていないこと

この記事を書いた時点で、確かめられなかったことを先に書いておく。侵害されたとされる製品の名前と版の番号は、筆者が開いた範囲では確かめられなかった。外部のブログが書いたとされる被害の台数も、JPCERT/CCの本文に書かれた範囲を超えるので、数字として使わない。「自分の会社の製品が当たっているか」は、記事からは分からず、提供元の情報で確かめるしかない。後ろの章は、その確かめ方を書く。

02 なぜ・背景 — サイトのPHPと、製品の中のPHPは、更新の持ち主が違う

担当サイトのPHPは、自分たちか事業者が更新できる

ふつう、担当サイトのサーバーのPHPは、自分たちか、契約先の事業者が更新する。版は画面やコマンドで見えるし、更新できない間の暫定の設定も、自分たちで変えられる。当サイトも、サーバーのPHPについては、記事PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に、手順を書いた。

製品の中のPHPは、持ち主が提供元になる

製品に組み込まれたPHPは、事情が違う。製品の利用者は、中のPHPだけを取り出して更新することが、ふつうはできない。更新は、提供元が製品の更新として出すのを待つことになる。版の番号も、画面に出るのは製品の版であって、PHPの版ではないことが多い。これは筆者の読みで、製品ごとに違いうる。だから、提供元の案内を、製品ごとに開いて確かめるしかない。

境界の機器が足がかりにされると、何が変わるか

10月29日の追記は、侵害された機器から内部のネットワークへ広げようとした形跡に触れている。筆者の読みでは、これは、確かめる範囲が変わることを意味する。サイトのサーバーだけを見ていれば足りる事例とは違い、境界の機器が侵害されたなら、その内側にあるものも、確かめる対象になる。ただし、何が実際に内側で行われたかは、注意喚起には細かく書かれていない。この記事も、推測では書かない。

日付を、開いたページごとに並べる

開いたページの日付を、古い順に並べた。

修正版は、サイトのPHPに出ている

PHP公式のニュースによると、2026年10月21日に、8.5.12、8.4.27、8.3.36、8.2.35が出た。8.1以前には、プロジェクトからの修正版は出ていない。7.4、8.0、8.1には、php.netが、ソースから作る人向けの最小限のバックポート（リリースではない）を公開した。JPCERT/CCは「緩和策」の節を設けているが、php.netはこの修正を「最小限のバックポート」と呼んでいる。ここまでは、サイトのPHPの話である。製品の側に修正が届くのは、この後の、提供元の作業の順番による。

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

「同梱」と「組み込み」

ファームウェアとアドバイザリ

境界の機器

この記事で「境界の機器」と呼ぶのは、会社の内側のネットワークと、外のインターネットの間に置く機器である。ファイアウォールがその代表である。外と内の間にあるので、外から見える場所に、管理の画面がある場合がある。これも、製品ごとに確かめる。

バックポート

PHP公式のニュースは、ディストリビューションやLTS（長期サポート）の提供元が、バックポート版を出している場合があると書く。バックポートは、新しい版で直した内容を、古い版に移して直すことである。版の番号が上がらないまま、中身だけ直る場合がある。製品でも、同じことが起きうる、と筆者は読む。そのため、版の番号だけで、直ったかを判断しない。当サイトが、サーバーのPHPで版の番号が同じ文字だった経験は、記事PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。

台帳の「状態」の区分

NCSC-NLの一覧のページは、製品ごとの状態を、修正済み、脆弱、調査中、影響なし、未評価・不明といった区分で示している。担当サイトの台帳でも、同じような区分を借りると、人によって「だいたい大丈夫」の意味が違う、という事態を避けられる。区分の借り方は、後ろの章で書く。

04 型別 — PHP同梱の製品が、会社の中にいる5つの場所

サーバーだけを見ても、足りない

当サイトの記事PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）は、サイトごとの台帳を作る話だった。この記事は、その外側に、製品ごとの台帳を足す話である。担当サイトのサーバーを全部更新しても、サイトの前に置いた機器や、会社の中の管理ツールの中のPHPは、別に残る。

5つの場所の整理

PHP同梱の製品が会社の中にいる場所を、5つに分けた。この分け方は、出典に書かれたものではなく、探す場所を決めるための筆者の整理である。どの製品がPHPを同梱しているかは、製品ごとに、提供元の情報で確かめる。

場所1と場所2は、外から見える場合がある

境界の機器や、管理画面のある機器は、管理画面が外のインターネットから開ける設定になっている場合がある。開けるかどうかは、機器ごとの設定と、ネットワークの組み方による。外から開けるなら、悪用の試みも届きうる、と筆者は読む。外から管理画面が開くかは、後ろのチェックリストで、実際に開いて確かめる。

場所3は、事業者の告知を探す

ホスティングやサーバーの管理ツールのPHPは、自分たちでは更新できないことが多い。事業者が告知を出す場合は、告知を開いて、日付と対象の範囲を台帳に写す。出ていないなら、問い合わせる。問い合わせの文面は、後ろの章で例を示す。

場所4は、制作会社の資産も含める

自社のサーバーに入れるパッケージの業務ソフトは、PHPの上で動くものが多い。ソフトの更新と、PHPの更新が、別々に必要になる場合がある。制作会社が納品したものは、制作会社が台帳を持っていることもあるので、担当者に聞いて、書き出してもらう。

場所5は、サーバーの台帳と重なる

場所5は、サーバーのパッケージとして入っているPHPである。これは、サイトごとの台帳（PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要るの話）と重なる。注意喚起も、ディストリビューションの提供元の情報を確認するよう求めている。パッケージを更新したあとも、古い部品を掴んだまま動き続けるプロセスが残る場面は、記事圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方に書いた。

聞く相手は、3つに分かれる

製品を書き出すとき、1人にまとめて聞いても、全部は出てこない。筆者の整理では、聞く相手は3つに分かれる。1つ目は、情報システムの担当者で、社内の機器やネットワーク図を持っている。2つ目は、制作会社や保守の会社で、納品した業務ソフトや、預かっているサーバーの一覧を持っている。3つ目は、契約を結んだ総務や経理で、毎月の請求書から、使っているサービスの名前が分かる。この3つの答えを重ねると、1つだけでは見えなかった製品が出てくる。

聞くときは、「PHPを使っているか」とは尋ねない。担当者は、PHPで作られているかを知らないことが多い。尋ねるのは、製品の名前、提供元、保守の窓口である。PHPを同梱しているかどうかは、そのあとで、提供元の案内で確かめる。

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

以下は、担当サイトのサーバーの外にあるPHP同梱の製品を台帳に足す、13項目である。1〜3番目は書き出す作業、4〜9番目は版と提供元の情報の確認、10〜13番目は問い合わせと決め方である。1項目は5分以内でできる。確かめた結果は、台帳に日付つきで書く。

• 担当サイトのサーバーの外で、ネットワークにつながる機器や製品を、部署ごとに書き出し、台数を数字でメモに書く
• 保守の契約の一覧を開き、1製品につき1行で、提供元の名前と保守の窓口を書き写す
• 書き出した製品のうち、管理画面を持つものに印を付け、その数を書く
• 印を付けた管理画面のアドレスを、社外のスマートフォンの回線につないだ端末で1回ずつ開き、開いたか開かなかったかを書く。自社が持ち主の画面だけで試す
• 製品ごとに、管理画面か本体の画面で版の番号を見て、台帳の版の欄に書き写す
• 製品ごとに、提供元のアドバイザリのページを開き、「PHP」「CVE-2026-109618」「CVE-2026-109619」で検索して、見つかった件数を書く
• NCSC-NLの一覧のページを開き、書き出した製品の提供元と製品名で検索して、状態の区分を書き写す
• 製品ごとの状態を、影響あり・調査中・影響なし・記載なしの4つのどれかで台帳に書く
• 影響なしと書いた製品は、その根拠にした提供元のページのアドレスと、そのページの更新日を台帳に貼る
• 影響ありか調査中の製品は、提供元の次の案内の予定日が書かれているかを探し、あれば日付を、なければ「記載なし」と書く
• 影響ありか調査中で、外から管理画面が開いた製品は、アクセス元を絞る設定ができるかを、設定画面か保守の窓口で1回確かめて書く
• 影響ありか調査中の製品の保守の窓口へ、影響の有無と更新の予定日を尋ねるメールを1通ずつ送り、送った日を台帳に書く
• 製品ごとに、ログを見る担当者の名前と、ログの保存日数を台帳に書き、次に台帳を開く日を日付で入れる

06 代替・他の選択肢 — 提供元の更新を待つ間の、扱いを決める

台帳の欄を、先に決める

製品の台帳には、次の欄があると、後で困らない。欄は、筆者の整理である。1行が1製品で、同じ製品が2台あれば2行にする。台数を1行にまとめると、1台だけ更新が遅れたときに見えなくなる。

選択肢を、4つに分ける

影響がありうる製品の扱いは、4つに分けられる。出典に書かれた分類ではなく、筆者の整理である。

提供元に尋ねるメールの例

提供元の窓口に尋ねるときは、製品名・版・知りたいことを3行で書くと、返事が早い。一例を示す。

• 1行目: 「貴社の製品（製品名・版の番号）をご契約中です。」
• 2行目: 「PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）について、この製品の影響の有無を教えてください。」
• 3行目: 「影響がある場合は、更新の予定日と、それまでの暫定の手当てを教えてください。」

分かれ道を、図に書いておく

更新できない間の手当ては、提供元の案内に従う

サーバーのPHPなら、更新できない間の暫定の設定を、自分たちで入れられる。製品の中のPHPでは、設定の場所に手が届かないことが多い。そのため、暫定の手当ては、提供元が案内したものだけを行う。自分で製品の中の設定ファイルを書き換えると、保守の契約の範囲を外れて、サポートが受けられなくなる場合がある。契約の範囲は、契約書で確かめる。

自分たちで確実にできるのは、製品の外側の手当てである。管理画面へのアクセス元を絞る、外から閉じる、ログを残す設定になっているかを確かめるの3つが、その例である。どれも、製品の機能として用意されているかを、まず確かめる。

「調査中」を放っておかない

提供元が「調査中」と書いたまま、何日も更新しないことがある。筆者の読みでは、調査中は、安全の証明でも、危険の証明でもない。台帳に「調査中」と書いたなら、次に確認する日を同じ行に入れる。日付がない調査中は、見直されないまま残る。

侵害を疑うときに、原文が挙げた確認先

注意喚起の「侵害調査」の節は、PHPの脆弱性についての、確認先を挙げている。要旨は、異常な形のセッションのCookieの有無、不審なアップロード形式のリクエストとその前後のメモリ不足のエラーや内部エラー、PHPのワーカーの予期しない異常終了や再起動、不審なプロセスの実行や外部への通信、不審なファイルの作成である。痕跡が見つからなくても、侵害がないとは言い切れないとも書かれている。製品の場合、これらのログを自分で見られるかは、製品による。見られないなら、提供元にログの確認の方法を尋ねるのが先になる。当サイトがサーバーで、この確認先を件数で数えた記録は、記事PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法と、PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）に書いた。

07 当サイトで確かめたこと — この記事の台帳は、これから作る

サーバーのPHPの確かめは、別の記事に書いた

当サイトは、サーバーのPHPについて、修正が入ったかを値で確かめた記録を、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったとPHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったの2本に書いた。それと、サイトの公開の場所に残った控えファイルを外へ出した記録は、記事控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順に書いた。これらは、サーバーの中の話である。

サーバーの外の製品の台帳は、まだ作り終えていない

この記事の主題である、サーバーの外の製品の台帳は、この記事を書いた2026年10月30日の時点で、当サイトでは作り終えていない。そこで、この記事の13項目を、当サイトの運営の側でも、これから順に行う。結果は、行ったあとに、この記事の末尾へ日付つきで書き足す。数字や状態は、確かめるまで書かない。

サーバーの中身は、ここには書かない

サーバーの設定の中身や、版の番号、防御の設定は、この記事には書かない。公開すると、今まさに空いている穴の案内になりうるからである。書くのは、確かめる手順と、確かめた日付までに絞る。

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

この記事で扱った範囲

この記事が扱ったのは、2026年10月29日のJPCERT/CCの注意喚起の更新と、担当サイトのサーバーの外にあるPHP同梱の製品を、台帳に足して確かめる手順である。

この記事で扱っていないこと

• 侵害されたとされる個別の製品の名前（筆者が開いた範囲では確かめられなかった）
• 攻撃の手順や、攻撃に使われた技術の細部（守る側の確認に必要ないので書かない）
• どのLinuxカーネルの脆弱性が組み合わされたか（原文の表現を、筆者は確かめきれなかった）
• CVE-2026-115560の詳しい条件（記事PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）に任せた）

関連する、これまでの記事

期限の読み替えは、記事CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目（2026年10月時点）に、開発用のパソコンの同梱PHPは、記事PHPのWindows版は、版の番号が同じまま「-1」で作り直された ── 開発用のパソコンの同梱PHPを洗い出し、部品の版を確かめる13項目（2026年10月時点）に書いた。サイトの前に置いた部品の台帳は、記事SiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）と、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）にもつながる。

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

この記事の内容は、2026年10月30日に、JPCERT/CCの注意喚起、PHP公式サイトのニュース、NCSC-NLのページを開いて確かめた時点のものである。注意喚起は、今後も更新されうる。更新の内容を確かめたときは、日付つきで書き足す。