NGINX njsに脆弱性3件、認可回避や停止の恐れ

結論から書きます。NGINX上でJavaScriptを動かすモジュール「njs（NGINX JavaScript）」に脆弱性3件が公表され、2026年9月2日に修正版njs 1.0.1がリリースされました。最大深刻度はCVSS v4.0で9.2。ただし影響を受けるのは「njsモジュールを読み込み、設定ファイルで実際にJavaScriptを呼んでいる環境」だけです。まずは自社のNGINXが該当するかどうかを切り分けてください。判定は数分で終わります。

この記事でわかること

  • njsとは何をするもので、どこで動いているのか
  • 3件の脆弱性の内容・影響バージョン・深刻度（一覧表）
  • 自社が影響を受けるかを切り分けるコマンド手順
  • スコアが最大の脆弱性より、実務で先に潰すべき脆弱性はどれか

njsとは何か（「うちは使っていない」と思う前に）

njs（NGINX JavaScript）とは、NGINXの設定ファイルの中からJavaScriptを呼び出し、リクエストの書き換えや認証・認可の判定、外部APIの呼び出しといった処理を行わせるための拡張モジュールです。

導入するのは主にインフラ担当者です。NGINXをリバースプロキシやロードバランサとして立てたあと、設定ディレクティブだけでは書けないロジック（JWTの検証、独自ヘッダの生成、条件の複雑なアクセス制御など）を足したいときに、数十行のJavaScriptを書いて組み込む――という使われ方をします。アプリ側のコードではなく「インフラの設定の一部」として存在するのが特徴で、これが後述する管理の盲点につながります。

そして重要なのが、どこに同梱されているかです。

  • オープンソース版nginx：既定では入っていません。nginx-module-njsパッケージを追加し、load_module modules/ngx_http_js_module.so;で読み込む形です（動的モジュール）。
  • NGINX Plus（商用版）：こちらも既定では含まれず、nginx-plus-module-njsを別途インストールする方式です。
  • F5 NGINX Ingress Controller：公式の技術仕様において、NGINX Plusベースのコンテナイメージの「追加モジュール」としてNJSが明記されています。Kubernetes基盤でIngress Controllerを動かしている場合、自分でnjsを入れた覚えがなくてもイメージの中に含まれていることになります。

つまり「njsなんてインストールしていない」と即断できるのは、OSS版やNGINX Plusを素の状態で使っているケースまでです。コンテナ基盤側は別途確認が必要になります。

何が起きたのか：公表された3件の脆弱性

nginx公式のnjsセキュリティアドバイザリおよびCVE情報をもとに整理すると、次の3件です。いずれも修正はnjs 1.0.1で行われています。

CVE 内容 影響を受けるnjsバージョン CVSS v4.0 CVSS v3.1 nginx公式の深刻度
CVE-2026-78689 xml.exclusiveC14n()のヒープバッファオーバーフロー（範囲外書き込み）。細工されたXML名前空間プレフィックスリストにより、ワーカープロセスのクラッシュやメモリ増加が起きうる 0.7.10 〜 1.0.0 9.2 8.1 Major
CVE-2026-18329 js_accessのアクセス制御バイパス。非同期のアクセス制御評価中に例外が発生すると、拒否されるべきリクエストが通ってしまう（フェイルオープン） 0.9.9 〜 1.0.0 8.8 8.2 Medium
CVE-2026-78222 ngx.fetch()が不正な形式のHTTPレスポンスを受け取るとワーカープロセスがクラッシュする（NULLポインタ参照によるDoS） 0.5.1 〜 1.0.0 8.7 7.5 Medium

CVE-2026-78689で問題となったxml.exclusiveC14n()は、XML署名の正規化（Exclusive XML Canonicalization）を行う関数です。SAMLアサーションの署名検証など、XML署名を扱う実装で登場します。njsでXML署名まわりの処理まで書いている環境は多くないと思われますが、逆に言えば該当する環境はシングルサインオンの入口である可能性が高いということでもあります。

スコアが一番高い脆弱性を先に直すべきか？

いいえ。実務での優先度はCVE-2026-18329（js_accessのフェイルオープン）が最も高いと考えます。理由は「気づけないから」です。

クラッシュ系（CVE-2026-78689、CVE-2026-78222）は、起きればワーカープロセスが落ちるため、監視やアクセスログに異常として現れます。可用性は損なわれますが、少なくとも検知はできます。一方でアクセス制御のフェイルオープンは、拒否されるはずのリクエストが正常なレスポンスとして返るという形で発現します。攻撃が成立していても、画面上もログ上も「普通のアクセス」に見えてしまう。js_accessで認可をかけている環境は、パッチ適用と併せて、過去のアクセスログに想定外の到達がないかを見直しておくのが安全です。

自社は影響を受けるのか：切り分けの手順

nginx公式は緩和策として、js_importディレクティブが存在しなければNGINXはJavaScript関連の脆弱性から保護されるという趣旨を示しています。つまり「モジュールが入っているか」ではなく「実際に使っているか」で判定できます。次の順で確認してください。

  1. モジュールが読み込まれているか
    nginx -V 2>&1 | grep -o njs ／ grep -R "load_module.*js_module" /etc/nginx/
  2. 実際にJavaScriptを呼んでいるか（ここが本命）
    grep -R "js_import" /etc/nginx/ ―― ヒットしなければ、今回の3件の影響は受けません。
  3. どのAPIを使っているか
    grep -REn "js_access|ngx\.fetch|exclusiveC14n" /etc/nginx/ を、設定ファイルとjs_importが指すJavaScriptファイルの置き場に対して実行します。該当したCVEが自社に直結するものです。
  4. njsのバージョン
    RPM系はrpm -q nginx-module-njs、Debian系はdpkg -l | grep njs。CLIが入っていればnjs -vでも確認できます。1.0.1未満なら更新対象です。
  5. コンテナ／Ingress Controller
    ホスト上のパッケージではなくイメージに含まれるため、イメージタグを更新してnjs 1.0.1以降を含むビルドへ上げる必要があります。ベースイメージの更新提供を待つ形になるケースもあるので、提供状況を先に確認しておきます。

手順2で何も出てこなければ、そこで打ち切って構いません。「影響なし」と判断した根拠（実行したコマンドと日付）を残しておくと、後日の報告や監査で効きます。

現場目線の課題：njsは資産管理台帳に載らない

この手の脆弱性で毎回つらいのは、パッチ適用そのものより「自社に該当するかを確定させる作業」のほうです。njsは特にその傾向が強いと感じます。

第一に、njsはソフトウェア資産としてカウントされにくい。資産管理台帳に「nginx 1.x」とは書いてあっても、「njs 0.8.x」まで書いてある組織はほとんどないでしょう。動的モジュールは製品名の陰に隠れます。

第二に、書いた人がもういない。「数年前にJWT検証のために20〜30行のJavaScriptを足した」というのが一番ありがちなパターンで、現在の担当者がその中身を読める保証はありません。js_accessを使っているかどうかを判断するのに、まずコードを読むところから始めることになります。

第三に、コンテナだとさらに見えない。Ingress Controllerのイメージに含まれるコンポーネントを一つずつ把握している運用は、少数派だと思います。手元でgrepできない分、公式の技術仕様やSBOMを都度読みに行く必要があり、単純に手間がかかります。

「使っていなければ影響なし」は朗報ですが、使っていないことの証明に時間を取られるのが実情だ、というのが正直なところです。

情シスはどうすべきか

個別のチェックリストを自前で積み上げるより、公的機関の指針に沿って「脆弱性情報を受け取り、影響範囲を判定し、対処する」という流れそのものを整えるほうが再現性があります。

  • 中小企業の情報セキュリティ対策ガイドライン（IPA）
    規模を問わず使える構成で、ソフトウェアの把握（資産管理）と更新の運用が体系的にまとまっています。今回のように「どこに何が入っているか分からない」が課題になったときは、台帳の粒度を見直す出発点として有効です。
  • 対策のしおり（IPA）
    利用部門への周知資料として使えます。今回はインフラ側の話ですが、SSOやプロキシの挙動が変わりうる更新は、事前告知の有無で問い合わせ件数が大きく変わります。地道な周知・啓発を軽視しないほうが、結局は運用が楽になります。

加えて、njsのようなスクリプトを書いた場合は「誰が・いつ・何のために書いたか」をコード内のコメントか運用手順書に残す運用を、この機会に決めてしまうことをおすすめします。次に同種の脆弱性が出たときの判定コストが大きく下がります。

中長期の視点：「設定ファイルの中のコード」が増えている

njsに限らず、近年はプロキシやゲートウェイの内部でスクリプトを動かす仕組みが増えました。njs、NGINXのLuaモジュール、Envoyのフィルタ、Ingressのアノテーションによる挙動変更などがその例です。これらはアプリケーションでもOSでもない中間領域にあり、脆弱性管理のプロセスからも、SBOMの生成対象からも漏れやすい位置にあります。

棚卸しの単位を「導入している製品」から「有効化しているモジュール・拡張」へ一段細かくすること。これが中長期の打ち手になります。全部を一度にやる必要はなく、インターネットに面したプロキシやSSOの入口から始めるのが現実的です。

まとめ

  1. njsに3件の脆弱性が公表され、修正版1.0.1が2026年9月2日にリリースされた。最大はCVE-2026-78689でCVSS v4.0の9.2。
  2. 影響判定の決め手はjs_importの有無。設定ファイルにこのディレクティブが無ければ今回の脆弱性の影響は受けない。あるならバージョンと使用API（js_access／ngx.fetch()／xml.exclusiveC14n()）を確認する。
  3. 実務の優先度はスコア順ではなくCVE-2026-18329（js_accessのフェイルオープン）から。認可の素通りはログ上「正常なアクセス」に見え、検知が難しい。

関連記事

出典

タイトルとURLをコピーしました