「Brotliに脆弱性」と聞いて、自社サイトをすぐに停止すべきか迷う担当者もいるでしょう。
BrotliはWebの通信量を減らすために広く使われており、本人が導入した覚えがなくても、サーバーやアプリの部品として組み込まれていることがあります。
今回の確認で焦点になるのは、サイトの画面を圧縮して送ることよりも、どの製品が外部から受け取ったBrotliデータを展開しているかです。
2026年10月29日時点の公的機関と製品開発元の情報を基に、影響の調べ方から対応先まで整理します。
Brotliは、文字などのデータを圧縮し、通信量を減らすための技術です。
例えばWebサイトがページのデータを小さくして送れば、受け取ったブラウザが展開して表示できます。
圧縮はデータを小さくまとめる処理、展開は元に戻す処理です。
サイト側がBrotli形式でデータを送ることだけでは、今回の脆弱な展開処理がサイト側で実行されるとは限りません。
一方、サーバー側のアプリが外部のサービスから圧縮された応答を受け取ったり、利用者からの圧縮データを展開したりする経路があれば、その展開に使う実装を調べる必要があります。
ブラウザなど受信側にも、それぞれ製品別の確認が必要です。
CVE-2026-111497は、BrotliのC言語実装のデコーダーにある境界外書き込みの脆弱性です。
細工された入力によって、本来書き込むべき領域の外にデータが書かれ、メモリが破損する可能性があります。
JPCERT/CCによると、この問題はNode.jsの公表に関連して「Node2Shell」と呼ばれ、その後、原因が複数の製品に組み込まれるBrotliにあることから「HTTP2Shell」とも呼ばれるようになりました。
いずれも今回のCVEに関連する通称であり、HTTP/2を使うサイトだけが対象という意味ではありません。製品と処理経路をCVE番号で照合してください。
出典：JPCERT/CC（2026年10月26日更新） https://www.jpcert.or.jp/at/2026/at260034.html
攻撃が成立するには、影響を受ける実装が使われ、その処理に攻撃者が細工したBrotli形式のデータを渡せる必要があります。
入力は受信リクエストに限りません。アプリが取得する外部サイトやAPIの応答を展開する処理も確認対象です。
JPCERT/CCは、メモリ破損によるアプリの異常終了、メモリ上の情報漏えい、任意のコード実行を挙げています。
コード実行が成立した場合の影響は、実行プロセスの権限や、その環境が扱う情報などによって変わります。
存在する脆弱性から直ちに、あらゆる環境で同じ被害が起こるとは判断できません。
カナダのサイバーセキュリティセンターは、CISAが2026年10月27日にこのCVEを既知の悪用された脆弱性（KEV）カタログへ追加したと伝えています。
これは現実世界での悪用が確認された問題として扱われていることを示しますが、自社への攻撃や侵害が確認されたことを意味しません。
影響を受ける可能性があれば、修正と並行してログや製品ベンダーの情報を確認します。
異常終了がないことや、ログに不審な記録が見つからないことだけで侵害を完全に否定することもできません。
判断が難しい場合は、記録を保全して専門家へ相談してください。
出典：カナダ政府（2026年10月28日更新） https://www.cyber.gc.ca/en/alerts-advisories/al26-027-critical-vulnerability-impacting-google-brotli-cve-2026-111497
JPCERT/CCとJVNが2026年10月26日時点で示すBrotli本体の対象は、1.0.3以上1.0.10未満、1.1.0以上1.1.1未満、1.2.0以上1.2.1未満です。
各系統の修正版はそれぞれ1.0.10、1.1.1、1.2.1です。
OSベンダーが修正を旧バージョンに取り込んでいる場合もあるため、表示番号だけで確定せず、その配布元の案内を確認します。
製品別には、次の情報が確認できます。数値は2026年10月29日の確認時点です。
JPCERT/CCはNode.js、Bun、Python向けBrotliパッケージなどを例に挙げています。
これらは影響を受ける可能性のある製品例であり、同名の環境がすべて同じ条件で攻撃可能という意味ではありません。
出典：JVN https://jvn.jp/vu/JVNVU97400824/index.html
Node.js https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
Python https://github.com/advisories/GHSA-9v8h-qqgm-4m35
Bun https://github.com/oven-sh/bun/security/advisories/GHSA-663w-cv8g-jj2p
開発者は、稼働中のサーバー、コンテナ、サーバーレス関数、ビルド環境を洗い出し、それぞれの実行環境とライブラリを確認します。
手元の開発端末だけでなく、本番のコンテナ内など、実際に動いている場所で調べることが必要です。
Node.jsなら「node -v」で実行バージョンを確認し、Dockerfileやベースイメージ、デプロイ設定の固定バージョンも照合します。
Pythonでは対象環境の「python -m pip show Brotli」と「python -m pip show brotlicffi」で導入状況を確認できます。
ただし、これらの結果だけで、別の製品に組み込まれたコピーやOS側の実装まで網羅できるとは限りません。
依存関係一覧、ロックファイル、SBOM、コンテナのスキャン結果に加え、製品のセキュリティ情報を確認します。
npm auditなどのパッケージ検査だけではNode.js本体の状態を十分に判断できないため、実行環境そのものも点検してください。
サーバーの管理画面しか触れない担当者は、推測で設定を変更するより、保守会社やホスティング事業者にCVE番号を伝え、次を確認すると対応を進めやすくなります。
クラウド上でマネージドサービスを使っていても、別途用意したコンテナや外部バックエンドは利用者側の管理対象となる場合があります。
サービス名だけで判断せず、構成ごとに責任範囲を整理してください。
影響がある製品は、開発元や配布元が案内する修正版を確認し、互換性をテストしたうえで速やかに適用します。
Brotli本体を更新しても、アプリに同梱されたライブラリや静的リンクされた実行ファイルが自動的に置き換わるとは限りません。
ベンダーの指示に従い、アプリやコンテナを再ビルドし、再配備後に稼働中のバージョンを確認します。
修正まで時間がかかる場合は、不要な経路で信頼できないBrotliデータを展開しないよう、製品ごとに提供される緩和策を検討します。
JPCERT/CCによれば、GoogleはBrotli本体に対する緩和策を提供していません。
入り口での通信制限やWAFは対象経路を減らす手段にはなりますが、外部から取得した応答の展開など、別経路まで守れるとは限りません。
修正の代替と考えず、影響を検証して適用してください。
例えばVercelは、管理対象の実行環境への修正展開と受信経路の保護を案内する一方、外部バックエンドや自前コンテナのNode.jsは利用者が更新するよう求めています。
具体的な条件は、利用中のサービスの最新告知で確認してください。
予期しないプロセス停止、不審な実行、外部通信、権限の変更などがあれば、担当するセキュリティチームや保守会社に連絡します。
侵害が疑われる場合は、影響システムの隔離とログ・証拠の保全を専門家と進め、認証情報の漏えいが疑われる場合の失効・再発行も検討します。
調査前に記録を消去したり、出所不明の検査ツールを本番で実行したりしないでください。
今回のように、脆弱な部品が実行環境や別のライブラリに組み込まれていると、アプリの開発者がBrotliを直接選んでいなくても調査が必要になります。
依存関係、実行環境、コンテナイメージ、外部サービスの一覧を保ち、通知の受け取り先と更新担当者を決めておくと、次の脆弱性にも対応しやすくなります。
更新の完了条件は、修正済みのコードを用意することだけではありません。
テスト、再ビルド、再配備、稼働中の環境の確認までを一連の手順として記録します。
重要なシステムでは、緊急更新の承認方法とロールバック手順も事前に整えておくとよいでしょう。
バイブコーディングで作ったアプリでも、公開後は通常のWebアプリと同様に、ランタイム、依存パッケージ、ホスティング設定が必要です。
AIが書いたコードだけを見ても、実際の配備先に何が組み込まれているかは分かりません。
リポジトリの依存関係、デプロイ先、外部通信、更新権限を確認し、自分で把握できない部分はサービス提供者や開発を依頼した人に尋ねてください。
インターネットに公開された重要サービスで対象製品が見つかった場合、攻撃の兆候がある場合、影響範囲を確定できない場合は、社内のセキュリティ担当者や外部のインシデント対応専門家に相談します。
関連する別の問題については、公開済みの「PHP2Shellを狙う攻撃、日本も対象に」と、バイブコーディングの脆弱性を扱う記事も参照してください。
最初に確認すべきなのは、利用中の製品と、外部からのBrotliデータをどこで展開するかです。
影響がある場合は製品の修正情報に従い、テスト、更新、必要な再配備、侵害調査を進めてください。
管理を委託している場合も、事業者側の対応だけで自社アプリや外部バックエンドまで修正されるとは限らないため、担当範囲を確認することが次の行動になります。
.png){kind=logo}
