この記事のポイント
- 脆弱性
- CVE-2026-111497
- 深刻度
CRITICAL9.2
- 対象
- PythonパッケージBrotli:1.0.3以上1.2.1未満、Pythonパッケージbrotlicffi:1.0.3以上1.2.1.0未満、対象パッケージを使ってBrotli応答を解凍するRequests・urllib3利用環境
- 悪用状況
- 不明
- 推奨対応
- Brotliを1.2.1、brotlicffiを1.2.1.0へ更新し、依存ロックと配布イメージを更新してください。全ワーカーを置き換えて稼働版を確認し、外部応答の自動解凍経路を優先して点検します。
- 公表日
目次
Node.jsのBrotli脆弱性に対応したチームも、Pythonで動くURLプレビュー、クローラー、データ取得ワーカーを別に点検してください。CVE-2026-111497はNode.js固有の不具合ではなく、同梱されるBrotliデコーダーの問題です。PythonパッケージのBrotliとbrotlicffiにも影響があり、修正版はそれぞれ1.2.1と1.2.1.0です。
重要なのは、アプリのコードにBrotliの解凍処理を書いたかどうかだけでは判断できない点です。RequestsなどのHTTPクライアントは、対応パッケージがインストールされていると圧縮応答を自動で解凍します。公開Webサーバーの受信要求を制限しても、バックグラウンド処理が外部から受け取る応答は別経路です。
本稿は2026年10月25日にGoogle Brotliのリリース情報、brotlicffiの修正履歴、GitHub Advisory DatabaseのPython向け登録を直接確認した続報です。新しいCVEが増えたという話ではなく、既報の更新対象をPythonの依存関係へ広げるための記事です。以下の構成例と確認手順は本サイトの提案であり、Pythonでコード実行を実証した結果ではありません。
このCVEは10月21日のNode.js公式セキュリティ告知ですでに公表され、Google Brotliの修正版も同日付で公開されています。Python向け登録の更新日は10月23日、本記事の確認日は10月25日です。確認日に新たな脆弱性や被害が発生したという意味ではありません。
スポンサーリンク
今回増えた判断材料はPython側の更新対象
本サイトのNode.jsの10月セキュリティ更新記事は、10月22日の確認時点でNode.js本体、CI、コンテナなどの更新を扱いました。本稿では、Node.jsを使わないPython環境や、Node.jsと併用している取得ワーカーを追加の点検対象にします。Node.jsの修正版を入れても、別プロセスのPythonパッケージは更新されません。
Google Brotliの1.2.1・1.1.1・1.0.10のリリースには、CVE-2026-111497への修正が明記されています。一方、Python向けBrotliの配布物として今回確認した更新先は1.2.1です。Cライブラリーの保守系列と、PyPI上のPythonパッケージの更新先を混ぜないでください。
GitHub Advisory Databaseは10月22日に登録、10月23日に更新され、Brotliは1.0.3以上1.2.1未満、brotlicffiは1.0.3以上1.2.1.0未満を影響範囲として掲載しています。修正履歴だけでなく、依存関係の検査に使う登録情報も変化しているため、過去のスキャン結果を今回の状態と同じものとして扱わないことが大切です。
攻撃者の圧縮データが解凍へ届くことが条件
問題は、不正なBrotli圧縮ストリームによる境界外書き込みです。メモリーの破損、機密情報の開示、サービス妨害、任意コード実行につながる可能性があります。Node.jsの公式告知も、攻撃者が渡したBrotliデータをアプリが解凍する経路を条件として説明しています。
ここで「Pythonを入れているサーバーはすべて侵入される」と広げるのは不正確です。対象のデコーダーを含む環境があり、その処理へ攻撃者の制御するデータが届くかを調べます。パッケージの存在は更新対象の発見に使い、入力経路は対応の優先順位を決めるために使います。経路の調査が済むまで更新を止める必要はありません。
GitHubの登録では深刻度はCritical、CVSS 4.0は9.2です。Node.js側の告知はHighとしており、評価主体と対象が異なる点を区別します。また、コード実行につながり得ること、特定環境での研究上の実証、実環境での悪用確認は別の情報です。本稿で直接確認できた開発元資料から、Python環境の実被害を確定することはできません。
スポンサーリンク
自分でimportしなくてもRequests経由で使われる
Requestsの公式Quickstartは、Brotliまたはbrotlicffiがインストールされていると、brで符号化された応答を自動で解凍すると説明しています。urllib3の公式資料も両パッケージによるBrotli対応と、追加依存の指定方法を示しています。アプリのソース内でimport brotliを検索するだけでは利用範囲を把握できません。
たとえば、利用者が指定した記事URLをPythonワーカーが取得して概要を表示するサイトを考えます。これは説明用の仮想例です。攻撃者が応答元を制御でき、ワーカーが返されたBrotliデータを自動解凍するなら、通常の外向きHTTP通信がデコーダーへの入力になります。管理画面へログインできる攻撃者だけを想定していると、この経路を見落とします。
別のパッケージが追加依存としてBrotliを導入したり、開発用と本番用で解決される依存関係が違ったりする場合もあります。確認するのはリポジトリに書かれた直接依存だけでなく、実際の仮想環境と配布イメージにインストールされた集合です。ベースイメージを共有する別サービスへも、対象の有無を照会します。
更新するパッケージと配布経路を分ける
| 対象 | 確認した修正版 | 運用上の注意 |
|---|---|---|
| PyPIのBrotli | 1.2.1 | 稼働するPython環境とロックファイルを照合 |
| PyPIのbrotlicffi | 1.2.1.0 | 同梱libbrotliの更新を修正履歴で確認 |
| OS配布のパッケージ | 配布元が当該CVEを修正した版 | バックポートを含む配布元の告知で判断 |
brotlicffiの1.2.1.0の変更履歴は、libbrotliを1.2.1へ更新して当該CVEを修正したことに加え、完了したストリームの後ろに余分なバイトがある入力をエラーにする変更も説明しています。以前は受け入れていたデータが拒否される可能性があるため、更新後の通常データとエラー処理を確認します。BrotliのPyPI配布ページでは1.2.1の配布物も確認できます。
本サイトが勧める順序は、まず外部応答を処理するサービスと対象環境を特定し、依存制約とロックを更新し、検証用イメージを作り直してから本番へ展開する方法です。Brotliとbrotlicffiの両方が入っている環境では、片方を更新したという記録だけで完了にしません。両方の状態を確認します。
確認コマンドは、サービスが実際に使うPythonへ対して実行します。管理者の端末のpythonと、コンテナ内の仮想環境が別なら結果も別です。次の例はインストール状況の表示だけを行い、デコーダーへ攻撃入力を与えるものではありません。
python -m pip show Brotli brotlicffi
python -m pip check
パッケージが見つからないという結果は、そのコマンドを実行した環境についての情報です。全サービスで未使用という証明にはなりません。また、pip checkは依存関係の整合性を調べる補助であり、脆弱性がないことや修正の有効性を保証する検査ではありません。
スポンサーリンク
Accept-Encodingからbrを外すだけで完了にしない
暫定策を考える場合も、要求で送るAccept-Encodingと、応答に付くContent-Encodingを区別します。前者は利用可能な形式の通知であり、相手から届く全データを強制的に制限する境界ではありません。brを要求しない設定に変えただけで、脆弱な解凍処理が到達不能になったとは判断できません。
本サイトの提案として、更新までの間は不要な外部取得機能を止めるか、対象のBrotli解凍へ入力が渡る前に拒否できる構成を検討します。HTTPクライアントによっては通常のリクエスト処理中に本文を自動処理するため、レスポンスを受け取った後でヘッダーを検査するコードでは遅い場合があります。実際の利用ライブラリーと設定で、処理の順番を確認してください。
Brotli対応が任意なら、対象パッケージを外した検証環境を作る案もあります。ただし、依存関係が自動で再導入しないこと、brの応答が来た場合に安全に失敗すること、必要な機能が保たれることを確認します。別の圧縮形式へ必ず自動で再取得されると期待してはいけません。暫定策には対象機能、適用範囲、担当者、修正版へ移る期限を残します。
再ビルド後に全ワーカーの稼働状態を確かめる
ロックファイルを更新しても、すでに配備されたイメージや長時間稼働するワーカーは変わりません。新しい成果物を配布し、旧プロセスを置き換え、待機系や定期ジョブも含めて対象を照合します。調査表にはサービス名、Python環境、対象パッケージの版、イメージ識別子、切り替え時刻を対応付けます。
検証では、自社管理の正常な圧縮応答が処理できること、通信失敗や解凍失敗が制御されたエラーになること、再試行が無限に続かないことを確認します。本番で公開実証コードを実行する必要はありません。版の確認と通常機能の検証を分ければ、脆弱性の修正を証明するつもりで危険な入力を業務処理へ流す事態を避けられます。
更新前にクラッシュや不自然な外部接続があった場合は、対象URL、ジョブ、プロセス終了時刻、関連ログを保存して調査します。ただし、解凍エラーやクラッシュだけで当該CVEの悪用が成立したとは確定しません。異常を調べる対象と、侵害が確認された事実を区別して報告します。
今回の優先順位は、攻撃者が指定できるURLを取得する処理、外部データを継続取得するワーカー、圧縮された受信本文を解凍する機能から確認することです。そのうえで残りの対象環境も更新します。Node.jsへの対応済みという一行を、Pythonや他のBrotli利用製品まで完了した意味へ広げないことが、今回の続報で変わる実務上の判断です。
関連記事
VercelのWAFと外部応答の保護範囲を分ける確認は、10月24日時点のVercel管理ランタイムと自前バックエンドを扱います。本稿は同じCVEのPython依存関係が中心であり、マネージドサービスの修正状況は各提供元の最新案内で別途確認してください。
出典・一次情報
本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。
-
公式アドバイザリ
-
公式アドバイザリ
-
その他
-
公式アドバイザリ
-
公式アドバイザリ













