ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ nginx 1.30.1/1.31.0 公開とnjs CVE-2026-8711｜js_fetch_proxyヒープオーバーフローのstable系影響範囲とアップグレード手順
この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
js_fetch_proxy ディレクティブのヒープバッファオーバーフローで、F5 公式の CVSS v4.0 は 9.2 CRITICALです。混乱しやすいのは、nginx 本体側の修正（6件のCVEを含む）と njs モジュール側の修正が、ほぼ同時に走った点です。「nginx を 1.30.1 に上げれば安心」と早合点しがちですが、njs を使っている環境では njs パッケージ側も別途上げる必要がある。
この記事では、stable 系（1.30.x）を本番で動かしている管理者を主読者に、影響範囲の切り分け、grep での自家診断、AlmaLinux / RHEL / Ubuntu / NGINX 公式リポジトリ別のアップグレード手順を整理します。
この記事のポイント
- CVE-2026-8711 は njs の
js_fetch_proxyディレクティブのヒープバッファオーバーフロー。0.9.4 で導入され 0.9.9 で修正。CVSS v4.0=9.2 CRITICAL。 - 発火条件は「
js_fetch_proxyに$http_*/$arg_*/$cookie_*など クライアント由来の変数を含めている」かつ「ロケーションの JS ハンドラがngx.fetch()を呼ぶ」状態。njs 自体を使っていなければ影響ゼロ。 - nginx 本体側は 1.30.1 stable / 1.31.0 mainline で CVE-2026-42945（NGINX Rift）他 6件を同時修正。stable 利用者も今回はサボれない。
- 切り分けは
grep -rn "js_fetch_proxy\|load_module.*ngx_http_js_module" /etc/nginx/で2分で終わる。 - NGINX Open Source の stable 系は基本的に CVE バックポートのみが入る系統。今回の 「stable 系にもセキュリティリリースが出た」というシグナルそのものが運用上は重要。
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／
詳細はこちら
CVE-2026-8711 とは何か（js_fetch_proxy の発火条件）
0.9.4 から 0.9.8 までが影響範囲
CVE-2026-8711 の影響範囲は njs 0.9.4 ～ 0.9.8。njs 0.9.4 でjs_fetch_proxy ディレクティブが導入されたタイミングで一緒に混入し、0.9.9 で修正された、というのが時系列です。- 影響モジュール:
ngx_http_js_module（njs を nginx に組み込む際に load する動的モジュール） - 影響ディレクティブ:
js_fetch_proxy - 修正バージョン: njs 0.9.9（2026-05-19 公開）
- nginx 本体側の同時リリース: 1.30.1 stable / 1.31.0 mainline（2026-05-13 公開）
load_module modules/ngx_http_js_module.so; を nginx.conf や /etc/nginx/conf.d/ 配下で読んでいなければ影響ゼロ、と言い切れます。「js_fetch_proxy + クライアント由来変数」が3条件AND
F5 advisory と njs の CHANGES が一致して指摘しているのは、発火条件が 3つANDになっている点です。- 条件1:
js_fetch_proxyディレクティブを使っている。 - 条件2: その値に nginx 変数（特に
$http_*/$arg_*/$cookie_*等のクライアント要求由来）が含まれている。 - 条件3: 当該ロケーションの JS ハンドラ内で
ngx.fetch()が呼ばれる経路がある。
js_fetch_proxy は発火しない。本番投入時に多いのは「内部の認証プロキシに動的にヘッダを引き継がせたい」「クッキーや Authorization をそのまま下流に流したい」という発想で $http_* を埋め込むケース。この設計が今回の地雷を踏みます。nginx 1.30.1 stable と 1.31.0 mainline の影響差
stable と mainline の系統を整理する
混乱しやすいので NGINX Open Source の系統を改めて整理します。| 系統 | バージョン例 | 性格 | このリリースで入った変更 |
|---|---|---|---|
| mainline | 1.31.0 | 新機能と修正が継続的に積まれる開発系列 | CVE-2026-42945 他 6件のCVE修正＋通常の機能差分 |
| stable | 1.30.1 | 1系統あたり1年程度メンテされる安定系列。原則として CVE バックポートのみ | CVE-2026-42945 他 6件のCVE修正 |
nginx 本体側で同時に塞がれた6件のCVE
nginx.org の CHANGES と F5 advisory に列挙されているのは、概ね以下のCVE群です（impress watch および公式 CHANGES で言及されている範囲）。- CVE-2026-42945:
ngx_http_rewrite_moduleのヒープバッファオーバーフロー（NGINX Rift） - CVE-2026-42926:
proxy_set_body+ HTTP/2 バックエンド時のデータ注入 - CVE-2026-42946:
ngx_http_scgi_module/ngx_http_uwsgi_moduleのバッファオーバーリード - CVE-2026-42934:
charset_map経由の UTF-8 デコード時のオーバーリード - CVE-2026-40460: HTTP/3 接続移行時のアドレススプーフィング
- CVE-2026-40701:
ssl_ocsp使用時の Use-After-Free
PR / nginx の設定設計を腰を据えて見直す方へ
nginx実践入門 (WEB+DB PRESS plus) 久保 達彦・道井 俊介 / 技術評論社
njs / rewrite / proxy / ssl_ocsp といった「単に動かす分にはドキュメントを写すだけで足りるが、CVE が出たときに自分の設定を評価できないと困る」領域の設計判断をまとめて整理できる一冊。stable と mainline の運用設計を改めて見直す入り口に向いています。
自分のサーバが踏むかを2分で診断する
まず njs を読み込んでいるか
最短の診断はload_module 行の有無確認です。grep -rn "ngx_http_js_module\\|ngx_stream_js_module" /etc/nginx/ここでヒットゼロなら、CVE-2026-8711 については 運用上の対応不要。nginx 本体の 1.30.1 / 1.31.0 アップグレードだけ計画すれば足ります。
js_fetch_proxy にクライアント変数が入っていないか
njs を使っている環境では、続けてjs_fetch_proxy 行を炙り出します。grep -rn "js_fetch_proxy" /etc/nginx/ヒットした行の右辺に
$http_ / $arg_ / $cookie_ / $request_ / $uri あたりが含まれていれば、条件2 を満たします。あとは当該 location の JS ハンドラ内で ngx.fetch() が呼ばれているかを js_content や js_periodic から辿るだけ。grep -rn "ngx.fetch" /etc/nginx/ /usr/share/nginx/ /etc/nginx/njs/3つAND成立なら攻撃面に乗っています。njs 0.9.9 への即時アップグレードを準備してください。
診断結果でアップグレード優先度が3段階に分かれる
| 診断結果 | 優先度 | 対応 |
|---|---|---|
| njs 未ロード | 通常 | nginx 本体 1.30.1 / 1.31.0 へ計画的アップグレード（CVE-2026-42945 他） |
| njs ロード済みだが js_fetch_proxy にクライアント変数なし | 中 | njs 0.9.9 を次の定期メンテで適用 |
| 3条件AND成立（js_fetch_proxy + クライアント変数 + ngx.fetch） | 即時 | njs 0.9.9 への即時アップグレード＋暫定的に該当 location を停止 or 静的 FQDN に置換 |
アップグレード手順（AlmaLinux / RHEL / Ubuntu / 公式リポジトリ別）
NGINX 公式リポジトリ（rpm / deb）
NGINX 公式リポジトリを参照している環境（nginx.repo や nginx.list を入れているサーバ）が最も対応が早い系統です。sudo dnf clean metadata
sudo dnf upgrade nginx nginx-module-njs
sudo systemctl restart nginxDebian / Ubuntu 系は同様に
apt で。sudo apt update
sudo apt upgrade nginx nginx-module-njs
sudo systemctl restart nginxnginx -v と nginx -V 2>&1 | tr ' ' '\n' | grep -i njs でモジュール側のバージョンが想定通りか確認します。AlmaLinux / RHEL のディストリ標準リポジトリ
ディストリ標準パッケージは、NGINX 公式リリースから提供までに通常タイムラグがあります。今回も例外ではなく、執筆時点では NGINX 公式リポジトリ経由の方が先に到着している状況。- AlmaLinux / RHEL の
nginx標準パッケージは、ベンダー側がバックポートを取り込む形で順次配布される見込み。 - 緊急度が高い（3条件AND成立）環境は、NGINX 公式リポジトリへの一時切替えを検討。
- EPEL や Software Collections を介している場合はそれぞれの配布元の Errata を確認。
nginx.conf を書き換えないと起動しない、というケースは想定しなくて済むはずです。動的モジュールが nginx 本体の ABI に縛られる点に注意
落とし穴が一つあります。NGINX の動的モジュール（load_module で読む .so）は、ビルド時の nginx 本体バージョンと ABI が厳密に一致している必要がある。つまり「nginx を 1.30.1 に上げたが njs モジュールが 1.30.0 用のままだった」という状態だと、
nginx -t が module is not binary compatible エラーで落ちて起動しません。dnf / apt のディストリ標準パッケージ経由で揃えていれば依存解決で同期されますが、手動でビルド済み .so を配置している環境は要注意です。
運用判断（停めずに上げるか、一旦止めるか）
本番停止の判断軸
CVSS 9.2 CRITICAL という数字から「即時停止して上げるべき」と反射的に判断したくなりますが、運用側では 3条件AND成立の有無で停止判断を分けるのが妥当です。- 3条件AND成立 + 外向きインターネット公開: 営業時間外を待たずに該当 location を一時停止 or 静的 FQDN への書換えを優先。
- 3条件AND成立 + 社内限定: メンテ枠を確保してパッケージ更新と再起動。
- 3条件成立せず: 通常リリースサイクル（週次・月次定例メンテ）で問題ない。
nginx -s reload ではモジュール差し替えに対応できないケースがあるため、動的モジュールを差し替えた場合は systemctl restart nginx で完全再起動を推奨。reload と restart の挙動差で「上げたつもりが古い .so のままだった」事故が一番起きやすい場面です。暫定回避策（恒久対応までのつなぎ）
njs 0.9.9 のパッケージがディストリ標準で来るまで時間がかかる環境向けに、暫定回避策を整理します。- 該当
js_fetch_proxy行から$http_*/$arg_*/$cookie_*を取り除き、静的 FQDN に書換える。 - 当該 location を
return 503;で一時停止し、対応完了まで上流アプリ側で代替経路を組む。 - 該当バックエンドにアクセス可能なネットワーク区画を、社内 IP だけに
allow/denyで絞る。
stable 系運用者にとっての教訓
「stable はサボってよい」は半分嘘
nginx の stable 系を選ぶ理由は、運用上の「機能変動の少なさ」がメイン。「機能が増えないかわりに、頻繁に上げなくてよい」という設計でした。ですが今回のように stable 系にも CVE バックポートリリースが出るタイミングは年に数回ある。1.30.0 → 1.30.1 のような微小バージョンアップが出たら、それは「機能差分のないセキュリティリリース」と読んで間違いなく、運用側はむしろ 低リスクで上げ得と判断できます。
20年以上 Linux サーバーの現場にいますが、「stable だから半年後でいいや」と判断して塩漬けにした nginx が、後で別件のCVE対応のついでに 3 マイナー分まとめてバージョン上げになり、設定互換性で苦労する、というパターンを何度も見てきました。stable はサボれるが、CVE リリースが出たタイミングだけはサボれない。これが今回の運用上の教訓です。
動的モジュールを増やすほど追従コストが上がる
njs / brotli / GeoIP2 / VTS など動的モジュールを多用する nginx は、本体だけでなくモジュール側の追従が必要になります。今回の CVE-2026-8711 は、まさに「nginx 本体は上げたつもりだが njs を忘れていた」事故が起きやすい構造です。運用フローに
nginx -V の出力をスナップショットで残し、上げる前後で差分を取る習慣を組み込むと、こういう取りこぼしを潰せます。関連記事
- nginxに18年潜伏したCVE-2026-42945｜Apache mod_rewrite世代のサーバー管理者が踏みやすい罠と設計レベルの回避策 — 同時に修正された nginx 本体側CVE。
$1/$2思考の rewrite が抱える設計負債を整理しています。 - Webサーバー管理者向けNGINX Rift対応マニュアル｜影響判定・apt/dnfパッチ・WAF緩和を30分で — CVE-2026-42945 の影響判定・パッチ適用・WAF 緩和をオペレーション手順としてまとめた記事。本記事の njs 編とセットで参照してください。
よくある質問（FAQ）
Q1. njs を使っていない nginx も 1.30.1 / 1.31.0 へ上げるべきですか？
A. 上げるべきです。njs を使っていない環境では CVE-2026-8711 自体は影響しませんが、nginx 本体側で CVE-2026-42945 を含む 6件のCVEが同時に修正されています。njs の使用有無に関係なく、stable 系なら 1.30.1、mainline なら 1.31.0 へのアップグレードが必要です。Q2. nginx を 1.30.1 に上げたら CVE-2026-8711 も塞がりますか？
A. 塞がりません。CVE-2026-8711 は njs（ngx_http_js_module）側の脆弱性で、修正は njs 0.9.9 に入っています。nginx 本体のバージョンが 1.30.1 / 1.31.0 になっていても、njs パッケージが 0.9.8 以前のままだと CVE-2026-8711 は残ります。ディストリ標準パッケージ経由で nginx と njs が依存関係で揃って上がる構成か、明示的に njs パッケージを更新したかを確認してください。Q3. 静的な FQDN を js_fetch_proxy に書いているだけの環境は安全ですか？
A. F5 advisory と njs の CHANGES の記述から読む限り、発火条件はクライアント要求由来の nginx 変数（$http_* / $arg_* / $cookie_* 等）を js_fetch_proxy 値に含めている場合です。js_fetch_proxy http://internal-api.example.local; のような静的 FQDN だけの記述は、3条件ANDのうち条件2を満たしません。とはいえ将来の運用で $http_* を足す可能性があるなら、njs 0.9.9 への更新は計画的に進めておく方が安全です。Q4. NGINX Plus を使っている場合の対応は？
A. NGINX Plus は F5 の商用版で、CVE 対応リリースが別系列で出ています。CVE-2026-42945 の F5 advisory には NGINX Plus 側の対応バージョン（R32 P6 / R36 P4 等）が併記されています。CVE-2026-8711 についても同様に F5 advisory を参照し、自社契約版の対応バージョンを F5 サポート経由で確認してください。OSS 側のバージョン番号と直接対応しない点に注意。Q5. nginx -s reload でモジュールも更新されますか？
A. されません。動的モジュール（.so）の差し替えは nginx -s reload では反映されず、systemctl restart nginx（または service nginx restart）による完全再起動が必要です。dnf upgrade nginx nginx-module-njs 後に reload だけで済ませると、メモリ上は古い njs のままで動き続けるリスクがあります。動的モジュールを更新した場合は必ず restart を選んでください。PR / あわせて読みたい本
- nginx実践入門 (WEB+DB PRESS plus) 久保 達彦・道井 俊介 / 技術評論社
- 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 徳丸 浩 / SBクリエイティブ
nginx の設定設計を組み立て直したいときの実装観点（前者）と、Webアプリ全体の脆弱性パターンを系統立てて押さえる観点（後者）。CVE が出るたび個別対応する運用から、設計レベルで安全側に倒す運用へ移るための2冊として揃えておくと役立ちます。
まとめ
CVE-2026-8711 は njs 0.9.4 ～ 0.9.8 のjs_fetch_proxy ディレクティブにあるヒープバッファオーバーフローで、CVSS v4.0 9.2 CRITICAL。修正は njs 0.9.9（2026-05-19）。nginx 本体側は同時に 1.30.1 stable / 1.31.0 mainline（2026-05-13）が公開され、CVE-2026-42945（NGINX Rift）を含む 6件のCVEが修正されました。njs を使っていなくても nginx 本体側のアップグレードは必要です。
3つAND（
js_fetch_proxy + クライアント由来変数 + ngx.fetch() 呼出）が成立する環境は即時対応、それ以外は通常メンテ枠で十分。grep -rn "js_fetch_proxy" /etc/nginx/ で2分で診断が終わります。stable 系を運用している管理者の方は、1.30.0 → 1.30.1 のような 「機能差分のないCVE専用リリース」が来たタイミングを一番サボらないようにしてください。今回のように nginx 本体 + njs の2系統を揃えて上げる場面は、これからも繰り返し出てきます。
Linux サーバー運用の現場感覚を、もっと体系的に学びたい方へ。
リナックスマスター.JP では、現役の Linux 管理者向けに CVE 対応や運用判断の軸を扱うメール教育とセミナーを開催しています。今回の njs / 動的モジュール / stable と mainline の運用設計のような「公式ドキュメントに書かれていない、現場の判断軸」を、20年以上の運用経験を元にお伝えしています。
出典: 窓の杜「nginx」のJavaScriptモジュール「njs」に深刻度「Critical」の脆弱性（2026-05-21） / nginx.org CHANGES / GitHub nginx/njs CHANGES
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Ubuntu 26.10「stonking」開発状況—Canonical監査AI「Redhound」の中身
- 前のページへ：Torvalds激怒「AIバグ報告」氾濫がLinuxカーネルMLを止めた件｜OSS開発者と現役管理者が今すべき対応
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます