WEBサイト
2026年11月4日、圧縮の部品「Brotli」の解説記事を書いていた担当が、当サイトの毎朝の解析レポートを作る定時の処理が、保守の終わった系統の実行環境（Node.js）で動いていることに気づいた。その系統は、Brotliの脆弱性（CVE-2026-111497）の修正版が、今後も出ない側にある。Webサーバーの側ではなく、Webの外で毎朝、人の目に触れずに動いている処理の話だ。
この日のうちに、定時の処理の設定のうち、実行環境を指す1行だけを、パッケージ管理の仕組みで入れた方（Node.jsの開発元が修正版として挙げた系統）へ切り替えた。そして、11月5日と6日の2回の朝、処理が最後まで終わって、その日の報告を書き出していることを確かめた。この記事は、見つけた経緯、切り替えるときに何を決め手にしたか、2回の朝で何を見たかを書く。
読み終えたら、担当サイトで「Webとは別に動いている定時の処理は、どの実行環境で動いているか」を一覧にし、切り替えた翌朝に何を確かめればよいかが分かるようにしたい。安全のため、当サイトの実行環境の版の番号、置き場所、設定の書式、ファイルの名前は書かない。書くのは、日付、手順の順番、確かめた項目、提供元が公表している修正版の番号までだ。
何が見つかったか ── 3行で、そしてきっかけ
3行で言うと
- 毎朝の解析レポートを作る定時の処理が、保守の終わった系統のNode.jsで動いていた。その系統は、Brotliの修正版が出ない側にある。
- 11月4日に、定時の処理の設定の1行だけを、Node.jsの開発元が修正版として挙げた系統の方へ切り替えた。切り替える前に控えを取り、構文の確かめを通し、設定の行数が前後で同じことを見た。
- 修正版の実行環境でも、中に組み込まれたBrotliの「版の表示」は、切り替えた直後に見たとき、修正前と同じ文字を返した。だから、表示ではなく、設定が指す実行環境の版を修正版と比べて決めた。11月5日と6日の朝、処理は2回とも最後まで終わり、失敗の行は無かった。
きっかけは、別の記事を書いていたこと
見つけたのは、狙って探したからではなかった。解説記事Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目（2026年11月時点）を書いていた。この記事の主題は、Brotliが「実行環境の中」「別に入れた部品」「外から呼ぶ道具」の3つの層に入っている、ということだ。解説記事を書いていた担当が、1つ目の層（実行環境）を当サイトに当てはめて数えていたとき、Webサーバーの側ではなく、Webの外で動く定時の処理の実行環境が目に入った。
記事の13項目を、自分のサイトに当てはめる。同じ型の話を、すでに書いている。記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.***を、記事を公開したその日に上げるまででは、記事のチェック項目を書く途中で自分のサイトへ当てたら、自分のサーバーが対象だった。今回もそうだった。書き終えてから確かめるのではなく、書いている最中に当てる。そうすると、記事の中の「担当サイトで確かめること」が、自分の手で一度通った項目になる。
脆弱性の知らせは、Node.jsについて何と言っているか
Brotliの範囲外書き込みが、実行環境の中の部品にもあった
Node.jsの開発元は、2026年10月21日に、セキュリティ修正を含む更新を公開した。そのうちの1つが、CVE-2026-111497だ。開発元のページは、重大度を「high（高）」としている。内容は、Node.jsに同梱されたBrotliの展開部品（圧縮されたデータを元に戻す部分）で、不正な圧縮データを与えると、内部の領域の外へ書き込みが起きる、というものだ。開発元のページは、次のように書いている。
"An invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer."
（日本語訳: 不正なブロックの切り替えが、恒久的な形式エラーではなく「入力がもう少し必要」と報告されたため、流れ込みで展開する部品は、8バイトの内部の領域に、入力のバイトを追加し続けた。）
この脆弱性が悪用される場面は、アプリが、外から届いたBrotli圧縮のデータを展開する形になっているときだ。開発元のページは、Node.jsの標準の圧縮の機能で、攻撃者が用意したBrotliのデータを展開するアプリは、クラッシュ、処理中のメモリの漏えい、遠隔からのコード実行につながりうる、と説明している。自分のサイトが外から圧縮を受け取っているかどうかは、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だったで、元に戻す側に回る場所を数えた。
影響を受ける系統と、修正版の番号
開発元のページが、影響を受ける系統として挙げているのは、26系・24系・22系の3つだ。修正版として挙げられているのは、次の3つだった（ページの「ダウンロードとリリースの詳細」の欄）。
| 系統（括弧はリリースの頁の表示） | 修正版 | 公開日（各リリースの頁） |
|---|---|---|
| 26系（10月21日時点でCurrent） | 26.12.1 | 2026年10月21日 |
| 24系（10月21日時点でLTS） | 24.22.1 | 2026年10月21日 |
| 22系（10月21日時点でLTS） | 22.23.4 | 2026年10月21日 |
10月のセキュリティ更新のページは、この脆弱性ごとには修正版を対応づけていない。ただ、3つの版それぞれのリリースの頁（26.12.1・24.22.1・22.23.4）の「主な変更」の欄に、同じ1行がある。
"(CVE-2026-111497) deps: brotli: cherry-pick 0ed4268a4401abcb44720963 (Evgenii Kliuchnikov) – High"
（日本語訳: （CVE-2026-111497）依存部品: brotli: 修正の1件（0ed4268a4401abcb44720963）を取り込んだ。重大度は高。）
Node.jsの中に同梱されたBrotliへ、この修正の1件が取り込まれた、という記述だ。だから、この3つの版は、CVE-2026-111497の修正を含む版として読める。取り込んだのは修正の1件だけなので、部品の版の番号は、前と同じ文字のままでも、中身は直っている、と読める。これは、リリースの頁の記述からの読みで、当サイトで修正の有無を値で確かめたものではない。
保守が終わった系統は、いつも影響を受ける
表に載っていない系統は、どうなるのか。開発元のページは、はっきり書いている。
"It's important to note that End-of-Life versions are always affected when a security release occurs."
（日本語訳: 重要な点として、保守が終わった（End-of-Life）版は、セキュリティの更新が出るたびに、いつも影響を受ける。）
保守が終わった系統には、修正版は出ない。開発元のリリースの一覧には、保守が終わった系統（EOL）がいくつも並んでいる。奇数の番号の系統は、半年で保守が終わる、と一覧の注記にある（26系までの話として書かれている）。つまり、「少し前に入れた版」でも、系統ごと保守が終わっていることは、珍しくない。
「Webの外」で動く実行環境という盲点
Webの側だけを見ていると、定時の処理が抜ける
Brotliが怖いと聞くと、多くの人は、まずWebサーバーの側を確かめる。ブラウザからのアクセスを受け付ける側だ。それは正しい。ただ、サーバーの上では、Webの側のほかに、もう1つの動き方がある。毎朝・毎晩の決まった時刻に動く、定時の処理だ。レポートの作成、バックアップ、データの取り込み、外のAPIから情報を取ってくる処理、がその例になる。
定時の処理は、人が見ていない時間に動く。画面が無く、アクセスログにも出ない。動いていることは、結果のファイルが毎朝できていることでしか分からない。しかも、使っている実行環境は、Webの側とは別に入れたものであることが多い。Webの側を更新しても、定時の処理の実行環境は、そのまま残る。
実行環境が動いている場所を、誰が・どこで確かめるか
| 場所 | 動かすもの | 実行環境の版が分かる場所 | 気づきにくい理由 |
|---|---|---|---|
| Webの側 | Webサーバー、またはその裏のアプリ | サーバーの更新の記録、Web側の設定 | 更新の話題で必ず出る。確かめる人が多い |
| 定時の処理 | 決まった時刻に動くタスク（cronなど） | タスクの設定が指している実行環境そのもの | Webの更新に連れて動かない。画面が無く、結果のファイルしか手がかりが無い |
| 道具の中の組み込み | 別に入れたアプリや道具の中の実行環境 | その道具の提供元の案内 | サーバーの更新の一覧に出ない。道具の更新を待つしかない |
解説記事Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目（2026年11月時点）は、実行環境の中・別に入れた部品・外から呼ぶ道具の3つの層を台帳に書く13項目を挙げた。この記事は、その1つ目の層（実行環境）を、Webとは別に動く定時の処理に当てた記録になる。
当サイトでは、定時の処理が別の実行環境を指していた
当サイトでは、Webの側の更新は、サーバーの更新の記録に残る。一方、毎朝のレポートを作る定時の処理は、そこには出てこない。設定の1行が指している実行環境が、何なのかを見ない限り、分からない。見てみると、その行が指していたのは、手で入れた実行環境で、保守の終わった系統だった。手で入れたものは、サーバーの更新の記録の外にある。
保守の終わった系統は、今回に限らず、次の脆弱性が出たときも、修正版が出ない側に立つ。そのため、切り替えることにした。
版の表示は、修正の証拠にならなかった
修正版でも、組み込みの版の表示は同じ文字だった
切り替えた直後（11月4日）、念のため、実行環境が自分で名乗る「組み込まれたBrotliの版」を表示させてみた。Node.jsは、内部の部品の版を一覧にして返す機能を持っている。結果は、切り替える前の、保守の終わった系統の実行環境が返したものと、同じ文字だった。
これを見て、「修正が入っていない」と読むのは間違いだ。3つの版のリリースの頁は、修正を「cherry-pick（修正の1件だけを取り込む）」と書いている。部品ごと新しい番号へ入れ替えたのではなく、修正の1件だけを取り込んだ形だ。この形なら、部品の版の番号は前と同じ文字のままになりうる。表示された番号は、部品の元の番号を指していて、修正の有無を指していない。
PHPの件と同じ形だった
同じ形の話を、すでに書いている。PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったでは、PHPが名乗る版も、「作った日」の表示も、修正の前後で変わらなかった。修正が入ったかは、表示からは分からず、修正で増えた設定の有無という、値で確かめた。今回も、同じ言い方ができる。部品が名乗る版の表示は、修正の証拠にならない。
違うのは、今回は、修正で増えた設定のような、値で確かめる材料が見つからなかったことだ。その代わりに使えるものがある。それが、次の項で書く「実行環境の版を、提供元の修正版と比べる」やり方だ。
何を決め手にしたか ── 実行環境の版と、提供元の修正版
決め手にしたのは、2つだ。1つ目は、定時の処理の設定が指す実行環境の版が、提供元の修正版と同じか、それより新しいか。Node.jsの開発元が修正版として挙げた系統の、修正版以降であれば、修正を含む。2つ目は、その実行環境を、どこから入れたかだ。パッケージ管理の仕組みで入れたものは、更新の仕組みに乗る。手で入れたものは、自分で気づかない限り、更新されない。
この2つで比べた結果、切り替える前は、どちらも満たしていなかった。切り替えた後は、両方を満たした。なお、配る側が修正を取り込んだうえで、版の番号を変えずに配る場合は、この比べ方では判断が難しくなる。当サイトの実行環境は、開発元の番号と同じ数字で比べられる形のものだったので、この比べ方で足りた。
切り替えの手順 ── 行ったことと、勧める順
勧める順番と、その理由
切り替えるときに勧める順は、次のとおりだ。当サイトで行ったのは、2番（控えを取る）、4番（1行だけ書き換える）、5番（構文と行数を確かめる）、6番（翌朝の結果を見る）で、1番（一覧を作る）と3番（先に動くことを確かめる）は、この記事を書きながら、勧める順に加えたものだ。
- 定時の処理の設定を全部拾い、それぞれが指している実行環境の一覧を作る（勧める順）。
- 設定の控えを取る。控えは、公開の場所の外に置く（控えファイルを外から確かめた日で書いた、控えが積もる話を繰り返さないため）。
- 新しく指す実行環境が、確かに動くことを、設定を変える前に確かめる（勧める順）。
- 設定の1行だけを書き換える。ほかの行には触らない。
- 書き換えの後、設定の構文の確かめを通し、行数が前後で同じことを見る。
- 次の朝の結果を見る。
3番目の「設定を変える前に確かめる」を、独立の項目にして勧めるのは、先に設定を変えてしまうと、新しい実行環境が動かなかったとき、次の朝まで、レポートが作られない時間ができるからだ。先に動くことを確かめておけば、書き換えは1行で済み、うまくいかなければ1行を戻すだけで済む。
変えたのは、設定の1行だけだった
実際に変えたのは、定時の処理の設定のうち、実行環境を指す1行だけだ。ほかの定時の処理の行には、触っていない。変える前に控えを取り、変えた後に構文の確かめを通した。設定の行数は、前と同じだった。行が増えても減ってもいない、ということは、別の行を巻き込んでいない、という目安になる。
変更を小さくしておくことの利点は、戻し方が分かりやすいことと、「何を変えたか」を、後から言いやすいことだ。大きく直した設定は、うまくいったときも、うまくいかなかったときも、原因の見当がつきにくい。
手で入れた古い方は、消さなかった
手で入れた古い実行環境は、消していない。定時の処理の設定からは、もう使われていない。ほかの場所で使っているかどうかは、確かめていない。消さなかった理由は、2つある。1つ目は、ほかで使っていないことを確かめていないこと。2つ目は、消すと戻せないが、残しておくだけなら、戻せること。
ただ、残しておくことにも代償がある。古い実行環境が残っていると、誰かが「動くから」と気軽に使い始めることがある。片付けるかどうかを決める日を、先に置いておく必要がある。これは、この記事の🔧の1つにした。
2回の朝で確かめた
確かめたのは、2つだけ
切り替えた翌朝から、確かめたのは、次の2つだけだ。
- 定時の処理の設定が指す実行環境の版は、提供元の修正版以降か。
- 処理が、最後まで終わって、その日の報告を書き出したか。記録に、止まった・失敗した行が無いか。
1つ目は、切り替えが、期待どおりに効いているかの確かめだ。設定の1行を書き換えただけで、定時の処理が別の実行環境を読んでいるとは限らない。そこで、設定が指している実行環境の版を見る（処理の記録には、版の行は無い）。2つ目は、切り替えの副作用が無いかの確かめだ。実行環境が替わると、読み込む部品の細かい動きが変わり、今まで通っていた処理が止まることがある。
11月5日の朝と、11月6日の朝
11月5日の朝、処理は最後まで終わり、その日の報告を書き出した。記録に、止まった行・失敗した行は無かった。定時の処理の設定が指す実行環境の版は、提供元の修正版以降だった。
11月6日の朝も、同じ結果だった。2回続けて確かめたのは、1回だけだと、たまたま通った可能性が残るからだ。定時の処理には、日によって通ったり通らなかったりする部分がある（外のAPIの一時的な不調など）。2回続けて通れば、少なくとも、切り替えたことで毎回止まる、という状態ではない、とは言える。
| 確かめる項目 | 切り替える前 | 11月5日の朝 | 11月6日の朝 | 何が分かるか |
|---|---|---|---|---|
| 1. 定時の処理の設定が指す実行環境の版は、提供元の修正版以降か | いいえ（保守の終わった系統） | はい | はい | 切り替えが、実際に効いていること |
| 2. 処理が最後まで終わり、その日の報告を書き出したか。記録に、止まった・失敗した行が無いか | （比べていない） | 終わった・失敗の行なし | 終わった・失敗の行なし | 切り替えで、止まっていないこと |
| （参考）組み込みの部品の版の表示 | ある文字 | （見ていない） | （見ていない） | 切り替えた直後の11月4日に、前と同じ文字だった。表示は、修正の証拠にならない |
参考の行が、この記事のいちばん大事な行だ。表示が変わらないのに、実行環境は替わっている。表示だけを見ていたら、「切り替えても何も変わらなかった」と読んでしまう。
解説記事に、日付つきで書き足した
この結果は、解説記事Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目（2026年11月時点）の最後の章に、「2026年11月6日 追記 ── 翌朝の確かめは、2つとも通った」として書き足した。記事に書いた13項目を、解説記事を書いていた担当の側で通した記録を、同じ記事の中に残す形だ。読者が、項目を読んで、「これは本当に通るものなのか」と思ったときに、通した記録が隣にある。
切り替えで迷った3つの点
「動いているのだから、そのままでいい」という気持ち
最初に浮かんだのは、このまま触らない方が安全ではないか、という考えだった。毎朝、報告は問題なくできている。実行環境を替えて、かえって止まったら、元も子もない。この気持ちは、自然だと思う。定時の処理は、止まるまで、誰も見ない。見ないものを触るのは、気が重い。
それでも切り替えたのは、「動いている」ことと「保守されている」ことが、別だからだ。動いていることは、今朝の結果が教えてくれる。保守されていることは、提供元の一覧を見ないと分からない。動いているあいだは、問題が見えない。問題が見えたときには、次の更新に間に合っていない。
戻し方を先に決めておく
迷いを減らしてくれたのは、戻し方が1行で済むことだった。設定の控えがあり、変えたのは実行環境を指す1行だけで、古い実行環境は残してある。うまくいかなければ、控えの1行に戻せば、元の動きに戻る。戻せるから、試せる。戻せないものを、気軽に切り替えるのは危ない。
戻す条件も、先に決めておくとよい。「翌朝、報告が書き出されていなければ戻す」のように、正常の定義で書く。「エラーが出たら戻す」と書くと、エラーの形に出ない失敗（報告が空のまま終わる、など）が、条件の外に落ちる。
切り替えを遅らせた場合に、何が起きるか
もし、確かめる手間を理由に、切り替えを先送りしたら、どうなっていたか。今回の脆弱性は、条件を満たさなければ悪用されない。だから、すぐには何も起きないかもしれない。起きないあいだは、先送りの代償は見えない。代償が出るのは、次の脆弱性が出て、修正版が出ない系統の側にいることに気づいたときだ。そのとき、慌てて切り替えると、確かめる時間が足りず、失敗の見分けもつきにくい。
落ち着いている時期に、1行だけ、戻せる形で切り替えておく。切り替えを小さくしておくと、次の脆弱性の知らせが来たとき、「また同じ手順でやればよい」と考えられる。
担当サイトで確かめること ── 10項目のチェックリスト
自分で確かめる10項目
担当サイトで、明日から確かめられる10項目を挙げる。設定を読むのが難しければ、制作会社やサーバーの担当に頼んでよい。
- サーバーの上で、決まった時刻に動く処理（cronなどのタスク）が、何本あるかを一覧にしてもらう。
- それぞれが、どの実行環境（Node.js、PHP、Pythonなど）を使っているかを、設定が指している先まで書いてもらう。Webの層とは別に数える。
- 実行環境の版を、提供元が公表している修正版と比べる。系統ごと保守が終わっていないかも、提供元の一覧で見る。
- 手で入れた実行環境と、パッケージ管理の仕組みで入れた実行環境を分けて書く。前者は、自分で気づかない限り、更新されない。
- 修正版に切り替えると決めたら、変える前に、設定の控えを、公開の外に取る。
- 新しい実行環境が動くことを、設定を変える前に確かめる。
- 設定は、実行環境を指す行だけを変える。変えた後に、構文の確かめを通し、行数が前後で同じことを見る。
- 切り替えの翌朝に、設定が指す実行環境の版が修正版以降か、処理が最後まで終わったか、の2つを確かめる。
- 2回続けて確かめる。1回だけでは、たまたま通ったのか、直ったのか分からない。
- 古い実行環境を片付けるかどうかを決める日を、先に置く。残すなら、誰がいつ見直すかを書く。
制作会社・サーバーの担当への聞き方と、使える無料ツール
担当サイトを制作会社や運用会社に任せている場合は、次のように聞くと、状況が分かる。
- 「サーバーの上で、決まった時刻に動いている処理は、何本ありますか。それぞれ、何の実行環境で動いていますか」
- 「その実行環境は、提供元の修正版が出る系統ですか。手で入れたものですか、パッケージ管理の仕組みで入れたものですか」
- 「切り替えるとき、前と後で、何を見て確かめますか」
答えが「確かめたことはない」でも、責める話ではない。定時の処理は、画面が無く、結果のファイルしか手がかりが無い。誰かが悪いのではなく、確かめる仕組みが無かっただけのことが多い。確かめる日を決めるきっかけになる。
外から見える範囲を点検したいときは、🔧 外からできるセキュリティ対策監査ツール（会員登録が必要）が入口になる。ただし、これは外から見えるものしか確かめられない。定時の処理は、外から見えない層なので、このツールの対象の外になる。切り替えの前後で画面を比べるなら、🔧 WEBサイトの状況チェック・比較ツール（チガウン）（会員登録が必要）が使える。ページの中身を、前と後で並べて見られる。画面を日付つきで残すなら、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールがある。
実行環境と並べて、別に入れた部品も数える方法は、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）に書いてある。Webの層の外にも広げて数えるときの、入口になる。
一覧に書く列の例と、月に1回の見直し方
定時の処理の一覧は、凝った表でなくてよい。次の6つの列があれば、見直しに足りる。
- 処理の名前と、何をする処理か（レポートの作成、バックアップ、データの取り込み、など）
- 動く時刻の目安（毎朝、毎晩、毎週、など。書式そのものは書かなくてよい）
- 使っている実行環境の種類（Node.js、PHP、Pythonなど）
- 入れ方（パッケージ管理の仕組みか、手で入れたものか）
- 提供元の修正版との関係（修正版以降か、系統ごと保守が終わっているか）
- 最後に確かめた日と、確かめた人
月に1回の見直しは、この表の「提供元の修正版との関係」の列だけを、提供元の一覧と並べ直す作業になる。新しい脆弱性の知らせが出た週は、月1回を待たずに、その週のうちに並べ直す。表があれば、並べ直しは数分で終わる。表が無いと、毎回「何がどこで動いているか」を探すところから始まる。探すことに時間を取られて、確かめるところまで行き着かない。表の価値は、確かめる作業の入口を、毎回同じにすることにある。
当サイトの現在地 ── 実施したことと、これから
この記事で書いたことについて、当サイトの現在地を、正直に書く。
✅ 当サイト実施済 毎朝の解析レポートを作る定時の処理が、保守の終わった系統の実行環境で動いていることを見つけた（11月4日）。同じ日に、設定の実行環境を指す1行だけを、提供元が修正版として挙げた系統の方へ切り替えた。変える前に控えを取り、構文の確かめを通し、設定の行数が前後で同じことを見た。
✅ 当サイト実施済 切り替えた直後に、組み込みの部品の版の表示が、前と同じ文字を返すことを確かめた。表示は修正の証拠にならないと分かったので、判定を、設定が指す実行環境の版を修正版と比べる形に決めた。
✅ 当サイト実施済 11月5日と6日の朝、処理が最後まで終わり、その日の報告を書き出したこと、記録に止まった行・失敗した行が無いこと、定時の処理の設定が指す実行環境の版が提供元の修正版以降だったことを、2回続けて確かめた。結果を、解説記事の最後の章に、日付つきで書き足した。
🔧 当サイトこれから 定時の処理ごとに、使っている実行環境を一覧にして、月に1回、提供元の修正版と比べる。今回は1本の処理で見つけたが、ほかの定時の処理が何を指しているかは、一覧にして初めて分かる。一覧を作ったら、誰がいつ見るかも、先に決める。
🔧 当サイトこれから 手で入れた古い実行環境を片付けるかどうかを決める。使っている場所が、ほかに無いことを確かめてから、消すか、残すか、残すなら見直す日はいつかを決める。決める日が来ても、決まらないまま残るのが、いちばんまずい形だ。
まとめ
持ち帰ってほしいことは、5つだ。
- Webの層を更新しても、決まった時刻に動く処理の実行環境は替わらない。Webとは別に数える。
- Node.jsの開発元は、Brotliの範囲外書き込みの修正版として、26.12.1・24.22.1・22.23.4を2026年10月21日に公開した。保守が終わった系統は、いつも影響を受ける側にある。
- 修正版に切り替えても、組み込まれた部品の版の表示は、前と同じ文字のことがある。表示は、修正の証拠にならない。実行環境の版を、提供元の修正版と比べる。
- 切り替えるときは、一覧を作る、控えを取る、先に動くことを確かめる、1行だけ変える、構文と行数を確かめる、の順に進める。
- 切り替えた翌朝に、設定が指す実行環境の版と、処理が最後まで終わったか、の2つを確かめる。2回続けて通れば、少なくとも、切り替えで毎回止まる状態ではない、と言える。
確かめていないことも書いておく。1つ目は、定時の処理のほかに、サーバーの上で動いている、別の実行環境が無いかだ。いまの一覧は、見つけた範囲の数にすぎない。2つ目は、手で入れた古い実行環境を、将来消したときの影響だ。3つ目は、組み込みの部品の修正が、実際に入っているかを、値で確かめる方法を、当サイトでは見つけられていないことだ。この記事の判定は、リリースの頁に修正が載っていることと、実行環境の版の比較に頼っている。4つ目は、開発元が今後出す更新で、版が変わったときは、同じ比べ方でもう一度確かめる。
関連 archives（連載軸として読む）
- 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方 ── 同じ脆弱性を、元に戻す側から数えた記事。今回は、その実行環境の側の続き（10月28日）
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録 ── 版の表示は修正の証拠にならないという話。今回は、Node.jsで同じ形を見た（10月26日）
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.***を、記事を公開したその日に上げるまで ── 記事のチェック項目を、書く途中で自分のサイトへ当てた記録
- Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録 ── 自分のサーバーの中を数えて、その日のうちに直した記録（10月30日）
- 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 ── 設定の控えを公開の外に置く理由の元になった記事（10月23日）
解説記事では、Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目（2026年11月時点）（この記事の発端になった、実行環境の版を台帳に書く13項目）のほか、Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目（2026年10月時点）、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）もあわせて読める。
出典
すべて2026年11月6日に開いた。Node.jsの10月のセキュリティ更新のページは、最終更新が2026年10月21日だった。リリースの一覧のページは、サーバーから更新日を得られなかった。
