Node.jsのBrotli脆弱性とは？2026年10月の修正と開発者がやること

2026年10月21日、Node.jsは10件の脆弱性を直した修正版を公開しました。最も重いのは、圧縮されたデータを元に戻す処理の不具合です。同じ修正版では、認証局のトラブルへの対応も行われました。

本記事では、Node.jsの公式発表、圧縮形式Brotli（ブロトリー）の開発元、ブラウザーの開発元が出した情報をもとに、10件の脆弱性の仕組みと、認証局との関係を1つずつ解説します。公表から修正までの流れ、開発者や運営者が何をすればよいかも、あわせて整理しました。

【メモ】

同じ10月21日には、PHPの重大な脆弱性（PHP2Shell）も公表されました。中身とサイト運営者がやることは、PHP2Shellとは？で解説しています。

Node.jsのBrotli脆弱性とは

Node.jsはJavaScriptを、ブラウザーの外で動かすための実行環境です。Webサイトのサーバー、Next.jsやNuxtで作ったサイト、開発用のツールなど、幅広い場面で使われています。今回の修正の要点を表にまとめました。

項目	内容
公開日	2026年10月21日（日本時間19時38分）
修正した脆弱性	10件（深刻度「高」4件、「中」3件、「低」3件）
最も重いもの	CVE-2026-111497。Brotliの展開処理の不具合で、遠隔コード実行のおそれがある
深刻度（CVE-2026-111497）	Node.jsの評価は「高」。CVE番号を登録したGoogleの評価は、CVSS v4.0で10点満点中9.2
あわせて直したこと	秘密鍵が漏れた認証局eMudhraの証明書を、信頼しないようにした
修正版	Node.js 26.12.1、24.22.1、22.23.4
修正版が出ない版	20系や25系など、サポートが終わった版

遠隔コード実行とは、インターネットの向こうにいる攻撃者が、他人のサーバーの上で自分の用意したプログラムを動かせてしまうことで、PHP2Shellと同じ種類の被害です。報告者はOpenAIのCodex Securityで、OpenAIはPHP2Shellを報告した企業の1社でもあります。

【メモ】

遠隔コード実行がどんな弱点から起こり、なぜ特に重く扱われるのか、どう備えればよいかは、遠隔コード実行（RCE）とは？で解説しています。

点数の9.2は、PHP2Shellの2件と同じでした。ただしNode.jsは、Brotliのデータを展開する処理がなければ攻撃が届かないことなどから、自分の評価を「高」にとどめています。PHP2Shellは、PHPで動くページを開かれるだけで攻撃が届くため、ほぼすべてのサイトが危険にさらされました。この攻撃が届く範囲の違いが、騒ぎの大きさの違いにつながったと考えられます。

PHP2Shellのような正式な呼び名は、この不具合にはまだ付いていない状態です。セキュリティ企業のImpervaなどは「Node2Shell」と呼んでいますが、Node.jsやVercelの発表には、この名前は出てきません。本記事では、「Brotliの不具合」と呼びます。

Node.jsのアプリがデータを処理する流れ

10件の脆弱性は、Node.jsのアプリがデータを受け取ってから返すまでの、いろいろな段階に散らばっています。仕組みを知るために、まずNode.jsのアプリがどのようにデータを処理しているかを見ておきましょう。

Webサイトのサーバーとして動くNode.jsのアプリは、利用者からリクエストを受け取ると、必要に応じて外部のサーバーからデータを取り寄せ、ページを組み立てて返します。下の図は、その流れと、それぞれの段階に関わる脆弱性の番号を示したものです。

受け取ったデータが圧縮されていれば、使う前に元の形へ展開しなければなりません。外部のサーバーへ接続するときは、まず相手のドメイン名からIPアドレスを調べ（DNS）、接続したあとに、相手が本物かを証明書で確かめます。

HTTPSの証明書で確かめることは2つです。証明書が信頼できる認証局の発行したものかと、証明書に書かれた名前が接続先と一致するかを見ます。証明書には、ドメイン名を書く欄とIPアドレスを書く欄があり、IPアドレスで接続するなら、本来はIPアドレスの欄と比べなければなりません。

【メモ】

ブラウザーとサーバーがどのように役割を分けているかは、クライアントサーバーシステムとは？で解説しています。

10件のうち6件は、この流れの中のどこかに不備がありました。残りの4件は、通信ではなく、乱数を作る機能、ZIPファイルを読む機能、ファイルの読み書きを制限する機能の不具合です。ここからは、最も重いCVE-2026-111497から、1件ずつ見ていきます。証明書の確認に関わる3件は、続けて並べました。

CVE-2026-111497の脆弱性の仕組み

CVE-2026-111497は、Brotliで圧縮されたデータを展開する処理の不具合で、10件の中で最も重いものです。展開の仕組みと、攻撃のデータが届く場面に分けて説明します。

範囲の外へ書き込んでしまう仕組み

Brotliは、Googleが開発したデータの圧縮形式です。Webでは、サーバーとブラウザーがやりとりするデータを小さくするのに使われ、データがBrotliで圧縮されていることを、HTTPの「Content-Encoding: br」という見出しで知らせます。

今回の不具合は、展開の途中で、用意したメモリーの範囲の外へデータを書き込んでしまうというものでした。下の図は、その流れを示しています。

Node.jsの説明によると、形式として成り立たないデータが来たとき、展開の処理は「続きのデータが足りない」と受け取っていました。本来ならその時点で、誤りとして展開を止めなければなりません。展開の処理は止まらずにデータを足し続け、8バイトしかない作業用の領域からあふれてしまったのです。

攻撃者が細工したデータを展開させると、隣にある別のデータを書き換えられます。その結果、Node.jsが止まったり、メモリーの中身が漏れたりするほか、うまくいけば好きな命令を動かされかねません。

Brotliのデータが届く場面

Node.jsは、頼まれないかぎりBrotliのデータを展開しません。攻撃が届くのは、プログラムやライブラリが、攻撃者の用意したBrotliのデータを展開するときに限られます。主な場面は、次の3つです。

場面	例
受け取るリクエストの本文	利用者がBrotliで圧縮したデータを送り、アプリやライブラリが展開する
取得した応答	アプリが fetch で他のサーバーからデータを取得し、その応答がBrotliで圧縮されている
自分で書いた展開の処理	アップロードされたファイルを、プログラムの中で展開する

気づきにくいのは、2つ目の場面です。1つ目と2つ目で、データがどこから届くかを図に描きました。

自分のサーバーが外へデータを取りに行ったときも、相手のサーバーが細工した応答を返せば、展開の処理で攻撃が成立しかねません。利用者が入力したURLのページを取得するような機能は、特に狙われやすい作りといえます。攻撃らしい通信を遮断する仕組み（WAF）は、外から届くリクエストを調べるものなので、この応答は通り抜けてしまうのです。

【メモ】

Brotliの開発元も、日本時間の10月22日4時27分にBrotli 1.2.1、1.1.1、1.0.10を公開し、同じ不具合を直しました。Node.js以外にもBrotliを組み込んだソフトはあるため、それぞれの提供元の情報も確かめてください。

CVE-2026-105483の脆弱性の仕組み

CVE-2026-105483は、全角の数字で書いたIPアドレスで、証明書の名前の確認をすり抜けられる不具合です。深刻度は「高」で、26系と24系が影響を受けます。

接続先を １２７.0.0.1 のように全角の数字で書くと、実際の接続は普通のIPアドレスの 127.0.0.1 へ行きます。ところが、証明書を確かめる処理はこれをIPアドレスと見なさず、証明書のドメイン名の欄と比べていました。そのため、ドメイン名の欄に 127.0.0.1 と書かれた証明書が、IPアドレスの欄に書かれていなくても確認を通ってしまうのです。以前の修正のあとで、直したはずの確認が再び甘くなっていました。

CVE-2026-106069の脆弱性の仕組み

CVE-2026-106069は、先頭に0を付けたIPアドレスで、接続した相手とは別のIPアドレス向けの証明書が通ってしまう不具合です。深刻度は「高」で、26系、24系、22系が影響を受けます。

0127.0.0.1 のように先頭に0を付けると、証明書を確かめる処理は、URLの決まりに従って8進数として読み、87.0.0.1 と解釈します。一方で、実際に接続するときに名前を読むmacOSなどのOSは、10進数として 127.0.0.1 に接続していました。87.0.0.1 向けに発行された証明書を持つサーバーが、127.0.0.1 の相手として認められてしまうわけです。

CVE-2026-106072の脆弱性の仕組み

CVE-2026-106072は、IPアドレスの変則の書き方で、ドメイン名の欄だけを持つ証明書が通ってしまう不具合です。深刻度は「中」で、26系、24系、22系が影響を受けます。

IPアドレスは、0177.0.0.1、0x7f.0.0.1、2130706433、127.1 のようにも書けます。証明書を確かめる処理は、これらを 127.0.0.1 に直したうえで、IPアドレスの欄ではなくドメイン名の欄と比べていました。Linuxで使われるglibcなどは、こうした書き方を受け付けて 127.0.0.1 に接続するのです。

ただし、悪用するには、ドメイン名の欄に数字を書いた証明書を、信頼された認証局から発行してもらう必要があります。深刻度が「中」にとどまっているのは、この条件があるためでしょう。

3件の証明書の不具合は、どれも攻撃者がこうした書き方の接続先をアプリに使わせる必要があり、ブラウザーでサイトを開くだけで起こるものではありません。それでも証明書の確認が甘ければ、偽のサーバーを本物と思い込んで通信してしまうおそれがあります。

CVE-2026-105482の脆弱性の仕組み

CVE-2026-105482は、ドメイン名からIPアドレスを調べる dns.resolve が、名前を途中で切ってしまう不具合です。深刻度は「高」で、26系、24系、22系が影響を受けます。

名前の途中にNUL文字（文字列の終わりを示す特別な文字）を入れると、dns.resolve はそこから後ろを無視していました。アプリが「trusted.exampleの名前だけに接続する」という許可リストで確かめても、dns.resolve は攻撃者のattacker.exampleを調べて、その結果を返します。アプリは、確かめた名前とは別の相手の情報を使ってしまうのです。以前の修正では dns.lookup などだけが直されていて、今回、残っていた dns.resolve と dns.reverse も直りました。

CVE-2026-105481の脆弱性の仕組み

CVE-2026-105481は、接続を使い回すとき、頼んでいない応答を、あとから送ったリクエストの応答として受け取ってしまう不具合です。深刻度は「中」で、26系、24系、22系が影響を受けます。

Node.jsのアプリが他のサーバーと通信するときは、速さのために、一度つないだ接続を待機させて使い回します（keep-alive）。待機中に相手から頼んでいないデータが届いたら、その接続は捨てる決まりです。ところが、アプリが別の処理で忙しく、届いたデータをまだ読んでいない間は、この確認が働いていませんでした。

その状態で新しいリクエストを送ると、先に届いていたデータを、そのリクエストへの応答として受け取ってしまうわけです。相手のサーバーが偽の応答を前もって送り込めば、アプリに偽の情報を信じ込ませられるおそれがあります。

CVE-2026-106074の脆弱性の仕組み

CVE-2026-106074は、起動を速くするために作るスナップショットに、乱数の蓄えが保存されてしまう不具合です。深刻度は「中」で、26系、24系、22系が影響を受けます。

Node.jsには、起動したあとの状態を保存しておき、次からはその状態から始める「スナップショット」の仕組みがあり、1つのファイルで配る単一実行ファイル（SEA）でも使えます。スナップショットを作る途中で crypto.randomUUID() や crypto.randomInt() を呼ぶと、あらかじめ作っておいた乱数の蓄えまで保存されていました。

そのスナップショットから起動したプロセスは、どれも同じ乱数の並びから使い始めます。重ならないはずのID（UUID）が別々のプロセスで重なったり、1つのプロセスが出した値から、ほかのプロセスの値を予測されたりしかねません。蓄えが入れ替わるまでの、最大127個のUUIDと約1,000個の乱数が対象です。

CVE-2026-106070の脆弱性の仕組み

CVE-2026-106070は、ZIPファイルを読む zlib.ZipFile が、確認に失敗したあとも、攻撃者が決めた中身を返してしまう不具合です。深刻度は「低」で、26系だけが影響を受けます。

ZIPファイルには、中身の一覧と、ファイルごとの見出しがあります。2つが一致しないZIPを読ませると、Node.jsは確認に失敗しても、途中まで読んだ見出しを残したままにしていました。そのあと中身を読むと、ファイルの先頭にある、攻撃者が決めたバイト列を返していたのです。中身が正しいかを調べる値（CRC-32）も、攻撃者が一覧の側で合わせられるため、確認を通ってしまいました。

Node.jsでZIPの中身を調べて「安全」と判定する仕組みを作っていると、実際にほかのソフトで取り出される中身とは別のものを調べてしまうおそれがあります。

CVE-2026-106071の脆弱性の仕組み

CVE-2026-106071は、ファイルの読み書きを制限するパーミッションモデルで、許可していないファイルまで許可してしまう不具合です。深刻度は「低」で、26系だけが影響を受けます。

Node.jsを --permission を付けて起動すると、読み書きできるファイルを --allow-fs-read などで限れます。ワイルドカード（*）を使って /etc/passwd.* だけを許可したとき、名前の短い /etc/passwd まで読めてしまっていました。許可の一覧の調べ方が、途中で比べるのをやめていたためです。

CVE-2026-106073の脆弱性の仕組み

CVE-2026-106073も、パーミッションモデルの不具合です。深刻度は「低」で、26系、24系、22系が影響を受けます。

ファイルの本当の場所を調べる fs.realpathSync では、読み取りの許可を確かめていませんでした。読める場所を限っていても、この関数を使えば、許可していない場所にファイルがあるかや、リンクの行き先を調べられます。似た関数の fs.realpathSync.native は以前の修正で直っていて、今回、残っていた方も直りました。

10件のほかに、Node.jsに組み込まれたOpenSSL、c-ares、Undiciなどのライブラリも更新されています。

認証局eMudhraの問題との関係

今回の修正版には、10件の脆弱性とは別に、インドの認証局eMudhraのトラブルへの対応も入りました。何が起き、なぜNode.jsの修正版が必要だったのかを説明します。

中間認証局の秘密鍵を計算で求められた

TLS証明書は、認証局が「このサイトは本物です」と署名して発行するものです。認証局は、大もとのルート認証局の下に中間認証局を置き、ふだんの証明書は中間認証局が署名します。この関係を、図に描きました。

Mozillaの記録によると、eMudhraの中間認証局8つ（TLS用6つ、プログラムの署名用2つ）は、秘密鍵が256未満の小さな整数でした。署名に使う秘密鍵は、本来なら推測できない大きな数でなければなりません。公開されている証明書から、だれでも秘密鍵を計算で求められる状態だったわけです。

秘密鍵を手に入れた人は、中間認証局になりすまして、どのサイト名の証明書でも作れます。その偽の証明書を使えば、銀行などのサイトになりすました通信も、正しい証明書の通信に見せかけられるのです。eMudhraは、2025年4月30日に鍵を作った作業で、手順のスクリプトの不備から弱い鍵が別に作られ、名前が似ていたため誤って使ったと説明しています。

10月17日に研究者がブラウザーの開発元とeMudhraに報告し、eMudhraは18日に8つの中間認証局を失効させました。悪用されたかどうかは、分かっていません。その後、eMudhraは10月22日（現地時間）に、世界向けのSSL/TLS証明書の事業から撤退すると発表しています。

Node.jsの修正版が必要だった理由

ブラウザーは、問題の証明書をそれぞれの更新の仕組みで拒否するようになりました。一方、Node.jsは修正版を出さないかぎり、同じ証明書を受け入れてしまいます。違いを比べました。

Node.jsは、Firefoxと同じMozillaのルート証明書の一覧を、本体に組み込んで使う作りです。ブラウザーには、信頼をやめた証明書の一覧を、本体の更新を待たずに届ける仕組みがあります。MozillaのOneCRLやChromeのCRLSetがそれです。Node.jsには同じ仕組みがなく、初期設定では失効の確認もしません。中間認証局の鍵が漏れても、信頼するルートまでたどれるかぎり、証明書は確認を通ってしまうのです。

そこでNode.jsは、修正版で2つの手を打ちました。まず、問題の8つの中間認証局の公開鍵を遮断の一覧として本体に組み込み、それを通る証明書を失効したものとして拒否するようにしています。さらに、ルート証明書の一覧を新しくし、上位のemSign ECC Root CA - G3などを外しました。Node.jsの発表では依存ライブラリの更新として1行で書かれているだけですが、HTTPSで外部と通信するアプリにとっては見過ごせない修正です。

【ポイント】

同じ問題は、ルート証明書の一覧を自分で持つソフトすべてに関わります。報告者のまとめでは、Python、Go、Deno、Bun、Electron、curlなども修正版を出しました。Electronで作ったアプリは、アプリ自体が修正済みのElectronに上がるまで直りません。

公表から修正までの流れ

Node.jsは1週間前に予告し、予定どおりの日に修正版を公開しました。公開までの出来事と、各社の対応を順に見ていきます。

予告から修正版の公開までの出来事

PHPが予定を1日早めたのに対し、Node.jsは予告どおりに修正版を出しています。主な出来事を、日本時間の順に並べました。

日本時間	出来事
10月14日	Node.jsが、21日に22系、24系、26系の修正版を出すと予告する。中身は「最も重いものは深刻度『高』」とだけ書いた
10月17日	研究者が、eMudhraの中間認証局の秘密鍵を求められると、ブラウザーの開発元とeMudhraに報告する
10月18日	MozillaがFirefoxで8つの中間認証局の信頼を外す。eMudhraも8つを失効させる
10月21日 1時43分	Node.jsに、問題の公開鍵を拒否する変更が入る
10月21日 19時38分	Node.jsが修正版の26.12.1、24.22.1、22.23.4を公開する
10月21日	Vercelが、自社のネットワークを通るリクエストに、WAFの遮断ルールを無料で当てる
10月22日 4時27分	Brotliの開発元が、修正版の1.2.1、1.1.1、1.0.10を公開する
10月22日	Impervaが、公式の版のNode.jsで命令の実行を確かめたと公表する
10月22日 22時35分	CVE-2026-111497の公式の記録が公開される。登録したGoogleは、深刻度をCVSS v4.0で9.2とした
10月23日	Node.jsの発表に、10件それぞれの説明が書き足される

予告の時点では、どの機能の不具合かは伏せられていました。修正版が出る前に中身が漏れた様子は、記録からは見つかっていません。

緊急メンテナンスに入った主なサービス

PHP2Shellとは違い、この不具合を理由に緊急メンテナンスに入ったと告知した大手のサービスは、10月24日の時点で見つかりませんでした。代わりに、Node.jsを実行する環境を提供する事業者や、Brotliを組み込んだソフトの提供元が、次のように対応しています。

提供元	対応
Vercel	21日に、自社のネットワークを通るリクエストへWAFの遮断ルールを無料で当てた。自社が管理する実行環境の22系と24系に、修正版を順に当てている
Imperva	自社のWAFに、この不具合を狙う通信の遮断ルールを足した
Brotliの開発元	1.2.1、1.1.1、1.0.10を公開した
Bun	1.4.4で修正した

Vercelは、利用者がNode.jsの版の設定を変える必要はないと案内しています。ただし、サポートが終わった20系を使うプロジェクトには修正版が当たらないため、22系か24系に切り替えて、もう一度デプロイしなければなりません。

修正版の公開前後で、危険はどう変わったか

修正版の公開前は、どの機能の不具合かが伏せられていました。公開を境に修正の中身が読めるようになり、翌日には公式の版で攻撃が成り立つと確かめられています。最も危ないのは、修正版が公開されてから、自分の環境を修正版に上げるまでの間です。

公開前の予告には、22系、24系、26系に深刻度「高」の修正が入ることしか書かれていませんでした。PHP2ShellのようにCVE番号や実演動画が先に出回った様子は見つからず、公開前の攻撃の試みも報告されていません。ただし、認証局eMudhraの弱い鍵は、2025年4月に作られてから報告までの間、だれでも計算できる状態でした。公表前の不具合も、見つける力のある人には狙える状態だったわけです。

修正版が公開されたあとは、Node.jsとBrotliのどこを直したかを、だれでも読めます。直した場所が分かれば不備の場所も分かるので、攻撃の方法を作りやすくなるのです。

実際に、公開の翌日の10月22日には、攻撃の実演コードが公開されました。このコードは、守りの仕組みを弱めたテスト用の版でしか命令の実行まで行かなかったと報じられ、すぐには悪用されにくいという見方も出ていたのです。ところが同じ日に、セキュリティ企業のImpervaが、Node.jsの公式の24.22.0（Linux、arm64）で命令の実行を確かめたと公表しています。試したのは、fetch で受け取った応答と、Webアプリのフレームワーク「Express 5」が受け取ったリクエストの本文の2つの場面です。Impervaは、何度か試してようやく成功したとし、攻撃のコードは公開していません。修正版の24.22.1では、同じデータを受け付けなかったそうです。

10月23日の時点で、実際の攻撃は報告されていません。それでも、公式の版で成り立つと分かった以上、テスト用の版でしか成功しないという理由で更新を後回しにするのは危険です。

PHP2Shellでは、レンタルサーバーの事業者が利用者の代わりに修正を当て、危ない期間を短くしました。Node.jsは開発者が自分で入れて動かす例が多いため、危ない期間をどれだけ短くできるかは、一人ひとりが修正版に上げる早さにかかっています。

開発者・運営者がやること

Node.jsの修正を当てるのは、多くの場合、Node.jsを動かしている本人です。自分の環境の版を確かめる方法、すぐに上げられないときの対策、Node.js以外に確かめておきたいものを順に説明します。

Node.jsが動いている場所ごとの対応

Node.jsがどこで動いているかによって、修正を当てる人と、やることが変わります。

Node.jsが動いている場所	修正を当てる人	やること
自分で管理するサーバー（VPS、クラウドの仮想サーバー）	自分	修正版に上げ、アプリを再起動する
コンテナ	自分	修正済みのNode.jsのイメージで作り直す
Vercelなどの管理された実行環境	事業者	事業者の案内を確かめる
手元のパソコン、CI	自分	開発や自動テストで使うNode.jsも上げる

使っているNode.jsのバージョンは、ターミナルで次のコマンドを実行すると確かめられます。

node -v

表示された番号から、次の順に判断してください。

表示が v22.23.4、v24.22.1、v26.12.1 か、それより新しければ修正済みです。20系以前を使っている場合は修正版が出ないため、サポート中の22系以上へ移ってください。修正版は、Brotliの不具合、証明書の確認の不具合、eMudhraの証明書の拒否を、まとめて含んでいます。

すぐに上げられない場合

すぐに上げられない場合は、WAFが時間稼ぎになります。VercelやImpervaは、外から届くリクエストに遮断のルールを当てました。

ただし、Brotliのデータが届く場面の図のとおり、アプリが fetch で取得した応答はWAFでは守れません。Vercelも、WAFは修正版への更新の代わりにならないとしています。外部のサーバーからデータを取得する機能があるアプリは、特に早く上げてください。

Node.js以外の証明書の一覧も更新する

eMudhraの証明書の問題は、Node.jsだけのものではありません。ルート証明書の一覧を自分で持つソフトは、それぞれの更新が必要です。

PythonのrequestsなどでHTTPSの通信に使われるcertifi、Go、Deno、Bun、curlのほか、OSのルート証明書の一覧（Linuxの ca-certificates など）も修正版が出ています。Electronで作ったデスクトップアプリは、アプリの提供元が修正済みのElectronへ上げた版を出すまで直りません。OSやアプリの更新が届いていれば、早めに当てておきましょう。

静的サイトとビルドに使うNode.js

あらかじめ作ったHTMLを配るだけの静的サイトで、Node.jsをビルドだけに使っている場合は、公開したサイトでNode.jsが動きません。外から攻撃が届く心配は小さいものの、ビルドの途中で外部のデータを取得する作りもあります。手元やCIのNode.jsも、修正版に上げておくと安心です。

参考にした一次情報

• Node.js「Wednesday, October 21, 2026 Security Releases」
• Node.js「Node.js Releases」
• Node.jsのリリースノート「v24.22.1」
• Node.jsの変更「tls: reject chains containing blocked public keys」（#66871）
• Node.jsの変更「crypto: update root certificates to NSS 3.131.1」（#66877）
• google/brotli「Releases」
• CVE Program「CVE-2026-111497」
• Vercel「Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)」
• Imperva「Node2Shell: From Brotli Data to Remote Code Execution」
• Mozilla Bugzilla「eMudhra: Private key compromise of Intermediate Certificates」（Bug 2083449）
• eMudhra Intermediate CA Compromise（報告者による状況のまとめ）