>
>
公開日
brotli 脆弱性を調べる情シス担当者向けに、HTTP2Shellの概要とNode.js以外の影響確認を解説します。Python、curl、Webサーバー、ブラウザ、Electron、OSパッケージ、クラウド/CDNを対象に、公式情報の読み方、暫定対応、SBOMによる棚卸し、OS更新を完了条件にできるかの判断方法を紹介します。
Brotliの脆弱性とは
この記事で確認したこと（確認日: 2026年11月09日）：CVE-2026-111497に関するGoogleのリリース、JPCERT/CCの注意喚起、NVD、JVN、CISA、GitHub Advisory、各提供元の公開情報をもとに、Brotliのデコーダー利用状況、製品ごとの提供元情報、OS更新を完了条件にできる範囲、SBOMと実行環境を使った棚卸しの進め方を整理します。
CVE-2026-111497は、BrotliのC言語実装にある境界外書き込みの脆弱性です。Googleは2026年10月21日に修正版を公開しました。影響を受けるのはBrotli 1.0.3〜1.2.0で、修正版は系列ごとに1.0.10、1.1.1、1.2.1です。Brotliの利用、脆弱な実装の組み込み、実際の影響を分けて判断します。
本記事のポイント
製品名だけでは影響を確定できません。
OS更新を完了条件にするかは、OSパッケージの対象条件と配布物・実行環境の記録を分けて照合して決めます。
修正状況は提供元の公式情報と照合します。Brotli本体の提供元であるGoogleは緩和策を示していません。
Node.jsの個別手順は既存記事で扱います。
「brotli 脆弱性」を調べている法人の情報システム部門（情シス）の担当者・管理者にとって、初動は管理対象の切り分けです。Pythonなどの実行環境を管理する担当者は、導入したパッケージ、配布物、実行中のプロセスを調査対象にします。一方、クラウド/CDNの契約管理担当者は、提供元の影響案内と自社の利用サービスとの対応関係を整理します。HTTP2Shellという名称だけで、両者に同じ更新作業が必要だと判断しないようにします。
JVNは、BrotliのC言語実装における本件を、HTTP2Shell、Node2Shellとも呼ばれる脆弱性として案内しています。JPCERT/CCは、影響を受ける製品にNode.js、Bun、Python向けBrotliパッケージなどが含まれるとしています。名称にNodeが含まれていても、調査対象をNode.jsだけに限定しません。
影響判断では、利用しているという事実と、影響を受けるという結論は別です。管理対象に該当実装が含まれると分かれば、提供元の対象条件との照合に進みます。組み込み状況が分からない対象は、調査中として管理します。
Node.jsは22.23.4、24.22.1、26.12.1で修正されています（Node.jsのセキュリティリリース）。更新・確認コマンドは、既存のNode.jsのNode2Shell脆弱性の確認・更新手順で扱います。
HTTP2Shellの仕組みと深刻度の判断材料
HTTP2Shellの対応判断では、Brotliのデコーダーを組み込んでいるかと、外部から受け取る圧縮データの処理経路を分けて整理します。
境界外書き込みの概要
境界外書き込みとは、プログラムが確保したメモリ領域の外へデータを書き込む問題です。
NVDは、CVE-2026-111497をBrotliのデコーダー（c/dec/decode.c）に存在するバッファオーバーフローとして掲載しています。デコーダーは圧縮データを元に戻す処理を担います。この展開処理で書き込み先が本来の領域から外れると、メモリの内容を壊すおそれがあります。
対応対象を整理する際は、圧縮ライブラリの名前の有無だけでなく、デコーダーを組み込んでいるか、外部から受け取ったデータがその展開処理へ届くかを区別します。名称だけから、すべての利用環境で同じ危険性があるとは判断しません。
影響範囲と修正版の情報
修正状況は、単純なバージョンの大小ではなく、利用系列ごとの修正版と照合して判断します。
NVDは、Brotli 1.0.3〜1.2.0のライブラリまたはバイナリを、利用している系列に対応する最新版へ更新するよう案内しています。
系列 | 影響を受ける版 | 修正版 |
|---|---|---|
1.2系 | 1.2.0 | 1.2.1 |
1.1系 | 1.1.0 | 1.1.1 |
1.0系 | 1.0.3以上1.0.10未満 | 1.0.10 |
台帳には、導入済みの版だけでなく、その版が属する系列、配布元、組み込み先を記録します。製品側の修正済みビルドは、Brotli本体の更新案内とは分けて、その製品の提供元情報で判定します。
調査時に、利用しているBrotliの系列と組み込み先を記録します。
その系列の修正版、または組み込み先の提供元が示す修正版が利用構成に一致すれば、修正適用の確認へ進みます。
内包バージョンや修正内容を特定できなければ、対応済みにはせず、提供元への照会対象として残します。
深刻度と悪用情報の根拠
深刻度は、CVSSの掲載値と実際の悪用情報を分けて捉え、自環境の処理経路と合わせて判断します。
CVSSは脆弱性の深刻度を表す評価指標です。NVDには、評価主体の異なる2つの基本値が掲載されています。記録するときは、版と評価主体を分けて残します。
評価主体 | 規格 | 基本値 |
|---|---|---|
NVD（NIST）自身の評価 | CVSS v3.1 | 9.8（CRITICAL） |
CVE採番機関（CNA）であるGoogleの評価 | CVSS v4.0 | 9.2（CRITICAL） |
CISAは、2026年10月27日の公式告知で、CVE-2026-111497を悪用が確認された脆弱性のカタログ（KEV）へ追加したと発表しています。米国の連邦機関には11月10日までの対応が求められています。これは悪用実績を判断する根拠ですが、特定企業の被害件数や、自環境の侵害を示す情報ではありません。外部入力が未修正のデコーダーへ到達する構成なら修正対応を優先し、経路が不明なら調査を優先して、安全と判定しない運用にします。
▲ Brotliデコーダーの組み込み状況と外部入力の到達経路に基づく影響判断フロー。
Node.js以外のBrotli組み込み先と調査対象
圧縮ライブラリの棚卸しでは、OS管理のパッケージ、コンテナイメージ、アプリケーションの配布物、実行中の環境を分けて記録します。依存関係の所在と更新主体を対応付けると、OS更新をどの範囲の完了根拠に使えるかを整理できます。
言語ランタイム・ライブラリの調査対象
Python環境では、Brotli関連パッケージの導入有無だけでなく、仮想環境、依存関係定義、配布物、実行中の環境が同じ対象を指しているかを照合します。ここでいう依存ライブラリとは、アプリケーションが動作に利用する部品を指します。
PyPIで配布されているbrotliは1.2.1、brotlicffiは1.2.1.0で修正されています（GitHub Advisory GHSA-9v8h-qqgm-4m35）。利用している場合は、仮想環境ごとの導入内容、依存関係を定義したファイル、配布物に含まれるライブラリ、実行中の環境を照合します。例えば、対象の仮想環境でpython -m pip list、python -m pip show brotli、python -m pip show brotlicffiを実行すると、導入済みパッケージと導入先を台帳へ記録できます。導入版が修正版より古ければ更新対象として記録します。定義と実体が一致すれば更新対象を整理でき、不一致なら稼働中の実体を特定する調査を先に進めます。
Go言語では、移植版のライブラリandybalholm/brotliの1.2.7より前の版も、NVDが影響を受ける構成として掲載しています。
製品同梱ライブラリの調査対象
curl、Webサーバー、ブラウザ、Electronなどは、製品名だけでなく、利用ビルド、追加モジュール、配布物に含まれるファイルを調べる対象です。ビルドとは、その製品をどの構成で組み立てたかを示す単位です。
Brotli対応という表示だけで脆弱性の有無を判断せず、圧縮データを展開するデコーダーの利用と、提供元の対象製品情報を照合します。F5は、NGINX Plus Brotliモジュールの案内で、同モジュールはデコーダー機能を直接使わないため本件の直接的な影響を受けないと説明しています。この説明を別製品へ当てはめず、利用構成に対応した情報が得られれば判断記録へ進み、対応関係が不明なら構成情報を添えて提供元へ問い合わせます。
配布物の確認では、アーカイブを展開した作業用ディレクトリ、インストール先、コンテナイメージのファイル一覧を対象にします。ファイル名にBrotliを含むことは候補抽出の材料ですが、影響判定はファイル名だけで確定しません。バイナリに静的に組み込まれた実装、名称を変えたファイル、製品独自の配布形式があり得るため、候補を見つけた後は製品のバージョン情報、ソフトウェア部品表、提供元の対象条件を組み合わせて記録します。
OSパッケージ・クラウド/CDNの調査対象
OSパッケージについては、利用しているOSのパッケージ管理画面またはパッケージ管理コマンドで、Brotliに関係する導入項目と更新履歴を取得します。RPM系ではrpm -qa | grep -i brotli、Debian系ではdpkg-query -W '*brotli*'、Alpine Linuxではapk info -v | grep -i brotliが候補の一覧化に使えます。OS配布元は、修正を元の版番号のまま取り込む（バックポートする）ことがあります。そのため、NVDの修正版番号ではなく、OS配布元のセキュリティ情報に載っている修正済みパッケージの版と照合します。たとえばDebianのセキュリティトラッカーでは、Debian 12は1.0.9-2+deb12u1、Debian 13は1.1.0-2+deb13u1で修正済みです。導入一覧が修正済みの版と一致すれば、OS管理下の対象について完了記録へ進み、一致しなければ更新計画を立てます。
コンテナでは、ホストOSの一覧ではなく、稼働中または配布予定のイメージごとに確認します。たとえばシェルを利用できるイメージならdocker run --rm イメージ名 sh -c 'rpm -qa 2>/dev/null; dpkg-query -W 2>/dev/null; apk info -v 2>/dev/null'のように、イメージ内のパッケージ管理情報を取得します。パッケージ管理情報が存在しない最小イメージや静的バイナリ中心の成果物では、SBOM、ビルド定義、成果物の作成記録を確認先にします。SBOMにBrotli関連のコンポーネント名やPURLが確認できれば、その配布物を調査対象として台帳に追加し、該当しなければSBOMの生成範囲とビルド成果物の対応を見直します。
クラウド/CDNでは、利用者が管理するアプリケーションと提供元が管理する基盤を分けます。CDNはコンテンツ配信のためのネットワークです。変更権限が利用者側にあれば社内の更新担当へ、提供元側にあれば契約上の窓口へ調査を割り当てます。
調査対象 | 依存関係の所在 | 更新主体 | 必要な証跡 |
|---|---|---|---|
言語パッケージ | 仮想環境・配布物 | アプリケーション管理担当 | 依存関係の定義・導入一覧・実行環境の記録 |
製品同梱ライブラリ | 製品の配布物内 | 製品提供元・導入担当 | 利用ビルド・同梱構成・提供元の対象情報 |
OSパッケージ | OS管理下の導入先 | OS管理担当 | 導入一覧・配布元の案内・更新履歴 |
クラウド/CDN | 利用者管理領域・提供元基盤 | 各領域の管理者 | 責任分界・変更権限・提供元の回答 |
調査票には、この表に加えて確認日と担当窓口を残します。所在と更新主体を特定した対象から、提供元情報と照合します。証跡がない対象は調査中のまま管理します。
▲ OS管理パッケージと製品同梱ライブラリにおける所在・更新主体・必要証跡の比較。
提供元ごとの影響・修正状況の確認方法
修正状況は、利用中の製品・ビルドに対応する提供元の公式情報を根拠に判定します。
本件への対応では、ライブラリ単体の修正情報と、それを組み込んだ製品の修正情報を分けて扱います。
公式情報による確認結果
F5の案内で確認できるのは、NGINX Plus Brotliモジュールが本件の直接的な影響を受けないという、対象を限定した結論です。
F5は、アドバイザリ番号K000163902で、NGINX Plus Brotliモジュールについて、Brotliデコーダー、つまり圧縮データを展開する機能を直接使用しないため、CVE-2026-111497の直接的な影響を受けないと案内しています。根拠はF5のNGINX Plus Brotliモジュールに関するアドバイザリです。この説明をWebサーバー全体や、別のモジュールを含む構成へ一般化してはいけません。
Brotli本体の修正版（1.0.10、1.1.1、1.2.1）は、各製品の修正済みビルドを示すものではありません。製品別の更新判断は、その製品の提供元が公開するセキュリティアドバイザリ、リリースノート、サポート文書の対象条件と照合します。NVDが影響を受ける構成として掲載している製品のうち、修正の境目となる版が示されているものは次のとおりです（2026年11月9日時点）。
製品 | 影響を受ける版（NVDの掲載） |
|---|---|
Node.js | 22.23.4、24.22.1、26.12.1より前（各系列） |
.NET | 8.0.33、9.0.22、10.0.14より前（各系列） |
Bun | 1.4.4より前 |
Envoy | 1.37.8、1.38.6、1.39.3より前（各系列） |
Istio | 1.29.9、1.30.6、1.31.2より前（各系列） |
PyPIのbrotlicffi | 1.2.1.0より前 |
Go版andybalholm/brotli | 1.2.7より前 |
このほか、Debian、7-Zip系のツール、データベース製品、Siemensの産業用製品なども影響を受ける構成として掲載されています。利用中の製品が掲載されていない場合も、影響がないとは判断しません。
対象 | 確認時に照合する情報 | 公式根拠 | 追加で必要な情報 | 判断への影響 |
|---|---|---|---|---|
NGINX Plus Brotliモジュール | デコーダー機能を直接使用しないというF5の対象限定の説明 | F5の当該アドバイザリです。 | 利用中のモジュールと構成が案内の対象に一致するかを照合します。 | 一致すれば、その範囲に限定して対象外の根拠を保存します。 |
Python環境 | 導入済みパッケージ、仮想環境、配布物、修正版（brotli 1.2.1、brotlicffi 1.2.1.0） | GitHub Advisory GHSA-9v8h-qqgm-4m35 | パッケージ名、導入版、修正情報を照合します。 | 利用構成に一致する情報が得られれば更新対象を記録し、得られなければ照会対象として管理します。 |
curl | 利用ビルド、コンパイル時の構成、提供元の対象条件 | curl提供元または配布元のセキュリティ情報 | 利用ビルドと組み込み構成を照合します。 | 構成に合う情報が得られれば判定記録へ進み、得られなければ継続調査に進みます。 |
その他のWebサーバー | 製品名、ビルド、追加モジュール、デコーダー利用条件 | 製品提供元のセキュリティ情報 | 製品名、ビルド、追加モジュールを照合します。 | F5の結論を流用せず、製品別に判定します。 |
ブラウザ／Electron | 製品版、配布チャネル、組み込みコンポーネントの修正情報 | 各製品提供元のセキュリティ情報 | 製品版と組み込み先の修正情報を照合します。 | 修正版との対応が確認できれば更新対象を確定し、確認できなければ未判定として管理します。 |
OSパッケージ | 配布元、パッケージの版、バックポートされた修正済みの版、利用している配布物 | OS配布元のセキュリティ情報 | 配布元、パッケージの版、修正適用情報を照合します。 | OS管理下の対象条件に一致すればOS側の対応を記録し、配布物側は別の根拠で判定します。 |
クラウド／CDN | 利用サービスの対象範囲、責任分界、提供元側の対応状況 | サービス提供元のセキュリティ情報・サポート回答 | 利用サービスの対象範囲と提供元側の対応状況を照合します。 | 自社で更新できる範囲と提供元への照会事項を分けます。 |
未判定対象の扱い
上表で提供元情報との照合が必要な対象は、各提供元のセキュリティアドバイザリ、リリースノート、サポートページでCVE-2026-111497を検索します。利用中の製品・ビルドと修正版の記載が一致すれば更新計画へ進み、該当する記載が見つからなければ、製品名、ビルド、導入経路、利用している機能を添えて提供元への照会に回します。
ニュース記事や大学による紹介だけで示される製品別バージョンは、ここでの判定根拠には採用しません。CVSSの値は、NVDの評価（v3.1）と提供元の評価（v4.0）のどちらも深刻度の目安であり、利用中の構成が影響を受けるかの判定根拠にはなりません。追加調査の記録には、確認日、公式資料名、対象製品・ビルド、適用条件、未解決事項を残します。資料が見つからなかった場合も、照会した製品・構成・窓口を記録すれば、後続の担当者が調査を引き継げます。
確認結果別の対応判断
確認結果は、更新計画・対象外記録・未判定の継続調査に分け、証拠が不足する対象を対象外へ移さない運用にします。
公式情報で利用構成に合う修正版を確認したら、対象ビルド、修正内容、動作検証の結果、更新日程を記録します。
公式に対象外と確認できれば、根拠資料と適用条件を保存します。構成が変わった場合は、その結論を引き継がず再判定します。
判断材料が不足する場合は、未判定として残します。提供元へ利用構成を添えて照会し、回答を待つ間の暫定対応を検討します。
すぐ更新できない場合の暫定対応と解除条件
更新を待つ間は、問題の処理経路を把握できる範囲で入力制限や機能停止を検討し、修正版への移行を別途管理します。
Brotli本体の提供元であるGoogleは、本脆弱性の緩和策を提供していません（JPCERT/CC）。組み込んだ製品の緩和策は、各提供元の情報を確認します。たとえばMicrosoftは.NETの告知で、ASP.NET Coreの要求の自動展開とHttpClientの応答の自動展開は既定で無効であり、これらでBrotliを有効にしている場合や、Brotliの展開APIを明示的に使っている場合に影響を受けると説明しています。
提供元の緩和策がない環境では、外部入力が展開処理へ届く経路と、自社で変更できる範囲を整理し、検証できた範囲だけを対応済みとして扱います。
対象経路を把握できれば、その経路への入力制限や、展開機能の停止を検証対象にします。把握できなければ遮断効果を断定せず、提供元へ入力経路と停止可否を照会し、変更権限の整理と更新準備へ進みます。変更権限がない場合は、提供元への依頼事項と自社側の作業を分けて管理します。
圧縮したデータの配信停止と、デコーダーの利用停止は同一視しません。デコーダーは圧縮データを展開する処理です。設定変更を試す場合は、目的の展開経路を止められるか、業務への影響を許容できるか、変更前へ戻せるかを検証条件にします。いずれかを確認できなければ、その変更を防御策として計上せず、別の制限方法や正式更新を検討します。
担当は組織内の権限に合わせて割り当て、次のフェーズ表で暫定変更と正式更新を分けて管理します。
着手条件 | 実施内容 | 担当 | 残るリスク | 次の判断 |
|---|---|---|---|---|
初動整理：対象構成の調査開始時 | 入力経路、変更権限、業務上の制約を整理します | 運用担当・提供元窓口 | 未把握の処理経路 | 経路を特定できれば検証へ、不明なら照会と更新準備へ進みます |
暫定変更の検証：対象経路と変更権限が明確な場合 | 入力制限や機能停止、業務影響、復旧手順を検証します | 変更担当・業務責任者 | 未検証の経路からの入力 | 条件を満たせば適用し、満たさなければ別案を検討します |
正式更新：対象構成の修正版と更新手順を確認できた場合 | 更新を実施し、稼働状況と配布物の記録を照合します | 更新担当・運用担当 | 更新漏れや動作不良 | 修正・稼働・配布物の確認結果で解除可否を判断します |
解除判定：更新結果がそろった場合 | 暫定制限の解除範囲を決め、解除後の動作を確認します | 運用担当・業務責任者 | 未確認の構成や配布物 | 確認済み範囲だけ解除し、未確認部分は対応を継続します |
解除条件は、対象構成の修正確認、更新後の稼働確認、対象配布物と実行環境の照合です。監視で異常が見えないことだけを、未侵害や修正完了の証拠にはしません。提供元の回答、構成変更、新たな入力経路の判明を再評価のきっかけとして記録し、暫定対応を続ける場合も正式更新の担当と未完了事項を残します。
▲ Brotli脆弱性への暫定対応から正式更新・解除判定に至る4つのフェーズ。
Brotli脆弱性対応で避けたい失敗パターン
対応完了は更新作業の実施だけではなく、実行環境と適用根拠の照合によって判定します。以下は実在企業の事例ではなく、Brotli脆弱性対応で調査結果を読み違えないための一般的な注意点です。
OS更新だけでの完了判定
OSを更新した後に対応を完了とするかは、OS配布元の修正情報が対象のOSパッケージに適用され、かつ台帳上の対象配布物・実行環境との対応関係を説明できるかで決めます。OS管理下の対象だけが台帳に記録され、OSの導入一覧と配布元の対象条件が一致すれば、その範囲は完了記録へ移します。配布物、コンテナ、静的バイナリなど別の確認経路を持つ対象が台帳に残るなら、その対象はOS更新とは分けて調査を継続します。
誤った判断 | 不足する証拠 | 修正後の判断 |
|---|---|---|
OS更新が成功したので、すべての対象を調査対象から外します。 | 台帳上の各配布物・実行環境と、OS配布元の修正対象との対応を示す記録です。 | OS管理下として確認できた対象は更新履歴で判定し、それ以外は更新主体と配布物を別に管理します。 |
更新担当が異なる対象を一括で完了にすると、担当間の対応漏れを見落とします。配布物ごとに根拠がそろった範囲だけを完了とします。たとえば、OSの共有ライブラリはパッケージ管理の導入一覧で版を確認できますが、コンテナイメージ、CI/CDの成果物、個別に配布されたバイナリは、それぞれの成果物一覧、SBOM、ビルド時の依存関係ファイルを確認先にします。これらの記録が対象配布物と一致すればその行の判定を更新し、一致しなければ別行で調査を継続します。
たとえばMicrosoftは、.NETのself-containedアプリケーションやNativeAOTアプリケーションについて、マシンの共有ランタイムを更新するだけでは修正されず、修正済みのランタイムで再ビルドして再配布する必要があるとしています。
機能名だけでの影響判定
Brotli対応という表示やHTTP2Shellという名称だけでは、対象・対象外を決めません。
誤った判断 | 不足する証拠 | 修正後の判断 |
|---|---|---|
Brotli対応の表示だけで影響ありとします。 | 使用する実装と処理に対する提供元の適用根拠です。 | 機能の有無と脆弱性の該当性を分けて判定します。 |
HTTP2Shellという名称だけで調査範囲を限定します。 | 提供元が示す対象条件との一致です。 | 名称ではなく、実装と構成に基づいて対象を管理します。 |
F5は、NGINX Plus Brotliモジュールがデコーダー機能を直接使用しないため、CVE-2026-111497の直接的な影響を受けないと説明しています。この結論を他製品や異なる構成へ拡張してはいけません。
証跡不足での完了判定
更新・対象外・異常なしは別の判断であり、それぞれに対応する証拠を残します。
誤った判断 | 不足する証拠 | 修正後の判断 |
|---|---|---|
開発環境を更新したので完了とします。 | 本番の実行環境への反映記録です。 | 本番への適用を裏付けられれば完了とし、なければ未完了とします。 |
未判定の対象を対象外にします。 | 対象外とする条件と、その一致を示す記録です。 | 根拠がなければ未判定のまま管理します。 |
異常ログがないので安全とします。 | 修正版の適用、または対象外を示す根拠です。 | ログの有無だけでは対応完了にしません。 |
完了記録には実行環境・判定結果・適用根拠をひも付け、根拠が欠ける対象は完了件数に含めない運用にします。
SBOMによる依存ライブラリの棚卸しと対応管理
SBOMはソフトウェアの構成要素を整理した一覧であり、本件の対応では実行環境と更新担当を結び付けて使います。収集した情報に判定根拠と未判定項目を付け、対応完了まで追跡する台帳として運用します。
棚卸し台帳の記録項目
台帳には、構成情報だけでなく、誰が更新し、何を根拠に判定したかを記録します。同じシステムでも配布物や実行環境が異なる場合は行を分け、確認結果の取り違えを防ぎます。
項目 | 記入欄・記録内容 |
|---|---|
対象システム | ［記入］名称・管理用の識別情報 |
配布物・実行環境 | ［記入］配布物の識別情報・稼働先・用途 |
Brotliの所在 | ［記入］ファイルの場所・依存関係上の位置 |
バージョンまたは修正根拠 | ［記入］確認値・提供元の修正説明 |
組み込み形態 | ［記入］個別導入・同梱などの形態 |
更新主体 | ［記入］更新を実施する部署・提供元 |
公式資料 | ［記入］資料名・URL・確認日・該当箇所 |
判定 | ［記入］影響あり・影響なし・未判定と、その根拠 |
担当 | ［記入］調査・対応の担当者、期限、未判定項目の確認方法 |
再確認条件 | ［記入］情報更新・構成変更など、再判定の契機 |
SBOMの検索では、コンポーネント名だけでなく、パッケージURL（PURL）、CPE、サプライヤー名、バージョン、配布物の識別情報を確認項目にします。名称一致の結果は候補抽出に使い、該当コンポーネントが実際に対象配布物へ含まれることは、SBOMのmetadata、コンポーネント階層、ビルド成果物の識別情報で照合します。SBOMに該当名がない場合も、そのSBOMがコンテナ、OSパッケージ、アプリケーション依存関係のどこまでを生成対象にしたかを記録し、範囲外の配布物は別の確認手段に回します。
修正根拠は「最新版」とだけ書かず、対象との対応関係を残します。Brotli本体なら「1.2系の修正版1.2.1を適用」のように系列と版を書き、OSパッケージや製品なら、配布元・提供元が示す修正済みの版と資料名を書きます。Brotli本体の修正版と、対象配布物の提供元が示す修正済みビルドの説明は区別して扱います。
対応完了の判定項目
対応完了は、更新の予定や配布だけでなく、稼働中環境への反映と証跡までそろった段階で判定します。更新対象には、次のチェックリストを適用します。
公式情報と対象の構成・修正根拠を照合し、判定理由を記録しました。
対象配布物を更新し、更新後の識別情報を台帳に反映しました。
稼働中環境への反映を確認し、確認方法と結果を残しました。
古い配布物について、削除・隔離・再利用防止などの扱いを決めました。
参照資料、更新記録、稼働確認結果を保存し、台帳から参照できるようにしました。
自動収集で把握できない項目は、影響なしではなく未判定として残します。所在や組み込み形態が分からなければ、担当と確認方法を設定します。提供元への照会結果や実行環境の調査で根拠がそろえば判定を更新し、そろわなければ対応完了にはしません。
継続確認への引き継ぎ項目
提供元の情報更新や利用構成の変更があれば、保存した判定を再評価します。過去の「影響なし」を別の配布物へ流用せず、変更後の構成に対応する記録を作ります。
着手時は、利用環境の一覧と更新担当を対応付けます。
確認できた対象から判定記録を作成し、未確認の対象には担当・期限・確認方法を設定します。
対応後は、公式情報の更新、配布物の差し替え、依存関係や稼働先の変更を再確認条件として引き継ぎます。
再判定では以前の記録を消さず、変更点と判断理由を追記します。これにより、残っている作業と対応を終えた根拠を、次の担当者も追跡できます。
まとめ
Brotliの脆弱性CVE-2026-111497は、Brotli 1.0.3〜1.2.0のデコーダーにある境界外書き込みで、悪用が確認されています。Brotli本体は1.0.10、1.1.1、1.2.1で修正されています。
製品名やBrotli対応の表示だけで影響を決めず、デコーダーの利用、外部入力の処理経路、利用中の製品・ビルド、提供元の対象条件を対応付けます。Node.js、.NET、PyPIのbrotli／brotlicffiなどは、提供元が修正版を公表しています。
OS更新は、OS配布元の修正済みパッケージと台帳上の対象配布物・実行環境が一致する範囲で完了根拠に使えます。コンテナ、アプリケーション配布物、個別バイナリなどは、SBOM、ビルド記録、製品提供元の情報に基づいて別に判定します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
