Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目(2026年11月時点)
Brotliは、言語の実行環境の中にも、別に入れた部品にも入っている。カナダの告知が挙げた例を3つの層に分け ── 実行環境の版を提供元の修正版と比べて台帳に書く13項目(2026年11月時点)
目次
01 何が書いてあるか — カナダ政府の告知は、Brotliを組み込んだ製品を「例」として並べ、「ほかにもある」と書いた
引用について
この記事は、2026年11月4日に開いて読んだ次のページの内容を書いている。カナダのサイバーセキュリティセンターの告知AL26-027、アメリカのCISAが公開している悪用が確認された脆弱性のカタログ(JSONの形)、GoogleのBrotliのリリース一覧、Node.jsの2026年10月のセキュリティリリース、PyPIのBrotliのページ、それにnpmとpipの公式の文書である。英文は一字ずつ引き写さず、記事の筆者が日本語に直した要旨で書く。出典に書かれていない筆者の読みと案は、「筆者の読み」「筆者の案」と書いて分ける。なお、PyPIのページとNode.jsの文書は非常に長く、先頭の部分だけを読んだ。
2026年10月28日付けで、カナダのサイバーセキュリティセンターが、Brotliの脆弱性(CVE-2026-111497)の告知を出した。Brotliは、データを小さくするための圧縮の方式で、この脆弱性は、圧縮されたデータを元に戻す部分(デコーダー)で、決められた範囲の外にデータを書き込めてしまうものである。告知は、認証なしで遠隔から悪用でき、メモリの破壊や情報の漏れ、処理の停止、任意のコードの実行につながりうると書いた。Brotliそのものの話は、当サイトの別の記事「Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目(2026年10月時点)」にまとめてある。この記事が扱うのは、その告知の製品の一覧を読んだときに出てくる、別の問いである。自分の担当サイトでは、Brotliは、どの部品の、どの場所に入っているのか。
告知が挙げた「組み込んだ製品」
告知は、Brotliを組み込んでいる製品として、Node.js、Microsoft .NET、PowerShell、Bun、Envoy Proxy、Istio、それにPythonのBrotliとbrotlicffiという2つのパッケージを挙げている。告知は、この一覧に挙がっていない技術も含まれる、と書いている。つまり一覧は例であって、網羅ではない。個別の製品の修正版の番号は、この告知には載っていない。告知は、適切な修正版への更新を求めている。製品ごとの修正版は、各提供元の情報で確かめることになる、と読める。
影響を受けるBrotliの版
告知の表によれば、影響を受けるのは、1.0.3以上で1.0.10より前、1.1.0以上で1.1.1より前、1.2.0以上で1.2.1より前のBrotliである。修正版は、それぞれ1.0.10、1.1.1、1.2.1の3つで、3つとも別々の系列に出ている。Googleのリリース一覧にも、この3つの版が並んでいて、どれも欄に同じCVEの番号が載っていた。日付は、一覧に「21 Oct」とだけ出ていて、年は表示されていなかった。
CISAのカタログに載った行
CISAのカタログのデータを読むと、この番号の行は、追加日が2026年10月27日、対応の期限の欄が2026年11月10日、弱点の種類がCWE-252(戻り値を確かめない)とCWE-787(範囲外への書き込み)だった。「ランサムウェアの攻撃に使われたか」の欄は「Unknown」、侵害の調査(フォレンジック)を求める欄は「No」だった。同じ行の備考欄には、こう書かれている。
"This vulnerability affects an open-source component, third-party library, protocol, or proprietary implementation that could be used by different products."(訳: この脆弱性は、オープンソースの部品、第三者のライブラリ、プロトコル、または独自の実装に当たり、さまざまな製品で使われうる。)
この1文が、この記事の出発点である。さまざまな製品で使われうる部品だから、「うちはBrotliを入れた覚えがない」だけでは、当てはまらないとは言えない。
02 なぜ・背景 — 同じ部品が、3つの置き方で入っていて、更新する人が違う
1つ目の置き方: 言語の実行環境の中に同梱されている
Node.jsの告知は、この脆弱性を「Node.jsに同梱されたBrotliのデコーダー」の欠陥として書いた。深刻度はHigh(高)で、影響を受ける系統は26.x、24.x、22.xである。同じ日付の2026年10月21日に、3つの系統でセキュリティリリース(26.12.1、24.22.1、22.23.4)が出ている。ただし告知のページは、どのリリースがどのCVEを直したかを、CVEごとには対応づけていない。同梱されたBrotliは、Node.jsを入れた人が、別に入れたものではない。実行環境を更新しない限り、中のBrotliは更新されない、と筆者は読んでいる。
2つ目の置き方: 自分たちが別に入れた部品
PythonのBrotliのパッケージは、PyPIのページによれば「Brotli圧縮ライブラリのPython向けの接続部品」で、最新版は1.2.1、公開は2026年10月22日と表示されていた。このページは、Googleのソースを中に持っているのか、外にある部品を使うのかを、読んだ範囲では書いていなかった。つまり、パッケージの版が修正版でも、その中身がどうなっているかは、このページだけでは分からない。ここは、確かめていない点として残す。
3つ目の置き方: 外から呼んでいる道具や製品
告知が挙げたEnvoy ProxyやIstioのような、通信の途中に入る製品は、自分でプログラムを書かなくても、圧縮されたデータを受け取って解く場所になりうる。PowerShellや.NETも、同じ種類の「実行環境」や「道具」である。この層は、担当サイトの運営者が直接触れないことが多く、更新の持ち主は製品の提供元か、サーバーを管理している事業者になる、というのが筆者の読みである。
Node.jsの版の番号と、Brotliの版の番号は別のもの
ここで間違えやすいのが、2つの版の番号である。Node.jsの22.23.4という番号は、Node.jsの版である。Brotliの版は、1.2.1のような別の番号だ。告知は、Node.jsの3つの系統の版の番号を挙げたが、その中に入っているBrotliの版の番号は書いていない。修正が入ったかどうかは、実行環境の版を、提供元が修正版として挙げた版と比べて判断する。中に組み込まれたBrotliの番号の表示は、台帳に記録はしても、修正の有無の証拠にはしない。理由は04章の手順2に書いた。
告知に名前の無い系統は、告知から修正の有無が読めない
Node.jsの告知は、26.x、24.x、22.xの3つを挙げた。この3つ以外の系統を使っている場合、告知のページからは、修正が入っているかどうかが読み取れない。その場合は、Node.jsの提供元か、実行環境を入れた事業者に尋ねる。これも筆者の読みで、告知に書いてあることではない。
03 用語 — 出てくる言葉を、先にそろえる
用語
同梱(どうこん)は、ある製品の中に、別の部品が最初から入っていることである。同梱された部品は、製品を更新したときに一緒に入れ替わる。部品だけを別に更新する、という手が使えないことが多い。
用語
依存関係は、あるプログラムが動くために必要な、ほかの部品のつながりである。自分が入れた部品が、さらに別の部品を必要とすることがあり、その「孫」の部品を間接的な依存と呼ぶ。npmの文書は、一覧のコマンドが、依存の道筋を木の形で出すと書いている。
用語
バインディングは、ある言語から、別の言語で書かれた部品を呼ぶための橋渡しの部分である。PythonのBrotliのパッケージは、PyPIのページに「Python向けの接続部品」と書かれていて、橋渡しの役目だと読める。橋渡しだけで本体は外にある場合と、本体も中に持つ場合がある。
台帳とは、この記事では「部品の一覧表」のこと
この記事で台帳と書くのは、担当サイトごとに、どの層に何が入っているかを書いた表のことである。新しい仕組みや道具を入れる話ではない。表計算の1枚で足りる。当サイトの別の記事「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目(2026年10月時点)」では、PHPについて同じ形の表を作った。Brotliの場合は、列の中身が変わる。
04 型別 — 適用範囲、告知が書いていないこと、3つの層の読み方
🅰 適用範囲 — この記事の手順が関係する人
| 層 | 入っている場所 | 更新する人 | 版を読む手がかり |
|---|---|---|---|
| 実行環境の中 | Node.jsなどの同梱 | 実行環境の提供元 | 実行環境の版を読み、提供元が修正版として挙げた版と比べる |
| 別に入れた部品 | PythonのBrotli、npmのパッケージなど | 入れた人 | パッケージの一覧を出すコマンド |
| 外から呼ぶ道具や製品 | 通信の途中に入る製品、運用の道具など | 製品の提供元や事業者 | 提供元の告知と、事業者への質問 |
担当サイトが、静的なHTMLだけで、サーバーの中のプログラムを一切持たない場合は、1〜2層目は空になる。ただし、サイトを作る道具(ビルドの道具)や、納品後の確認に使う道具が、3層目に入っていることがある。
🅱 告知が書いていないこと
次の点は、読んだ範囲の告知やリリース一覧には書かれていなかった。書かれていないことは、推測で埋めない。
- 挙げられた製品それぞれの修正版の番号(告知は「各提供元で確認」という扱いに読める)
- 挙がっていない製品のうち、どれが同じ部品を持っているか(「ほかにも含まれる」とだけ書かれている)
- 攻撃の件数や、実際の被害の規模
- PythonのBrotliのパッケージが、Googleのソースを中に持つかどうか(PyPIのページの先頭部分には、記載が見つからなかった)
- npmの一覧のコマンドが、見つからなかったときに返す終了コード(読んだ文書に記載が無かった)
🅲 手順1 — 担当サイトを、層ごとに分けて書き出す
最初に、担当サイトごとに、1行ずつ書く。列は、サイトの名前、プログラムの言語(PHP・Python・Node.jsなど)、サイトを作る道具の有無、通信の途中に入る製品の有無、管理している人の5つで足りる。分からない欄は、「不明」と書いて、誰に聞くかを横に書く。「不明」を空欄にしない。
🅲 手順2 — 層1: 実行環境の版を読み、提供元の修正版と比べる
Node.jsを使っているサイトは、まず実行環境の版を読む。次に、Node.jsの提供元が修正版として挙げた版(26.12.1、24.22.1、22.23.4。2026年10月21日の告知で確かめた)と比べる。同じ系統で、その版以降なら、修正が入った実行環境と読める。台帳には、実行環境の版を書く。あわせて、中に組み込まれたBrotliの番号の表示も、記録として読んでおく。筆者が自分の環境で試した形は、次のとおりである。
node -p "process.versions.node"
node -p "process.versions.brotli"
1行目はNode.jsの版、2行目は組み込まれたBrotliの番号の表示が出る。2行目は、筆者が実行したところ文字列が返ったが、公式の文書で該当の節を読めていないので、この書き方が公式に保証されているかは、確かめていない。そして、この表示は、修正の有無の判定には使わない。筆者が修正版として告知が挙げた版のNode.jsで確かめたところ、組み込まれたBrotliの番号の表示が、修正前の系統と同じ番号のままだった。実行環境の提供元が、番号を変えずに修正を当てていることがある、というのが筆者の読みである。したがって、告知の表の番号と比べて「範囲に入る・入らない」を決めることはしない。表示された番号は、台帳に「表示」として書き、修正の有無は、実行環境の版で決める。
注意
実行環境が複数入っていることがある。同じサーバーに、OSの付属のものと、あとから入れたものが並んでいる場合は、実際に動かしている1つを使って読む。コマンドの場所を示す「command -v node」で、どの1つを使っているかを控えてから、版を読む。
🅲 手順3 — 層2: Pythonの一覧を出す
pipの文書によれば、pip listは入っているパッケージを大文字小文字を区別しない並びで出し、出力の形を列・freeze・JSONから選べる。pip showは、1つのパッケージの名前や版、置き場所、必要とする別のパッケージを出す。Brotliを探すときは、次のようにする。
python3 -m pip list --format=json
python3 -m pip show brotli
python3 -c "import brotli"
3行目は、実際に読み込めるかを試す。読み込めない場合、「入っていない」と読める。名前は、告知が挙げたbrotliとbrotlicffiの2つを、両方試す。仮想環境を使っているサイトは、その環境の中のpythonで同じことを行う。
🅲 手順4 — 層2: npmの依存を、木の形で出す
npmの文書によれば、npm lsは入っているパッケージを木の形で出し、パッケージの名前を引数に渡すと、その名前までの道筋だけに絞れる。既定では、直接の依存だけが出て、--allを付けると、間接的な依存まで出る。npm explainは、あるパッケージが入っている理由を、依存の鎖として出す。たとえば、次のように使う。
npm ls brotli --all
npm explain brotli
名前を「brotli」にしているが、Brotliを使う部品は、別の名前のことがある。1回の検索で何も出なくても、「入っていない」と決めない。出た場合は、鎖のどこに自分が入れた部品があるかを台帳に書く。
🅲 手順5 — 層3: 提供元と事業者に、決まった形で聞く
通信の途中に入る製品や、サイトを作る道具は、自分では版を読めないことが多い。その場合は、提供元の告知のページを探し、見つからなければ、事業者に聞く。聞く内容は3つで足りる。「CVE-2026-111497に当たる部品を含むか」「含むなら修正版の番号は何か」「いつ入れるか」。返事は、台帳の横の欄に、日付つきで書く。
🅲 手順6 — 台帳に、版と日付を書く
台帳には、実行環境の版と、読んだ日付を並べて書く。日付を書かないと、次の告知が出たときに、その番号が今のものか分からなくなる。Brotliの修正版の番号(1.0.10・1.1.1・1.2.1)は、Brotliを自分で入れた部品の層(Pythonのパッケージなど)の判断に使う。実行環境に組み込まれたBrotliの番号は、「表示」の欄に書くだけにする。
05 明日、担当サイトで確認できることチェックリスト
以下は、Brotliを組み込んだ部品を台帳に書き出す13項目である。1〜3番目は台帳の準備、4〜8番目は実行環境とPythonの確認、9〜10番目はnpmの確認、11〜12番目は提供元への質問、13番目は習慣である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- 担当サイトを3つ選び、言語・サイトを作る道具・通信の途中に入る製品の有無を、台帳の1行ずつに書く
- 台帳に、層1・層2・層3の列を作り、分からない欄に「不明」と、聞く相手の名前を書く
- Node.jsの提供元が挙げた修正版(26.12.1・24.22.1・22.23.4)と、Brotliの修正版(1.0.10・1.1.1・1.2.1)を、台帳の見出しの横に書き写す
- Node.jsを使うサーバーで、「command -v node」を実行し、使っている実行環境の場所を台帳に書く
- 同じサーバーで、Node.jsの版を読むコマンドを実行し、提供元の修正版と比べた結果を、日付つきで台帳に書く
- 組み込まれたBrotliの番号の表示を1回読んで、「表示」の欄に書く(修正の有無の判定には使わない)
- Pythonを使うサーバーで、pip listを実行し、brotliとbrotlicffiの2つの名前を探して、有無を台帳に書く
- Pythonで「import brotli」を試し、読み込めたか読み込めなかったかを、台帳に書く
- npmを使うサイトの置き場で、「npm ls brotli --all」を実行し、出た行数を台帳に書く
- 出た行がある場合は、「npm explain」で入っている理由を1つ読み、自分が入れた部品の名前を台帳に書く
- サイトを作る道具を1つ選び、提供元の告知のページを探して、URLを台帳に書く
- 管理を任せている事業者に、CVE-2026-111497に当たる部品を含むかと修正版の番号を聞く文を、3行で書いて送る
- 台帳を保存したファイルの名前に、書いた日付を入れ、次に見直す日を台帳の隅に書く
06 代替・他の選択肢 — 台帳の作り方と、更新できない間の手当て
台帳を作る3つの方法
| 方法 | 特徴 | 気をつけること |
|---|---|---|
| 手で書く | 表計算の1枚で始められる | 書いた日付が古くなる |
| コマンドの出力を保存する | 日付つきの記録が溜まる | 出力にサイトの内部の情報が混ざる。保存先の扱いを決める |
| 提供元や事業者の回答をもらう | 自分で読めない層にも届く | 返事が来ないまま止まる。催促の日を台帳に書く |
今すぐ更新できないとき、告知が書いた手当て
告知は、すぐに更新できない場合の手当てとして、影響を受けるアプリケーションが、信頼できない相手のBrotli圧縮の内容を処理しないようにすることを書いている。あわせて、影響を受ける製品が、予期しない停止や異常な動きをしていないか、監視するようにも書いている。外のサイトから受け取る応答を自動で展開する設定があるかどうかは、当サイトの別の記事「Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目(2026年10月時点)」で、数え方を書いた。
道具で外から見られる範囲
当サイトの🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — URLを与えて外から取れる情報をまとめる(会員限定)は、ページの説明によれば、CMS・フレームワーク・CDN・WAFの検出や、DNSの調査などを行う。🔒会員登録(無料)が要る。ただし、サーバーの中のBrotliの版は、外からは見えない。🔧 【SEO/UX】WEBサイト総合分析・レポートツール — SEO・セキュリティヘッダーなどをまとめて診断するも、同じで、見えるのは外から見える範囲である。どちらも、この記事の台帳の代わりにはならない。台帳の1層目と2層目は、サーバーの中で読む。
実務のヒント
台帳の「更新する人」の欄は、空欄にしない。サイトの運営者は自分だと思っていて、事業者は運営者だと思っている、という状態が、更新を止める原因になる。聞いた日と、返事の日を、両方書く。
ビルドの道具の更新台帳と、重ねて持つ
サイトを作る道具の更新の台帳は、当サイトの別の記事「GitLabの脆弱性が10月29日にCISAの悪用確認リストへ載り、期限の欄は11月1日だった。対象は自前で動かす側で、GitLab.comは修正済みと提供元が書く ── サイトを作る道具の更新台帳を作って確認する13項目(2026年10月時点)」で作り方を書いた。Brotliの台帳は、その表に1列足すだけで足りる。表を2つに増やすと、片方が古くなる。
07 当サイトで確かめたこと — 毎日の処理の実行環境を、提供元の修正版へ切り替えた
2026年11月4日、当サイトの毎日の処理の実行環境を、提供元のパッケージで入れた修正版へ切り替えた。結果は翌朝に確かめる。確かめたら、日付つきでこの章に書き足す。サイトの内部の構成は、安全のため書かない。書くのは、確かめる項目までである。
翌朝に確かめること
翌朝に確かめるのは、2つである。実行環境の版が、提供元が修正版として挙げた版以降になっているか。毎日の処理が、止まらずに最後まで終わったか。どちらも、この記事の05章の台帳の書き方で、日付つきで残す。
前の記事の確かめ方と、そろえる
外へつなぐ通信の先を一覧にする考え方は、記事「認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録」に書いた。PHPの2件の脆弱性で、版の番号が修正の証拠にならなかった話は、記事「PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ(CVE-2026-115560)を当サイトで確かめた記録」にある。Brotliでも、実行環境の版を提供元の修正版と比べ、日付を添えるという同じ形で確かめる。
08 このテーマは、ここまで — Brotliの記事の流れ
これまでの記事
- 脆弱性の中身と、「解く側」を数える方法は、「Brotliのデコーダーの脆弱性がCISAの悪用確認リストに載った ── 担当サイトで「圧縮を受け取って解く側」になっている所を数える13項目(2026年10月時点)」で書いた。
- 当サイトのサーバーで確かめた記録は、「圧縮の部品(Brotli)の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方」にある。
- PHPのWindows版が、版の番号のまま作り直された話は、「PHPのWindows版は、版の番号が同じまま「-1」で作り直された ── 開発用のパソコンの同梱PHPを洗い出し、部品の版を確かめる13項目(2026年10月時点)」で書いた。
- サイトを作る道具の更新台帳は、「GitLabの脆弱性が10月29日にCISAの悪用確認リストへ載り、期限の欄は11月1日だった。対象は自前で動かす側で、GitLab.comは修正済みと提供元が書く ── サイトを作る道具の更新台帳を作って確認する13項目(2026年10月時点)」で書いた。
- PHPを組み込んだ製品を台帳に足す話は、「JPCERT/CCはPHPの注意喚起を10月29日に更新し、ファイアウォール製品の特定の版で侵害の成功を示唆する痕跡が報告されたと追記した ── サーバーの外にあるPHP同梱の製品を台帳に足して確かめる13項目(2026年10月時点)」で書いた。
今回の記事の位置
これまでの記事は、脆弱性そのものと、自分のプログラムが圧縮を解く場所を扱っていた。今回は、Brotliが入っている部品の層を、台帳に書き出す手順を扱った。告知の一覧が「例」であることを踏まえると、次に起きる同種の告知でも、同じ台帳の使い方ができる。
2026年11月4日 — この記事の確認日
CISAの対応の期限は、2026年11月10日である。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む。この期限の読み方は、当サイトの別の記事「CISAの悪用確認リストにPHPの2件が載り、期限の欄は10月29日だった。拘束されるのは米国の連邦機関で、一般のサイトは優先順位の目安として読む ── 担当サイトの更新期限に読み替える13項目(2026年10月時点)」にまとめてある。台帳を作る日と、提供元への質問を送る日は、この期限より前に置くと、読み替えやすい。
現在の貴方のIPアドレス
このサイトで書いている人
WEBサイト