まず押さえておきたいこと
何が起きたのか。
Brotliという圧縮方式のデータを展開するGoogle製のC言語ライブラリに、異常なデータを処理するとプログラムのメモリを壊す欠陥が見つかりました。停止や情報漏えい、条件がそろえば攻撃者の命令の実行につながります。CVE-2026-111497と呼ばれ、Node.jsなど複数の製品が修正を公開しています。これは、いわゆるWebなどで使われるHTTP/2の通信規格(プロトコル)そのものの欠陥ではありません。[1][2][3]
誰が確認すべきか。
Webサイト・予約や連携サービス・業務サーバを開発・運用する組織と、その保守事業者です。Node.jsやPythonで外部URLの内容を取得する処理、Brotli対応のプロキシやHTTPクライアントも対象を調べます。「その言語を使っている」「ページをBrotliで圧縮して配っている」という理由だけでは、攻撃可能かどうかを決められません。ポイントはBrotliを使って圧縮されたデータを展開(デコード)する処理を行っているかどうか、というところを見る必要があります。[8][9][14][18]
まず何をするか。
院内・社内で独断の更新や停止をせず、管理責任者を決め、制作会社・保守事業者・クラウド提供元に対象の有無、適用版、再起動・再配備の完了、侵害調査の必要性を確認してください。回答は日時とともに記録します。10章にそのまま使える問い合わせ文例を用意しました。
Impervaは公式の未改変Node.jsビルドでのコード実行を報告。ELLIOも公式ビルドでの再現と、10月26日の攻撃通信の観測を説明しています。これは各研究者の一次報告です。当社が攻撃を再現したわけではなく、実在組織の被害件数・漏えい規模を裏付けるものでもありません。[22][23]
ここでいう「展開(デコード)」処理は、小さく圧縮されたデータを元の内容に戻すことです。更新済みの版が公開されていても、利用中の環境にその更新が適用されているかどうか確認が必要です。国内ではJPCERT/CCも10月26日に注意喚起しています。[34]
誰が、何を確認するか
院長・経営者・事務担当者
- 自院・自社のWebサイト、予約、外部連携、業務サーバについて、管理する会社と担当者を一覧にする。
- 本資料のCVE番号を添え、10章の文例で確認を依頼する。
- 「対応済み」の一言で終えず、10章の文例の1〜4に沿って、影響の有無とその理由、修正の完了日、動いているシステムへの反映、不正アクセスの形跡の確認結果を回答してもらう。
- システム停止や更新日時は、診療・受付・業務への影響を担当者と調整する。
保守事業者・IT担当者
- 実際に稼働するランタイム・ライブラリ・同梱物を特定する。
- 攻撃者が制御できるデータが展開APIへ届く経路を、受信・外部取得の両方で確認する。
- 提供元の修正版を適用し、再起動・再ビルド・再配備を完了する。
- 不審な再起動、取得先、通信、ファイル等を調べ、必要なら侵害対応を別に進める。
電子カルテ、レセコン、予約、検査連携、閉域網端末などは、提供元の動作確認や保守手順が必要です。利用者は管理者への連絡と回答の記録を担当し、実作業は管理者の手順に従ってください。本資料は特定の医療システムが影響を受けると認定した一覧ではありません。
保守事業者への確認を優先する構成:外部に公開したAPI、外部URLから画像や文書を取得する機能、Web収集、Webhook、AIエージェントの情報取得、Brotli展開を有効にしたプロキシ。機能名だけで脆弱とは判定せず、使われるデコーダーと到達経路まで調べます。
問題の正体 — 圧縮ではなく、展開する側のメモリ破損
本章は専門的な内容を含みます。「まず何をすればよいか」だけを知りたい方は、飛ばして構いません。Brotliは、通信量を減らすための圧縮方式
WebサーバはHTML、CSS、JavaScriptなどを圧縮して送り、受信側は展開してから利用します。Brotliはこのために使われる可逆圧縮方式の一つです。HTTPでは通常、送り手が Content-Encoding: br と示し、受け手が「内容はBrotliで圧縮されている」と判断します。BrotliはHTTP/2以外でも、HTTPを介さずファイルやデータを直接展開する場面でも使えます。[18][37]
元のデータを小さくして送る。今回の問題は、この圧縮処理そのものではない。
HTTPの本文、外部APIの応答、ファイル等。HTTP/2の利用は必須条件ではない。
脆弱なCデコーダーに細工されたデータが渡ると、メモリを壊す可能性がある。
CVE番号と通称の関係
CVE-2026-111497が同じ問題を追跡するための識別番号です。「Node2Shell」「HTTP2Shell」は記事・研究で使われる通称です。「HTTP2Shell」という呼称からHTTP/2だけの欠陥と判断したり、Node.jsだけを調べて終えたりしないでください。[1][22][23]
何が壊れ、どう直したか
異常なブロック切替を、恒久的な形式エラーとせず「入力が足りない」と扱うことがあり、ストリーミング処理が内部の8バイトの作業バッファへ入力を追加し続けます。その結果、想定範囲を超える書込みがメモリ破損につながります。これは、そもそものエラー設計として2種類のものを1つのエラーコードで返してしまうという仕様の問題でもあります。修正はエラー状態を区別し、呼出し元まで伝えて処理を止めるものです。[2][3]
技術補足:修正履歴で確認できること
c/dec/decode.c の DecodeBlockTypeAndLength 等の戻り値をエラーコード型へ変更し、BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH(−17)を追加。入力不足と形式異常を分け、通常経路・安全確認付き経路のどちらでも状態を伝播させます。関連する弱点はCWE-787(境界外書込み)とCWE-252(戻り値の未確認)です。修正コミットは 0ed4268a4401abcb4472096340477cf4af7d1a2b。[1][3]
GoogleのCNA記録が示す上流の影響範囲は 1.0.3以上1.0.10未満、1.1.0以上1.1.1未満、1.2.0以上1.2.1未満です。修正済みの枝を含めずに「1.2.1未満は全部未修正」とまとめるのは不正確です。配布元が修正をバックポートした製品も、別に判定します。[1][4][11]
攻撃者のデータが、展開処理まで届くか(攻撃が成立する条件)
本章も前章と同様に専門的な内容ですが、「実際の業務で起き得るシナリオ」は必ずお読みください。脆弱なデコーダーが存在し、攻撃者が制御できるBrotliデータを、そのデコーダーで展開することが基本条件です。アカウント不要でデータが届く構成では認証前に成立し得ますが、認証・ルーティング・展開の順番は各アプリケーションで確認します。[1][8][9]
表は横スクロールで閲覧できます。
| 経路 | 攻撃が届く条件 | 確認対象 |
|---|---|---|
| 外から届くリクエスト本文 | アプリやプロキシが Content-Encoding: br の本文を、脆弱なライブラリで展開する。認証より前に本文パーサーが動けば、認証前に到達する場合がある。 | Express/body-parserのJSON・raw等のパーサー、展開の有効化、認証との順序、EnvoyのBrotli decompressor。[13][9] |
| 外部サイト・APIの応答 | URLプレビュー等が、攻撃者のサーバや侵害された接続先からBrotli応答を受け、自動展開する。公開サイトに攻撃を直接送る必要がない経路。 | Node.jsの fetch()、Bun、PythonのHTTPクライアント、curl/libcurlの展開設定。取得後に本文を読む処理まで確認。[8][14][15][16][18][22] |
| 展開APIの直接呼出し | アップロード、キュー、保存データ等を、brotliDecompress や brotli.decompress 等へ渡す。HTTPを使わなくても成立条件になり得る。 | 入力の出所、実装・版、ファイル処理、バッチ、ワーカー。アプリが直接Brotliをimportしなくても依存先から呼ばれる場合がある。[2][7][8] |
素のNode.js HTTPサーバは、Brotli本文を受け取っただけでは自動展開しません。本文パーサー等の経路が必要です。Pythonも、対象のネイティブデコーダーが入り、実際に利用されるかを確認します。一方で、外部応答の自動展開により、アプリ自身がBrotliを意識せず利用している場合があります。[13][14][15][22]
実際の業務で起き得るシナリオ
外部URLのプレビューを作る、裏側の処理
職員が管理画面に入力したURLから、サーバがタイトルや画像を取得します。その接続先が悪意あるBrotli応答を送り、未修正デコーダーが展開すれば、プレビュー用プロセスが侵害される可能性があります。トップページが別のサーバやキャッシュから正常配信されていても、そのプロセスの安全は分かりません。
外部データ取得・Web収集・AIエージェント
外部ページを読むワーカーやエージェントのHTTP取得処理も、同じ条件で確認対象です。今回の問題は、AIへの指示文ではなく圧縮データの展開段階にあります。AIを使っているだけで対象とはいえず、「AIによる大規模攻撃が進行中」と認定する資料でもありません。しかし、AIの活用が進むなかで、エージェントが利用するツールやライブラリが応答を自動展開するかどうかは、同じ条件で確認の対象になります。
「盗まれる情報はない」場合にも残るリスク
命令実行に成功すると、そのプロセスのアカウントが読める設定・鍵・認証情報や、接続できる他システムが影響を受け得ます。書込みや通信が許されていれば、不正プログラムを残したり、他組織への攻撃の踏み台にしたりするシナリオも考えられます。これらは今回確認した個別の医療機関の被害ではなく、侵害後の条件付きリスクです。OS管理者権限やコンテナ外の支配が自動的に得られるわけではありません。
これらのシナリオは、展開経路とプロセス権限から導く本稿の推論です。プロセス権限の範囲でコードが動くという前提は、公式勧告と研究報告に基づきます。[1][22][23]
実証された(攻撃される可能性がある)ことと、実際の被害は分けて考えてください
「原文で確認」は、その文書・修正・版・記載を確認したという意味です。研究者の攻撃実証を当社が追試したという意味ではありません。
表は横スクロールで閲覧できます。
| 確認段階 | 読めた一次資料の内容 | 限界 |
|---|---|---|
| 停止・異常動作 | 研究用公開リポジトリは複数のNode.js版で停止を記録。OpenSourceMalwareはPython Brotli 1.2.0と1.2.1のASan付きビルド等を比較し、旧版が異常ストリームを受け続け、修正版が−17で拒否する挙動を説明。[24][25] | 異常終了、形式エラーの差、情報漏えい、コード実行は同じ実証ではない。OSMはPython拡張でのメモリ破損の悪用・コード実行までは進めていないと明記。 |
| 情報漏えい | Google CNAとNode.jsは、プロセスメモリの漏えいを起こし得ると評価。[1][2] | 「任意の秘密を確実に外へ取り出せる」という実証とは異なる。初期PoCの限定的な読み出しについては資料の版によって記述が変わり、本稿では再現条件を独立に確定していない。 |
| 研究条件付きのローカルRCE | 公開PoCの固定した初回READMEは、公式Node.js 24.9.0/Linux x86-64でも、内部の同期APIと特定のローカル試験条件を使った実証。ネットワーク到達性は証明しないと明記。[25] | バイナリの改変・弱化と、特殊な内部APIや試験環境の利用は別。「初期PoCはすべて改造版」ともいえない。弱化ビルドだけの成功は、通常配布版での成功と区別する。 |
| 公式の未改変ビルドでのRCE | Impervaは公式Node.js 24.22.0/Linux arm64のコンテナで、外部応答のfetch経路とExpress/body-parserの受信経路による実行を説明。24.22.1では同じ入力を拒否。ELLIOは公式24.22.0/Linux x86-64の複数構成で再現したと報告。[22][23] | Impervaは複数回の試行が必要と明記。ELLIOもビルド依存を説明。全OS・全CPU・全Node.js版で同じ成功率という証明ではない。当社は追試していない。 |
| インターネット上の悪用通信 | ELLIOは10月26日15:08 UTC(27日00:08 JST)のセンサー観測として、特定のNode.jsビルドを狙う攻撃本文を説明。先行する展開経路の探索通信とは区別している。[23] | 観測者による一次報告。実組織での侵入成功数・情報流出・被害規模を当社が確認したものではない。 |
| CISA KEV掲載 | 取得した公式JSONのカタログ 2026.10.26、更新 2026-10-26T22:24:24.6101Z に、本CVEの一致項目なし。取得:2026-10-27T11:51:05+09:00。[26] | 未掲載は「悪用されていない」「急がなくてよい」という意味ではない。カタログは今後更新され得る。 |
一部の個人研究にはRCEに否定的な見解があり、Red Hatの資料にも「信頼できる公開RCE実証を観測していない」との評価が残っています。これは評価対象・時点の違いも含みます。本稿は、Google・Node.jsの勧告と、公式ビルドを対象にした後続の一次研究を併記し、RCEのリスクを否定しません。[27][38][22][23]
深刻度の数字を読むとき
Google CNAの評価はCVSS v4.0、9.2(Critical)。Node.jsはHighと表記しています。Red HatはCVSS v3.1、8.1と評価します。評価主体と尺度(CVSSのバージョン自体)が異なり、数字の差が、それらの深刻度の違いをそのまま示すものではありません。CVSSのスコアそれ自体が、個々の利用環境の侵害確率や、実際の被害発生を示す数値でないことに注意してください。[1][2][27]
製品・環境別の確認対象と修正版
以下は本件の修正を含むと確認できた版・配布元の基準であり、「その版が常に最新」という表ではありません。採用時は提供元の最新のサポート版を確認してください。利用環境への適用済みを当社が確認した表でもありません。
ご利用中のシステムの開発・保守ベンダーに、本章の内容をみてもらい、提供されるサービスにおいてこれらの製品の使用有無、使用しているなら更新が適用されているか。未適用ならいつ頃を目処に適用されるか。これを確認してください。製品別の表は横スクロールで閲覧できます。
| 確認対象 | 成立条件 | 修正版または対処 | 未解決点・注意 | 一次資料 |
|---|---|---|---|---|
| Google Brotli/libbrotli | CNAの範囲は1.0.3–1.0.9、1.1.0、1.2.0。該当Cデコーダーへ不信な入力が渡る。 | 1.0.10/1.1.1/1.2.1。同梱製品は、その製品の修正を適用。 | ライブラリ名が同じでも独自実装へ一律に一般化しない。バックポートは配布元情報で判断。 | [1][4] |
| Node.js 22・24・26 | 修正前ランタイムの node:zlib、fetch等へ攻撃者のデータが届く。 | 22.23.4/24.22.1/26.12.1、または各系列の後続修正版。 | OS配布版は動的リンクの可能性。内蔵Brotliの版表示だけでは修正判定できない。 | [2][31][12][36] |
| サポート終了Node.js | 20・23・25等を利用。対象デコーダーと展開経路を確認。 | 今回の上流修正リリースの対象外。サポート中の系列へ移行する。 | 「EOLだから無関係」ではない。20は2026-04-30、23は2025-06-01、25は2026-06-01に上流サポート終了。 | [2][5] |
PythonのPyPI Brotli | 旧ネイティブ拡張を直接、またはHTTPライブラリ経由で利用。 | 1.2.1をPyPIで確認。利用する仮想環境・コンテナ・配布物ごとに更新。 | CPython本体の更新とは別。古い0.xも安全とはみなせないというOSMの調査は、CNAの正式範囲と区別する。旧版へ戻す回避は勧めない。 | [6][24][1] |
PythonのPyPI brotlicffi | 同梱するGoogle Cデコーダーへデータが届く。PyPy以外の環境でも導入状況を確認。 | 1.2.1.0。開発元履歴はlibbrotli 1.2.1の取込みと本CVE修正を明記。 | 版固定・extras・lockfileを確認。パッケージ削除だけでは次回の依存解決で戻る場合がある。 | [7] |
| Pythonの主要HTTPライブラリ | urllib3/Requests/HTTPX/aiohttpが、利用可能なBrotliバインディングで応答を展開。HTTPXの [brotli] 等の追加依存も確認。 | 使っているBrotli/brotlicffiと配布元を更新。HTTPクライアント自身の更新だけで同梱Cコードまで直るとは限らない。 | Python使用だけで一律に対象としない。自動展開・ストリーム読出し・選択されるバインディングを確認。ライブラリごとの補足は下表。 | [14][15][16][17] |
| Bun | 公式影響範囲は 1.0.21以上1.4.4未満。fetch、node:zlib、Brotli指定のDecompressionStream。 | 1.4.4。bun build --compile の実行ファイルは再ビルド・再配備。 | Bun側の攻撃実証は開発元も未試験と説明。Nodeの成功率を転用しない。 | [8] |
| curl/libcurl | Brotli対応ビルドで、--compressed や CURLOPT_ACCEPT_ENCODING 等により応答を展開する場合。 | 利用するlibbrotliの上流修正版、またはOS・配布元の修正パッケージを適用。静的同梱ならcurl等の配布物も更新。 | curlの版番号だけでは判定不能。旧名 CURLOPT_ENCODING も確認。通常の圧縮なし利用と分ける。 | [18][19][11] |
| Envoy | Brotli decompressorを設定した構成。圧縮配信だけの設定と区別。 | 1.40.0/1.39.3/1.38.6/1.37.8/1.36.12が勧告の修正版。 | 勧告は1.39.2・1.38.5・1.37.7・1.36.11を影響版として列挙。その他の旧版や系列のサポート継続は別確認。 | [9] |
| Istio等、Envoyを組み込む製品 | 対象Istio+EnvoyFilter等でBrotli展開を有効化。 | 公式基準:1.31.2/1.30.6/1.29.9以降の該当系列。より新しい保守版も確認。 | 制御プレーンだけでなく実際のプロキシ更新を確認。1.29は公式にEOLを案内。商用製品は製品提供元の回答が必要。 | [10] |
| Ubuntu 22.04 LTS | OS配布の brotli、libbrotli1、python3-brotli を利用。 | 1.0.9-2ubuntu0.1。USN-8956-1、10月26日公開。 | これより新しい同リリースの公式修正も確認。PyPIや自己同梱ライブラリは別。 | [11][12] |
| Ubuntu 24.04 LTS | 同上。 | 1.1.0-2ubuntu0.1。 | 上流表示1.1.0でも修正バックポートあり。上流番号の比較だけで「未修正」としない。 | [11][12] |
| Ubuntu 26.04 LTS | 同上。 | 1.2.0-3ubuntu0.1。 | Ubuntuの完全なパッケージ版を照合。OS更新は別のコンテナや同梱コピーに自動で届かない。 | [11][12] |
| Ubuntu 26.10 | 同上。 | 1.2.0-4ubuntu0.1。 | USN-8956-1に掲載。LTSではないため、サポート期間を確認する。 | [11][12] |
| Vercel | 管理ランタイム、外部バックエンド、旧Node.js 20プロジェクトを分ける。 | 提供元はWAF保護、管理ランタイムの修正版展開中、再配備で有効になる暫定の応答保護を説明。Node.js 20は22/24へ変更して再配備。 | 「展開中」を「全環境完了」にしない。外部サーバは自分の管理者が更新。WAFは外部応答経路を覆わない。 | [20] |
| Cloudflare | Managed RulesetのBrotli本文ルールとNext.js画像最適化パスのルール。 | 10月25日緊急リリース。公式の初期アクションは両方Log。 | Logは遮断しない。上書き設定、誤検知、正当な画像配信への影響を確認。これだけでアプリの修正完了とはいえない。 | [21] |
| .NET(補足) | BrotliStream/BrotliDecoder、明示的に有効化したASP.NET Core本文展開やHttpClient応答展開。 | 公式勧告:8.0.33/9.0.22/10.0.14、11プレビューは 11.0.0-rc.3.26522.148。 | 既定でHTTP自動展開するとは限らない。.NET Frameworkは対象外との提供元説明。自己完結・NativeAOTは再発行・再配備も必要。 | [28] |
Canonicalは22.04以降のOS配布nodejsがシステムのBrotliを使うため、nodejsパッケージ側を「Not affected」としています。修正はBrotli側で供給されます。一方、20.04(focal)のOS配布nodejsは同梱のBrotliを使うため「Vulnerable」とされています(20.04は通常サポートが終了しており、延長サポートの有無を含めて確認が必要です)。nodejsの欄だけでアプリ全体を「影響なし」としないでください。Node.js公式バイナリや別リポジトリから入れた版には、この判定を流用できませんし、miseやuvで環境を個別に作成(仮想環境)している環境、コンテナで個別に構築している環境などは、それぞれの開発ディレクトリ、コンテナ、仮想環境単位で注意深く更新する必要があると思ってください。[12]
Python:依存パッケージが入っただけで、展開処理が有効になることがある
| ライブラリ | 公式資料で確認した条件 | 確認のポイント |
|---|---|---|
| urllib3 | BrotliまたはbrotlicffiがインストールされていればBrotli対応。urllib3[brotli] でも導入。[14] | 応答のContent-Encodingと decode_content、実際の本文読出し。 |
| Requests | Brotli系ライブラリがあれば br 応答を自動展開すると公式文書に明記。[15] | そのPython環境の依存先。送るヘッダーの変更だけで展開停止とは判断しない。 |
| HTTPX | brotli/brotlicffi が任意依存として利用される。公式ソースは両バインディングを試す。[16] | extra指定だけでなく間接導入も確認。本文の自動デコードとraw読出しを区別。 |
| aiohttp | Brotliバインディング導入で対応し、応答の auto_decompress は既定でTrue。[17] | セッション/個別リクエストの設定。サーバ側の本文展開は別経路として構成確認。 |
「パッケージがある」は調査の入口で、攻撃成功の証明ではありません。「インストール一覧にない」も、別のPython、コンテナ、同梱ネイティブコードまで不在という証明にはなりません。
防御策には、効く範囲と効かない範囲を理解して採用してください
基本は、使われるデコーダーを修正版に替え、稼働中の処理へ反映させることです。暫定設定は、担当者が正常業務への影響と回避経路を確認したうえで採用します。
表は横スクロールで閲覧できます。
| 対策・設定 | 有効な範囲 | 限界・副作用 |
|---|---|---|
| OS更新 | OSが供給する共有libbrotli、OS版Pythonバインディング等の修正。[11] | Node.js公式バイナリ、pipのwheel、独自ビルド、別コンテナへ自動では適用されない。 |
| Node.js/Bun更新 | そのランタイムに入るデコーダーを修正。[2][8] | npmパッケージだけの更新は通常ランタイムを交換しない。直接zlibを使う処理も残る。Bunのコンパイル済み実行ファイルは再ビルドが必要。 |
| PythonのBrotli系更新 | 実際に使う仮想環境のBrotli/brotlicffiを修正。[6][7] | pip本体だけの更新、certifiだけの更新ではデコーダーは直らない。システムPythonとvenvは別に調べる。 |
| WAF・入口でbr本文を拒否 | 対象WAFを通る受信リクエストの展開経路を減らせる。[20][21] | 正当な圧縮本文も拒否し得る。直接アクセスや外部応答・直接APIを覆わない。CloudflareのLogは遮断しない。 |
| Accept-Encodingからbrを外す | 正常な相手がBrotli応答を選ぶ機会を減らす。 | 要求ヘッダーは命令ではない。相手がbrで返し、クライアントがContent-Encodingに従い展開すれば経路は残る。実際の自動展開停止・拒否が必要。[18][39] |
| 自動展開を停止する | Bunはリクエストごとの decompress:false、aiohttpは auto_decompress:false、libcurlは適切なデコード設定を公式に案内。[8][17][19] | 通常の本文が圧縮されたままになり、利用コードが壊れる場合がある。受信後に別APIで展開すれば回避にならない。アプリごとの試験が必要。 |
| HTTP/2を無効化する | 本件の根本対策としての有効性を確認できない。 | Brotli展開はHTTP/1.1や直接APIでも到達し得る。HTTP/2を止めたことだけで対策完了にしない。[1][8][18] |
| 権限・外向き通信・隔離 | 侵害時に読める情報や接続先を制限する防御の層。 | メモリ破損を修正するものではない。非管理者・コンテナ化でもサービス停止や、その権限内の侵害は起こり得る。[27][23] |
VercelとCloudflareの説明を、同じ「保護済み」にまとめない
Vercelの説明 Vercelは入口のWAF保護とは別に、管理Node.jsランタイムの一時保護を案内しています。未修正ランタイムを使う新規デプロイでは、fetch等による外部応答のBrotli処理を止め、既存プロジェクトには再配備を求めています。ランタイム修正版の展開完了は、告知が更新されるまで確認が必要です。[20]
Cloudflareの説明 緊急ルールは受信Brotli本文と /_next/image に一致し、初期値はLog。後者をBlockにすると画像最適化の正当な要求も止まり得ます。既存のルール全体のBlock上書きが作用する場合もあるため、実際の設定を確認します。[21]
更新ファイルを入れたあと、動いている処理まで確かめる
| 更新される単位 | 完了を確認すること |
|---|---|
| 動的リンクした共有ライブラリ | 配布元の修正パッケージへ更新し、古いライブラリを読み込んだままのサービスやワーカーを再起動。共有ライブラリの交換だけで稼働プロセスも新しくなったとは判断しない。 |
| 静的リンク・製品への同梱 | 製品側の修正版、再リンク・再ビルド・新しい実行ファイルへの交換を確認。OSのlibbrotli更新では取り替わらないコピーがある。 |
| Python仮想環境・wheel | 実サービスのPython実行パスと依存先を照合。venv、ジョブ、複数ユーザーの環境、lockfileを更新し、サービスを再起動。 |
| コンテナ・サーバレス | ベースイメージ・ランタイム・依存を更新して再ビルド・再配備。新しいdigestと稼働Pod/タスクを記録。ホストOSの更新だけで既存イメージ内が直るとは考えない。 |
| Bunのcompile/.NETの自己完結・NativeAOT | 更新したランタイム・SDKで再作成し、古い配布物を置換する。共有ランタイムの更新だけで内蔵コピーは替わらない。[8][28] |
この表は、修正提供元の案内とリンク・配布方式から整理した運用上の確認事項です。顧客環境でどの方式が使われているかは別途確認が必要です。[8][11][20][28]
侵入された可能性がある場合、更新だけでは終わらない
修正版は、今後同じ欠陥を使われる入口を塞ぎます。既に残された不正ファイル、盗まれた認証情報、不正な設定やジョブを消すものではありません。不審な外部取得、サービスの異常終了・再起動、想定外の子プロセスや通信等がある場合は、保守事業者・セキュリティ担当者と、ログ保全、調査、隔離・復旧、必要な認証情報の変更を別工程として扱います。
クラッシュやデコーダーのエラーだけで侵害を断定することもできません。版、データの出所、時刻、プロセスの状況を突き合わせてください。調査のためのログ・core dumpには秘密や個人情報が含まれ得るので、取扱いを制限します。[22][23]
技術担当者向け:読み取りだけの確認例
以下は管理を許可された環境で、担当者が使う確認例です。この調査では利用者の本番環境で実行していません。確認場所は「手元の端末」ではなく、実際にサービスを動かすランタイム・仮想環境・コンテナの内部です。出力を外部へ渡すときは、内部パスや構成情報を含む点に注意してください。
Node.js/Bun:その実行ファイルを確認する
node --version
node -p 'JSON.stringify({executable:process.execPath,node:process.versions.node,brotli:process.versions.brotli},null,2)'
bun --version結果の意味:起動した実行ファイルのパスと版が分かります。Bunを使わない環境で最後の行が失敗するのは、Bunの不在を示すだけです。サービスが別のPATH・別バイナリで起動している可能性、再起動の完了、展開経路までは分かりません。
Node.js 24.22.1は修正をcherry-pickしていますが、同梱Brotliのヘッダーの版は1.2.0のままです。Node.jsの配布版、修正コミット、OS配布元の対応を確認します。内蔵ライブラリの表示番号だけで修正判定しないでください。[31]
Python:実サービスのPythonと、各仮想環境を確認する
python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip --version
python -m pip show Brotli brotlicffi urllib3 requests httpx aiohttp結果の意味:そのPython環境のパッケージ版とLocationを確認できます。「Package(s) not found」は、そのPythonから見えないという意味です。別venv・別コンテナ・自己同梱物の不在や、通信データが展開されないことを証明しません。pipが入っていない環境は、配布元・管理者の台帳やパッケージ管理で確認します。調査のために新たにpipを入れる必要はありません。
Ubuntu:完全なパッケージ版を確認する
cat /etc/os-release
dpkg-query -W -f='${Package}\t${Version}\n' brotli libbrotli1 python3-brotli nodejs
apt-cache policy brotli libbrotli1 python3-brotli nodejs結果の意味:インストール版と、ローカルのパッケージ情報が分かります。USN-8956-1とリリースごとに照合します。apt-cacheは情報の最終取得時点に左右され、これ自体は更新を適用しません。パッケージがない場合にエラーが出ることがあります。別配布元のNode.jsやpipのパッケージ、稼働プロセスの読み込み状況は別に確認します。[11][12]
curl:Brotli対応のビルドかを確認する
curl --version結果の意味:curlのビルド情報とBrotli等の対応が分かります。ネットワークアクセスはしません。表示版だけでバックポートの有無を決めず、配布元のパッケージ版を照合します。組込みlibcurlを使う別アプリの構成や、自動展開の有効化までは分かりません。[18]
これらは棚卸しの入口です。SBOMや依存関係、起動定義、配布物、本文パーサー、外部取得処理を合わせて確認してください。第三者へのスキャン、細工した圧縮データによる試験、公開PoCの実行は本資料の手順に含めません。
本章の読み取り確認(ランタイム・パッケージ・OS配布版の版の棚卸し)を一括で行うスクリプトを、当社がGitHubで公開する予定です。公開したら本資料に追記し、お知らせでもご案内します。それまでは上記のコマンドを手で実行してください。
保守事業者への問い合わせ文例と、回答の読み方
〇〇の箇所を自院・自社と製品名に置き換えてお使いください。Web制作会社、業務システムの保守事業者、クラウド提供元へ、それぞれ管理範囲に応じて送ります。本文は、専門用語を使わずに「はい/いいえ」と日付で答えてもらう4問に絞りました。技術的な確認項目は、後ろの「技術担当者向けの確認項目」を添付して、事業者の技術担当者に渡してもらいます。回答が医療機関の側で読めないと、確認したことになりません。
件名:脆弱性 CVE-2026-111497(HTTP2Shell/Node2Shell)の影響確認のお願い
いつもお世話になっております。〇〇の〇〇です。
貴社に管理いただいている〇〇(ホームページ/予約システム/△△)について、
報道されている脆弱性 CVE-2026-111497(通称 HTTP2Shell/Node2Shell)の
影響を確認したく、ご連絡しました。
当方は専門ではありませんので、次の4点について、専門用語を使わずに
「はい/いいえ」と日付でお答えいただけると助かります。
1. 当院(当社)の〇〇は、この問題の影響を受ける仕組みを使っていますか。
「使っていない」の場合は、その理由を一言で教えてください
(例:該当するソフトを使っていない/別の方式で動いている)。
2. 影響を受ける場合、修正は済んでいますか。済んでいれば完了した日を、
まだの場合は完了予定日と、それまでの一時的な対策を教えてください。
3. 「修正済み」の場合、実際に動いているシステムに反映されていますか。
(修正ファイルを入れただけでなく、再起動や入れ替えまで終わっているか)
4. 修正が終わる前に、不正なアクセスを受けた形跡がないか確認していただけますか。
確認の結果と、当方で何かすべきことがあれば教えてください。
技術的な確認事項は、添付の「技術担当者向けの確認項目」を貴社の技術担当者へ
お渡しください。ご回答は上の1〜4の番号に沿って、専門用語を使わずに
いただけると助かります。
よろしくお願いいたします。CVE-2026-111497(Google Brotli デコーダーの境界外書込み)技術確認項目
A. 調査範囲
対象に含めた製品・処理・実行環境・依存ライブラリ(Node.js、Bun、
Python の Brotli/brotlicffi、libbrotli、プロキシ、コンテナや製品同梱コピー)。
B. 攻撃者のデータが Brotli 展開へ届く経路
外部から受信する圧縮本文(認証前の経路を含む)と、外部 URL・API から
取得する圧縮応答の自動展開、展開 API の直接利用、の有無。
C. 適用した修正
製品・パッケージの完全な版番号、根拠となる公式案内、適用日時。
OS のバックポートの場合はそのパッケージ版。
D. 稼働環境への反映
再起動、コンテナの再ビルド、ワーカー・プロキシを含む再配備の完了日時。
E. 暫定策
WAF や展開停止等を使う場合、その対象経路と対象外、業務への副作用、
恒久対応の予定。
F. 侵害の確認
未修正期間について確認したログと範囲、異常の有無、必要な復旧の完了状況。
「影響なし」の場合は、対象コードが無いのか、修正済みなのか、対象コードは
あるがデータが届く経路が無いのか、を区別して根拠を示してください。
参考資料: https://www.jmedic.co.jp/pubdoc/http2shell_report_20261027.html回答の読み方
表は横スクロールで閲覧できます。
| こう返ってきたら | そのままでは足りない理由 | 聞き返すこと |
|---|---|---|
| 「影響ありません」 | 理由が無いと、調べていないのか、調べて無いのか分からない。 | 問1の「理由」を一言で。該当するソフトを使っていないのか、使っているが修正済みなのか。 |
| 「対応済みです」「更新しました」 | 修正ファイルを入れただけで、動いているシステムに反映されていないことがある。 | 問2の完了日と、問3(反映まで終わっているか)が「はい」か。 |
| 「OSを更新しました」「クラウドなので大丈夫です」 | OS やクラウド側の対策だけでは、個別に入れたソフトや裏側の処理が直らない場合がある。 | 添付の技術確認項目を技術担当者に渡したか。その回答(A〜D)があるか。 |
| 「調査中です」 | 「影響なし」ではない。 | 完了予定日、それまでの一時的な対策、次に連絡をもらえる日。 |
| 「問題なく動いています」 | 画面が普段どおりなことと、不正アクセスが無かったことは別。 | 問4(形跡の確認)の結果。 |
| 専門用語だけの回答 | 医療機関の側で判断できない。 | 「問1〜4の番号に沿って、はい/いいえと日付で」と再度依頼する。 |
回答は日時とともに記録してください。修正の適用(問2・3)と、不正アクセスの有無の確認(問4)は別の完了項目として扱います。
時系列 — ソース修正、製品への取込み、公表を分ける
日付は原資料の表記を優先し、明確な時刻が得られた場合だけUTCと日本時間を対応させました。「発見」「報告」「修正コミット」「版の公開」「告知の更新」は別の出来事です。
表は横スクロールで閲覧できます。
| 時点 | 確認した出来事 | 読み方・限界 |
|---|---|---|
| 2026-02-27 | Google Brotliの修正コミット 0ed4268a。committer時刻13:10:54 UTC=22:10:54 JST。[3] | ソースが直った日で、修正版を利用者が入手・適用した日ではない。ここから発見日・報告日を推定しない。 |
| 2026-10-06/13 | EnvoyのGitHub APIでは修正版1.37.8が6日、1.40.0が13日に公開。1.37.8の依存先はBrotliの9月コミットへ変更されている。[29] | 23日のEnvoy勧告より先に修正版が存在。勧告公開日を、すべての製品の取込み日にしない。 |
| 2026-10-15/26 | Istio勧告の表示日付は15日。公式サイトの変更履歴は26日にBrotli CVEの記載を追加したと記録。[10][30] | 15日のページを現在読むだけでは、当初からBrotliの説明があったといえない。 |
| 2026-10-21(原資料日付) | Node.jsが22.23.4/24.22.1/26.12.1を告知。Googleの1.0.10/1.1.1/1.2.1も公開。[2][4] | Google 1.2.1のAPI公開時刻は21日19:27:34 UTC=日本22日04:27:34。日付だけの資料と混在させない。 |
| 2026-10-22 | CVEレコード公開13:35:41 UTC=22:35:41 JST。Impervaが公式ビルドの実証を公表。PyPI Brotli 1.2.1は13:57 UTC以降に公開。[1][22][6] | CVEレコードの datePublic は2月27日であり、レコード作成・製品告知の日とは異なる。 |
| 2026-10-21〜23 | brotlicffi履歴の版日付は21日、PyPIのアップロードは22日16:19 UTC=日本23日01:19。Bun勧告の公開日は23日、修正版は1.4.4。[7][8] | 履歴の日付と、配布レジストリへ届いた日時を区別する。 |
| 2026-10-23 | Envoy勧告と、Python影響を調べたOSMの研究が公開。[9][24] | OSM初期記事の「release notesにCVE記載なし」等は、現在のbrotlicffi開発元履歴とは異なる。現在の原資料を優先する。 |
| 2026-10-25 | Cloudflareの緊急WAFルール。Microsoftの.NET修正。ELLIOが公式x86-64ビルドの実証を公表。[21][28][23] | CloudflareはLogが初期値。RCE実証は研究環境に条件がある。 |
| 2026-10-26 | UbuntuがUSN-8956-1を公開。ELLIOが攻撃通信観測を追記。[11][23] | 古い記事の「Ubuntu未修正」「悪用報告なし」を現在の結論にしない。修正展開完了の個別確認は残る。 |
| 2026-10-27 JST | 本稿の調査・原文照合・HTML作成。CISAの取得カタログに本CVEの一致項目なし。Vercelの告知(公開日の表記なし)は、取得時点で管理ランタイムの修正展開中と説明。[26][20] | 調査時点の記録。今後の勧告更新と実環境への適用状況は継続確認が必要。 |
PHP2Shell・eMudhra証明書問題とは、別の事案です
| 事案 | 原因 | 成立条件・確認対象 | 主な更新対象 |
|---|---|---|---|
| 今回のBrotli CVE-2026-111497 | 展開処理の境界外書込み。 | 攻撃者のBrotliデータが対象デコーダーへ届く。受信・外部応答・直接API。[1] | Brotli、利用ランタイム、バインディング、製品内の同梱コピー。 |
| PHP2Shell CVE-2026-109618/109619 | PHPのメモリ不足時の状態破損や、リクエストをまたぐ不正な状態・参照。 | 対象PHPと、該当するリクエスト処理・実行構成。Brotli展開は必須条件ではない。[33] | PHP本体または配布元のバックポート、サービスの再起動等。 |
| eMudhra証明書問題 | 中間CAの鍵の問題により、証明書の信頼を見直す事案。 | 該当チェーンを受け入れる信頼ストア・検証処理。メモリ破損とは別。[32] | 証明書の信頼情報、OS・ブラウザ・ランタイム・certifi等の個別対応。 |
certifiは信頼するCAの一覧で、pipはPythonパッケージの管理ツールです。証明書対策でそれらを更新しても、Brotli/brotlicffiやNode.js内のデコーダーまで修正されたとは限りません。逆にBrotliの更新も、証明書問題やPHP問題の確認を代行するものではありません。[6][7][32][33]
当社の既存資料:PHP2Shellの解説 / 医療機関向け証明書問題の注意喚起 / 証明書問題の対応状況一覧。[35]
本稿は公開資料を調査した解説です。当社の本番環境や、各医療機関・企業の実構成を調査した安全宣言ではありません。「静的HTMLのサイトだから裏側もすべて無関係」「特定ベンダーの告知に名前がないから影響なし」とは判定していません。管理する事業者の調査結果を確認してください。
当社のWebサイトをはじめ、当社が提供しているサービスの基盤については、現在確認できる範囲ですべて確認し、必要な更新を適用済みです。
当社の保守契約のお客様で、ご利用のシステムについて確認したい点がある方は、お問い合わせフォームからご連絡ください。保守契約のない医療機関からの個別のお問い合わせはお受けしかねますが、公開できる情報は本資料とお知らせで発信します。
出典と、調査・確認の範囲
本文の番号は、以下の資料に対応します。公式CVE・開発元の勧告・リリース情報・OSの追跡情報を優先し、研究の実証と通信観測は当該研究者の原文を読みました。検索結果の抜粋だけを根拠にはしていません。研究者・提供元自身の説明は、当社による独立した追試や実機確認と区別しています。
- Google(CNA)/CVE Program:CVE-2026-111497 公式CVEレコード
CVE公式レコード(JSON) / CVE.orgの識別ページ(表示にJavaScriptが必要)発表・更新:レコード公開2026-10-22、更新2026-10-26(UTC)。datePublicは2026-02-27。 / 取得:2026-10-27 11:51 JST影響範囲、修正版、CWE、Google CNAのCVSS v4.0、謝辞と日付欄を照合。 - Node.js Project:Wednesday, October 21, 2026 Security Releases
Wednesday, October 21, 2026 Security Releases発表・更新:2026-10-21付。 / 取得:2026-10-27 11:50 JST - Google Brotli開発元:Detect and report invalid stream earlier. — 修正コミット0ed4268a
固定コミットの差分発表・更新:2026-02-27。committer 13:10:54 UTC。 / 取得:2026-10-27 11:09 JSTdecode.c、decode.hの変更とエラー伝播を静的に読んだ。 - Google Brotli開発元:Brotli 1.0.10/1.1.1/1.2.1 リリース
v1.0.10 / v1.1.1 / v1.2.1発表・更新:いずれも2026-10-21 UTCに公開。 / 取得:2026-10-27 11:08 JST、2026-10-27 11:09 JST本文とGitHub Releases APIのpublished_atを照合。1.2.1は21日19:27:34 UTC。 - Node.js Release Working Group:Release schedule
公式リリース日程(JSON)発表・更新:随時更新。固定の公開日表記なし。 / 取得:2026-10-27 11:11 JST - Google BrotliのPyPI発行情報:Brotli 1.2.1
PyPI公式配布メタデータ発表・更新:PyPIファイルの初回アップロード2026-10-22 13:57:11 UTC。 / 取得:2026-10-27 11:09 JST - python-hyper/brotlicffi開発元・PyPI:brotlicffi 1.2.1.0 の履歴・依存更新・配布情報
v1.2.1.0のHISTORY.rst / libbrotli更新の固定コミット / PyPI配布メタデータ発表・更新:履歴は2026-10-21付。PyPIアップロードは22日16:19 UTC(日本23日)。 / 取得:2026-10-27 11:09 JST、2026-10-27 11:11 JST、2026-10-27 11:13 JST - Bun開発元(oven-sh):GHSA-663w-cv8g-jj2p: Bundled brotli decoder has an out-of-bounds write
GHSA-663w-cv8g-jj2p: Bundled brotli decoder has an out-of-bounds write発表・更新:2026-10-23公開。 / 取得:2026-10-27 11:09 JST - Envoy開発元:GHSA-3wvj-j6qm-62mr: Out-of-Bounds Write in Brotli Decompressor
GHSA-3wvj-j6qm-62mr: Out-of-Bounds Write in Brotli Decompressor発表・更新:2026-10-23公開。 / 取得:2026-10-27 11:09 JST - Istio開発元:ISTIO-SECURITY-2026-007
ISTIO-SECURITY-2026-007発表・更新:ページ表示2026-10-15。Brotli追記の履歴は出典30参照。 / 取得:2026-10-27 11:10 JST - Canonical:USN-8956-1: Brotli vulnerability
USN-8956-1: Brotli vulnerability発表・更新:2026-10-26公開。 / 取得:2026-10-27 11:50 JST - Canonical:CVE-2026-111497 — Ubuntu CVE tracker
CVE-2026-111497 — Ubuntu CVE tracker発表・更新:2026-10-23公開、10-26更新。 / 取得:2026-10-27 11:50 JSTbrotliとnodejsの状態、nodejsがシステムBrotliを使うという担当者注記を確認。 - Express/body-parser開発元:body-parser公式文書
body-parser公式文書発表・更新:公開・更新日の本文記載なし。随時更新。 / 取得:2026-10-27 11:11 JSTbr対応、inflateの既定値とエラーの説明。 - urllib3開発元:Advanced Usage — Brotli Encoding
Advanced Usage — Brotli Encoding発表・更新:本文に公開日表記なし。stable文書。 / 取得:2026-10-27 11:10 JST - Requests開発元:Quickstart — Binary Response Content
Quickstart — Binary Response Content発表・更新:本文に公開日表記なし。latest文書。 / 取得:2026-10-27 11:10 JST - HTTPX開発元(encode):HTTPXの任意依存とデコーダーソース
公式文書・Dependencies / 公式_decoders.py発表・更新:本文に公開日表記なし。ソースは取得時のmaster。 / 取得:2026-10-27 11:11 JST - aiohttp開発元:Client Quickstart/Client Reference
公式Quickstart / 公式Client Reference発表・更新:本文に公開日表記なし。stable文書。 / 取得:2026-10-27 11:11 JST、2026-10-27 11:13 JST - curl開発元:CURLOPT_ACCEPT_ENCODING
CURLOPT_ACCEPT_ENCODING発表・更新:本文に公開日表記なし。随時更新。 / 取得:2026-10-27 11:11 JSTBrotli対応ビルドの条件、自動展開、要求と異なる符号化応答、旧オプション名を確認。 - curl開発元:curl manpage/CURLOPT_HTTP_CONTENT_DECODING
curl --compressedの公式説明 / libcurlのデコード制御発表・更新:本文に文書全体の公開日表記なし。随時更新。 / 取得:2026-10-27 11:11 JST、2026-10-27 11:13 JST - Vercel Security Team:Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)
Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)発表・更新:本文に公開日の表記なし(Node.jsの10月21日リリースに言及)。 / 取得:2026-10-27 11:50 JSTWAF、管理ランタイムの展開中表記、再配備による応答側保護を提供元自身の説明として扱う。 - Cloudflare:WAF Release - 2026-10-25 - Emergency - Cloudflare Managed Ruleset
WAF Release - 2026-10-25 - Emergency - Cloudflare Managed Ruleset発表・更新:2026-10-25付。 / 取得:2026-10-27 11:50 JST初期値Log、2種類のルールの一致対象、Block上書き・副作用を確認。 - Imperva Threat Research/Red Team:Node2Shell: From Brotli Data to Remote Code Execution
Node2Shell: From Brotli Data to Remote Code Execution発表・更新:公開2026-10-22。HTMLメタデータの更新は同日16:56:12 UTC。 / 取得:2026-10-27 11:10 JST研究者自身の実証説明。公式24.22.0、Linux arm64、試行条件と24.22.1比較。記載の報告者帰属は現在のNode.js公式勧告と差があり、帰属は公式を優先。 - ELLIO Threat Research Lab:Node2Shell: remote code execution on stock Node.js builds
Node2Shell: remote code execution on stock Node.js builds発表・更新:2026-10-25付、10-26追記。HTMLのdateModifiedは26日18:09:06 UTC。 / 取得:2026-10-27 11:50 JST公式x86-64での研究とセンサーでの攻撃通信観測の一次報告。被害組織の侵入成功件数を確認したものではない。 - OpenSourceMalware:Python Packages Vulnerable to Node2Shell
Python Packages Vulnerable to Node2Shell発表・更新:2026-10-23公開(05:31 UTC)。 / 取得:2026-10-27 11:13 JSTPythonでの差分・ASan試験を研究者自身が記述。初期の版・日付・勧告未掲載の説明は、現在の公式履歴や配布メタデータと分けた。 - dimasma0305(公開研究リポジトリ作者):CVE-2026-111497 PoC READMEの初版と取得時点の版
初回READMEの固定コミット / 取得時のREADME発表・更新:初回READMEコミット2026-10-22 13:32:42 UTC。後続更新あり。 / 取得:2026-10-27 11:14 JST、2026-10-27 11:16 JSTREADME・履歴だけを静的に読んだ。攻撃コードや研究用実行環境は起動していない。限定ローカル試験と後続のネットワーク到達性を区別。 - CISA:Known Exploited Vulnerabilities Catalog(公式JSON)
Known Exploited Vulnerabilities Catalog(公式JSON)発表・更新:カタログ更新2026-10-26 22:24:24 UTC。 / 取得:2026-10-27 11:51 JSTCVE識別番号の完全一致で検索。未掲載は悪用の不存在を証明しない。 - Red Hat Product Security:RHSB-2026-015: Out-of-Bounds Write — Google Brotli Decoder
RHSB-2026-015: Out-of-Bounds Write — Google Brotli Decoder発表・更新:取得本文の公開・更新表示2026-10-26。 / 取得:2026-10-27 11:09 JSTCVSS v3.1 8.1、公開RCE実証の信頼性に関する評価はRed Hatの説明として併記。 - Microsoft/.NET開発元:GHSA-p3jp-9v83-76w9: .NET Brotli Decoder Out-of-bounds Write Vulnerability
GHSA-p3jp-9v83-76w9: .NET Brotli Decoder Out-of-bounds Write Vulnerability発表・更新:2026-10-25公開。 / 取得:2026-10-27 11:09 JST - Envoy開発元:修正済みリリースの公開日時とBrotli依存先
v1.37.8 Releases API(published_at) / v1.40.0 Releases API(published_at) / v1.37.7の依存定義 / v1.37.8の依存定義発表・更新:v1.37.8は2026-10-06、v1.40.0は10-13(UTC)。 / 取得:2026-10-27 11:11 JST - Istio開発元:Website Content Changes
Website Content Changes発表・更新:公式履歴の2026-10-26項目を確認。 / 取得:2026-10-27 11:10 JSTBrotli CVEを2026-007と関連リリースへ追加した変更を記録。 - Node.js開発元:v24.22.1のBrotli修正コミットとversion.h
cherry-pickコミット49dff6f / v24.22.1のBrotli版ヘッダー発表・更新:取込みコミット2026-10-20、対象タグv24.22.1。 / 取得:2026-10-27 11:13 JST - certifi開発元:GHSA-6q48-6c7w-9gw2: certifi bundles emSign root CAs with compromised intermediate CA keys
GHSA-6q48-6c7w-9gw2: certifi bundles emSign root CAs with compromised intermediate CA keys発表・更新:2026-10-20公開。 / 取得:2026-10-27 11:11 JST証明書問題との比較に使用。Brotli修正の資料ではない。 - PHP開発元:PHP2Shellの公式セキュリティ勧告2件
CVE-2026-109618: RCE via OOM corruption / CVE-2026-109619: RCE via stale global state発表・更新:2026-10-21公開。 / 取得:2026-10-27 11:11 JST原因と確認・更新対象の違いだけを比較。今回のBrotli事案と混同しない。 - JPCERT/CC:JPCERT-AT-2026-0034: BrotliのC言語実装における境界外書き込みの脆弱性に関する注意喚起
JPCERT-AT-2026-0034: BrotliのC言語実装における境界外書き込みの脆弱性に関する注意喚起発表・更新:2026-10-26公開・更新。 / 取得:2026-10-27 11:08 JST - 株式会社ジェイ・メディック:関連する当社の公開資料3件(別事案)
医療機関向け証明書問題の注意喚起 / 保守事業者向けの対応状況一覧 / PHP2Shellの解説発表・更新:証明書注意喚起10-23、対応一覧10-24、PHP記事初版10-22・改訂10-23。 / 取得:2026-10-27 11:08 JSTいずれも別事案の解説。今回の個別環境の安全認定には利用していない。 - Node.js Project:Node.js v24.22.1 Release
Node.js v24.22.1 Release発表・更新:2026-10-21付。 / 取得:2026-10-27 11:11 JST - IETF/RFC Editor:RFC 7932: Brotli Compressed Data Format
RFC 7932全文発表・更新:2016年7月。 / 取得:2026-10-27 11:14 JST - Qi Deng/ikow(個人研究):brotli2crash — structural unreachabilityという主張
原文README発表・更新:README表示2026-10-22。 / 取得:2026-10-27 11:13 JSTRCEに否定的な評価や研究用ビルドへの言及を読むために使用。この結論を当社の安全判定として採用していない。 - Node.js/Undici開発元:fetchの公式実装: lib/web/fetch/index.js
Undiciの応答デコーダー選択発表・更新:公開・更新日表記なし。取得時のmain。 / 取得:2026-10-27 11:11 JST応答のContent-EncodingからBrotli展開を選ぶ処理と、要求のAccept-Encoding処理が別であることを静的に確認。mainが全利用版と同じと推定してはいない。
調査方法・取得上の制約
公式CVEレコード、開発元の勧告、リリース情報、OSの追跡情報を一次資料として優先し、研究者の実証と通信観測は当該研究者の原文を読みました。リリースの公開日時や修正差分は、公開APIと固定コミットで照合しています。攻撃コードの実行、脆弱性の再現、第三者へのスキャン、本番環境の変更は行っていません。
当社の既存資料3件(証明書問題の注意喚起・対応状況一覧・PHP2Shellの解説)は別事案の関連資料として参照したもので、今回の個別環境の安全認定には使っていません。[35]
更新履歴
| 版・日付 | 内容 |
|---|---|
| v0.2 / 2026-10-27 | 「当社の対応とお願い」に、当社のWebサイトと提供サービスの基盤を現在確認できる範囲で確認・更新済みである旨を追記。 |
| v0.1 / 2026-10-27 | 速報版(初版)。公式ビルドの実証と条件、ELLIOの10月26日追記、CISA取得カタログ、Ubuntuの10月26日修正、Vercelの展開中表記とCloudflareのLog初期値を確認して作成。 |
HTML表示・内部リンク・コピーボタン・スマートフォン幅・印刷用PDFのレイアウトはローカルで確認しています。ブラウザや印刷設定によって改ページ等は変わります。生成AIを調査・下書き・出典照合の補助に使用しました。
確認できていないこと
- 全OS・全CPU・全アプリ構成でのコード実行の成功条件・成功率。特にBunやPythonで、Node.jsと同じRCE結果が出るという追試。
- 公開研究の情報漏えいについて、あらゆる実装で任意の秘密が外部へ読み出せるという実証。
- 実在の医療機関・企業での侵入成功件数、情報流出や永続化の実被害規模。ELLIOのセンサー観測を、実被害の一覧に置き換えていません。
- Vercel管理ランタイムの全対象への修正版ロールアウト完了、Cloudflare利用者ごとの実効ルール、各商用製品の個別対応。
- 調査時点より後のCISA KEV追加、新規修正、勧告の改訂。記載が見つからなかった製品を「影響なし」と認定していません。
「修正版が公開された」「稼働環境に適用した」「侵害がないか調べた」を、別々に確認してください。