Claude CodeのBrotli脆弱性：Nodeの更新だけでは不十分
実際に使っているClaude Codeの実行ファイルと、別途動作するNode.js・Bunを更新し、起動対象とCIイメージを確認します。Claudeのバージョン番号だけを、内蔵デコーダーの修正が確認できた証拠として扱わないための手順です。
目次
Claude CodeのBrotli脆弱性への対応では、実際に使っている実行ファイルを更新して再起動し、ほかのツールが使うNode.jsやBunのプロセスにも個別に修正を適用してください。システムのNode.jsを更新してもClaude Codeの同梱ランタイム（実行環境）は置き換わらず、現在のnpmインストールで配布されるネイティブ実行ファイルも同じです。2026-10-23時点では、Anthropicの2.1.308リリースノートはBrotliの修正を確認できる内容ではなく、このバージョン番号だけでセキュリティ上の確認を完了するには証拠が不足しています。
Webページを取得するエージェントを確認すべき理由
問題になるのは、攻撃者が制御するBrotliデータをプロセスがデコードする経路です。エージェントはドキュメントの取得やWebサイトのスクレイピング中に、そのようなデータを受け取る可能性があります。モデルが読める形のページ内容を受け取るより前に、デコード処理が行われます。
CVE-2026-111497は、GoogleのBrotliデコーダーにある範囲外書き込みの脆弱性です。Googleが作成したCVEレコードでは、細工された圧縮ストリームにより、メモリ内容の漏えい、サービス拒否、任意のコード実行が起こる可能性が説明されています。Googleはこの脆弱性にCVSS 4.0で9.2、深刻度Criticalを付けています。一方、Node.jsのセキュリティ勧告では、Node.jsへの影響をHighと分類しています。
Bunのfetchドキュメントによると、レスポンスの自動展開はデフォルトで有効になっており、Brotliもサポートしています。そのため、Bunのfetch()を使うツールでは、サーバーがContent-Encoding: brを返すと、このデコーダーが呼び出される可能性があります。
この仕組みがあるため、ローカルでコンテンツを取得する各ツールについて、どのランタイムを使って処理しているかを点検する必要があります。ただし、Claude Codeの特定の操作が影響を受けるデコーダーに到達するかどうかは、その実装と取得処理が動く場所によって変わります。ローカルのMCPサーバー、シェルコマンド、リモートのコンテンツ取得サービスでは、それぞれ異なるランタイムが使われることがあります。
受信リクエストを保護するWebアプリケーションファイアウォール（WAF）だけでは、こうした経路をすべてカバーできません。Vercelの勧告は、受信するリクエストと、アプリケーション自身が取得するレスポンスを明確に区別しています。WAFの保護は、取得したレスポンスを処理するランタイムへの修正適用に代わるものではありません。
修正済みと確認できるバージョンはどれか
Node.jsとBunの修正バージョンは、一次情報で裏付けられています。Claude Codeで修正済みと判断できる最低バージョンについては、別途確認が必要です。
2026-10-23時点の状況は次のとおりです。
| 対象 | 修正済みと確認できるバージョン | 更新するもの |
|---|---|---|
| Node.js 22.x | 22.23.4 | そのアプリケーションやツールの起動時に、実際に選択されるNode実行ファイル |
| Node.js 24.x | 24.22.1 | そのアプリケーションやツールの起動時に、実際に選択されるNode実行ファイル |
| Node.js 26.x | 26.12.1 | そのアプリケーションやツールの起動時に、実際に選択されるNode実行ファイル |
| Bunの公式リリース | 1.4.4 | 単体でインストールしたBun、またはBunを内蔵するアプリケーション |
| Claude Code | 確認した公式情報では、最初の修正済みリリースを特定できない | インストール方法に応じてクライアントを更新し、そのビルドにひも付く検証資料を残す |
10月21日のNode.js勧告には、3つの修正リリースが記載されています。バージョンは同じリリース系列内で比較してください。Node 24なら24.22.1またはそれ以降の修正済みリリースが必要で、単に22.23.4より数値が大きければよいわけではありません。Node.js 20にはこの修正が提供されないため、Vercelはサポート対象の系列への移行を案内しています。
Bunについては、一般的なセキュリティ告知だけでなく、実際のリリースの依存関係まで修正をたどれます。Jarred Sumnerのマージ済みプルリクエストはBrotliを1.2.1へ更新したことを示し、Bun 1.4.4のリリースタグにある依存関係ファイルも、その修正済みの上流バージョンを選択しています。公式リリースの公開日は10月22日です。
Claude固有のバージョン情報は、@ryanesheaによる10月22日の投稿に基づきます。投稿者はClaude Code 2.1.296にBun 1.4.3が含まれることを確認したと報告し、2.1.308以降を推奨しています。これはコミュニティからの報告であり、Anthropicが確認したバージョン対応表ではありません。
Anthropicの2.1.308リリースノートにあるのは、バグ修正と信頼性向上という一般的な説明だけです。変更履歴には2.1.309も載っていますが、2.1.308に含まれるBunのバージョンやBrotliの修正を裏付ける情報はありません。速やかに更新しつつ、「クライアント更新済み」と「内蔵デコーダーの修正確認済み」は別の確認結果として記録してください。
実際に使っているClaude Codeを更新する
変更する前に、どのインストールが起動対象になっているかを確認してください。あるコピーを更新しても、ターミナル、エディター、CIランナーが別のコピーを起動し続けていれば、その環境の更新にはなりません。
Bashで次を実行します。
type -a claude
claude --version
claude doctortype -aは、シェルのエイリアス、関数、該当する実行ファイルのパスを表示します。CLIリファレンスでは、claude doctorはインストールと設定の状態を読み取るだけの診断コマンドとして説明されています。Claudeのセッションは開始しません。
作業を保存し、実行ファイルを置き換える前に既存のClaude Codeセッションを終了してください。そのうえで、自分のインストール方法に合う更新手順を選びます。
ネイティブインストール
Bashで次を実行します。
claude update更新処理はautoUpdatesChannelと適用中のバージョン制限に従います。そのため、更新不要と判定されても、公開されている最新リリースではなく、現在の設定で許可された中での最新リリースを指している場合があります。
ネイティブ版のリリースチャネル設定では、latestと、リリースが遅れて配信されるstableを区別します。/config → Auto-update channelを確認してください。個人用の設定は~/.claude/settings.jsonに保存されます。中央管理されている環境では、展開するバージョンと更新ポリシーを整合させて更新する必要があります。
npmによるインストール
npmで管理しているインストールは、Bashで次のように更新します。
npm install -g @anthropic-ai/claude-code@latest現在のnpmインストール手順では、インストール用にNode.js 22以降が必要です。npm経由で提供されるのは、単独のインストーラーと同じネイティブバイナリです。Nodeには上の表にある修正済みリリースを使ってください。ドキュメントは、古いパッケージのバージョン範囲にとどまる可能性があるnpm update -gではなく、上記の明示的なインストールコマンドを推奨しています。
Homebrewでは、インストールしたcaskに合わせてbrew upgrade claude-codeまたはbrew upgrade claude-code@latestを使います。WinGetでは、PowerShellでwinget upgrade Anthropic.ClaudeCodeを実行してください。これらには、それぞれのパッケージマネージャー経由の更新動作があります。
該当する更新が完了したら、新しいターミナルを開きます。Bashで次を確認してください。
hash -r
command -v claude
claude --version
claude doctor表示されるバージョンが、インストールしようとしたリリースと一致していることを確認します。コマンドの参照先も、意図したインストールに対応している必要があります。command -vが関数やエイリアスを示す場合は、先ほどのtype -aの出力から、その定義が何を起動するかを調べてください。
エディター内で動くセッションや、無人で実行しているセッションも個別に再起動します。ターミナルから新しく起動した実行ファイルの確認だけでは、以前から動いているプロセスが置き換わったことまでは証明できません。
更新に失敗する、または古いバージョンが起動する場合
すべてを再インストールするのではなく、観測した症状に対応する原因と対処を選んでください。Anthropicのインストールに関するトラブルシューティングには、複数インストールの競合、更新の失敗、npm経由で必要なバイナリが入らない場合の対処が記載されています。
| 症状 | 確認と対処 | 結果の確認 |
|---|---|---|
更新は完了したが、claude --versionが古いリリースを表示する | type -a claudeとwhich -a claudeで競合するインストールを探します。古いコピーを選んでいるランチャーまたはPATHの項目を修正してください。 | 新しいターミナルを開き、コマンドの参照先とバージョンを再確認します。 |
起動対象を独自に選ぶ~/.local/bin/claudeランチャーが、古いリリースを起動し続ける | ランチャーが起動する対象を調べます。ネイティブ版の更新処理は独自ランチャーを残すため、展開時にランチャーが選ぶバージョンも更新します。 | ダウンロードした新しいバイナリだけでなく、そのランチャー経由でバージョンを確認します。 |
Error: claude native binary not installed. | npmのオプション依存関係が省略されていないか、postinstallスクリプトがスキップされていないかを確認します。必要なインストール処理を有効に戻し、パッケージを再インストールします。 | claude --versionが正常に実行できることを確認します。 |
Auto-update failed · Run claude doctor | claude doctorを実行し、報告されたインストールまたはダウンロードの失敗に対応するガイドの項目を確認します。 | 適切な更新処理を再実行し、新しいプロセスで目的のバージョンを確認します。 |
更新処理が「許可された新しいバージョンはない」と判断した場合は、完了とみなす前にリリースチャネルと管理側が設けたバージョン上限を確認してください。インストールの動作確認で分かるのはプログラムが起動することです。Brotli脆弱性の有無を検査しているわけではありません。
Claude Codeに内蔵されたBunのバージョンは確認できるか
文書化されているClaudeのコマンドで確認できるのは、アプリケーションのバージョンとインストールの状態です。確認したCLIドキュメントには、内蔵Bunのバージョンを表示するための、サポート対象のコマンドは記載されていません。
bun --versionを実行して分かるのは、PATH上にある別のBun実行ファイルのバージョンです。同様に、システムのNodeプロセスにバージョンを問い合わせても、そのNodeプロセスの情報が得られるだけです。どちらも、Claude Codeに組み込まれたランタイムのバージョンを特定するものではありません。
Bunは単体の実行ファイルで使うBUN_BE_BUN=1を文書化しています。ただし、Claude Codeの診断方法としては文書化されておらず、kk-matsによるClaude Codeのissue #24575では、バージョンによって動作が変わると報告されています。Claudeのインストールに対して、確実に使えるセキュリティ判定手段だと決めつけないでください。
公開されているClaude Code 2.1.308のマニフェストには、リリース、ビルド、プラットフォーム、チェックサムの情報がありますが、Bunコンポーネントのバージョンはありません。Anthropicの署名付きマニフェストの検証手順を使えば、バイナリがベンダーのリリースと一致することは確認できます。デコーダーの修正状況を確定するには、その配布物にひも付くコンポーネント情報やパッチの証拠が別途必要です。
チームのセキュリティレビューでは、Claudeのバージョン、プラットフォーム、インストール元、実際に使う実行ファイル、ファイルを識別するためのチェックサムを記録してください。内蔵ランタイムの修正を正式に確認する必要がある場合は、そのリリースとプラットフォームを指定してベンダーに確認します。証拠が得られるまでは「クライアント更新済み、内蔵ランタイムの修正状況は未確認」と記録し、リスク評価で必要と判断した場合は、影響を受ける処理による信頼できないコンテンツの無人取得を一時停止してください。
チームの端末・コンテナ・CIランナーを確認する
バージョンの棚卸しは、エージェントの処理が実際に動くすべての実行環境の中で行ってください。開発者のノートPCで得た結果だけでは、コンテナ、自社管理のサーバーなどで動くセルフホスト型ランナーの実行アカウント、個別に展開されたMCPサーバーの状態は分かりません。
実行ユーザーとPATHの設定が違う環境では、どのファイルが選ばれるかも確認し直す必要があります。既存の端末管理ジョブやCIのステップで、次のBashコードを使えます。
set -u
uname -srm
id -un
for tool in claude node bun; do
if executable=$(type -P "$tool"); then
printf '%s\t%s\t' "$tool" "$executable"
"$executable" --version || exit 1
else
printf '%s\tNOT_FOUND\n' "$tool"
fi
done出力には、OS、実行ユーザー、各ツールについてPATHから選ばれた実行ファイルとそのバージョンが表示されます。NOT_FOUNDは棚卸しの結果です。ネイティブ版のClaudeを使うために、独立したBunコマンドが存在する必要はありません。
このスクリプトは、セキュリティ上の合格を表すPASSを出力しません。Nodeと単体Bunの結果は修正済みと確認できるバージョンと比較し、Claudeの配布物に関する証拠は別に評価してください。Bashのtype -Pが探すのは実行ファイルのパスです。シェルのラッパーや、設定で明示的に指定された実行ファイルは、別途確認する必要があります。
チームで更新を展開する際は、次の手順で進めます。
- 実行環境を確認する。 通常のPATH設定を適用した後、最終的に使うコンテナやランナー環境の中で、サービスの実行ユーザーとして上のコードを実行します。MCPサーバー、SDKを使用するプロセス、エディター連携が使う実行ファイルのパスは、それぞれ別に確認してください。
- ビルドまたはデプロイの定義を更新する。 影響を受けるNode/BunのバージョンとClaudeのインストールを更新します。古いインストールレイヤーのキャッシュによって以前の実行ファイルが残らないように、イメージを再ビルドしてください。
- 稼働中の処理を置き換える。 コンテナを作り直し、旧インストールを使い続けているランナーやサービスを再起動します。新しく起動した環境で棚卸しをやり直し、結果とともに、イメージの識別に使うdigest（ダイジェスト）も保存してください。
- 通常の作業を1つ確認する。 更新後の環境でも、チームが必要とするツールの処理を完了できるか確認します。これは互換性の確認結果として記録し、デコーダーの修正を示す証拠とは分けて扱います。
Bun自身で管理している単体インストールの場合、リリースに記載された更新コマンドは次のとおりです。Bashで実行します。
bun upgrade
bun --versionこれで更新されるのは、そのBunインストールです。Bunを内蔵するアプリケーションには、更新された実行ファイルやパッケージなど、アプリケーション本体の更新版が必要です。単体のBunを更新するだけでは、アプリケーション内のBunは置き換わりません。
カスタムAPIゲートウェイでもクライアントの更新は必要
カスタムのANTHROPIC_BASE_URLが変えるのはAPIの接続先であり、Claude Codeのローカル実行ファイルは置き換えません。ゲートウェイ経由のリクエストが成功していても、クライアントを最新の状態に保ってください。
Claude Codeの公式変更履歴には、ゲートウェイの互換性に関する2つの別個の修正が記載されています。
2.1.305： Vertex、Bedrock、その他のエンドポイントやゲートウェイがツール検索を拒否した際に、すべてのリクエストが失敗することがあった2.1.304のリグレッション、つまり変更によって以前の動作が壊れる不具合を修正しています。ToolSearchを許可しない設定や、--toolsに含めない設定も対象です。クライアントはツール検索を使わずに再試行するようになりました。2.1.307： カスタムのANTHROPIC_BASE_URLを使うゲートウェイとFoundryで、効果のないprompt-caching-scopeベータヘッダーを送信しないようにしています。
更新後は、以前失敗していた小さな処理をゲートウェイ経由で再実行してください。まだ失敗する場合は、更新したクライアントでエンドポイントのレスポンスと設定を調べます。Brotliの更新に関する情報だけで、すべてのゲートウェイエラーを説明できるわけではありません。リクエストの成功が確認するのは、その処理の互換性です。内蔵ランタイムに修正が適用されているかどうかは、引き続き別の確認として扱います。
