UNIVERGE IX-Rに未認証RCE、1.3系は修正なし

NECは2026年8月21日、企業向けVPNルータ「UNIVERGE IX-R/IX-Vシリーズ」に、認証なしで任意のコマンドを実行される脆弱性（CVE-2026-16876、CVSS v3.0で9.4／v4.0で9.3）が存在すると公表しました。Webコンソール機能に細工したメッセージを送信されるだけで成立します。

対処版は Ver1.4.34 と Ver1.5.29 ですが、落とし穴が2つあります。Ver1.3系以前には同系列の修正版が示されていないこと、そして「Webコンソール（WebGUI）は使っていないから関係ない」では該当を否定できないことです。

この記事でわかること

  • UNIVERGE IX-R/IX-Vとは何で、どこで動いているのか
  • CVE-2026-16876の影響範囲と対処版・回避策（一次情報ベース）
  • WebGUIを使っていなくても該当しうる「発生条件」の読み方と、自社の該当判定手順
  • Ver1.3系以前に修正版が無いことの実務上の意味
  • 同じ機能で3回続けて脆弱性が出ている事実から導ける、恒久的な打ち手

UNIVERGE IX-R/IX-Vとは何者か

UNIVERGE IX-R/IX-Vシリーズとは、NECが提供する企業向けのVPN対応ルータ製品群です。本社と拠点をIPsec VPNで結んだり、拠点のインターネット接続の出口に置いたりする、いわゆる「拠点ルータ」の位置づけで、導入するのは基本的に情報システム部門またはその委託先です。

押さえておきたいのは、ハードウェアだけでなくソフトウェア（仮想）ルータが含まれる点です。NECの製品ページによると、内訳は次のとおりです。

  • IX-Rシリーズ（ハードウェア）：IX-R2510（小型）、IX-R2520（拠点用多ポート）、IX-R2530（10ギガビット対応）、IX-R2610-4G（LTE通信モジュール内蔵）
  • IX-V100（ソフトウェアルータ）：Oracle Cloud Infrastructure（OCI）や VMware ESXi／vSphere Hypervisor の仮想マシン上で動作する仮想ルータ

ここが「自分ごと」の分かれ目になります。ラックにNEC製のルータを置いた覚えがなくても、クラウド上や仮想化基盤の中で IX-V100 が動いていれば対象です。仮想アプライアンスはハードウェアの資産台帳にも、端末の「インストール済みソフトウェア一覧」にも載らないため、存在そのものを見落としやすい資産です。クラウド側の構築を別部門やSIerに任せている場合は特に、まず所在の確認から始める必要があります。

何が起きたのか

JVNとNECの発表内容を整理すると、次のとおりです。

項目 内容
脆弱性ID CVE-2026-16876（JVN#81414813／NEC NV26-005）
種別 重要な機能に対する認証の欠如（CWE-306）
CVSS v4.0 9.3（AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N）
CVSS v3.0 9.4（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L）
想定される影響 Webコンソールに細工したメッセージを送信されると、認証なしで任意のコマンドを実行される可能性
対象製品 IX-R2510／IX-R2520／IX-R2530／IX-R2610-4G／IX-V100
対象ソフトウェア Ver1.1〜Ver1.3の全バージョン／Ver1.4.21〜Ver1.4.28の全バージョン／Ver1.5.23
対処版 Ver1.4.34、Ver1.5.29（IX-R／IX-V共通）
公表日 2026年8月21日

CVSSベクタを見ると PR:N（権限不要）・UI:N（利用者の操作不要）・AC:L（攻撃条件が単純）が揃っています。フィッシングで誰かを誘導する必要も、事前に管理者アカウントを奪う必要もありません。到達できれば成立する類のもので、境界に置かれる機器としては最も避けたい組み合わせです。

なぜ「WebGUIは使っていない」で済まないのか

答えは、該当条件がWebコンソールの利用有無ではなく、HTTP(S)サーバ機能が有効かどうかで決まるからです。

NECは発生条件を「HTTP(S)サーバ機能で以下を利用している場合」として、次の3つを挙げています。

  • Webコンソール
  • PAC配信（プロキシ自動設定ファイルの配信）
  • NetMeister子機接続

NetMeisterは、NECプラットフォームズが提供するネットワーク機器のクラウド型統合管理サービスです。設定を事前登録しておき現地では電源を入れるだけで反映させる（ゼロタッチプロビジョニング）といった運用に使われており、拠点展開の効率化のために導入している組織ほど、この機能を有効にしている可能性があります。つまり「管理はCLIでやっているからWebは切ってあるはず」という認識でも、クラウド管理や設定配信のために内部でHTTP(S)サーバが有効になっていることがあるわけです。

NEC自身も、判定は機能名ではなく設定コマンドで行うよう示しています。具体的には、次のいずれか（または両方）が入っていれば発生条件を満たします。

http-server ip enable
http-server ipv6 enable

自社が該当するかを確認する手順

  1. 資産の洗い出し：IX-R2510／2520／2530／2610-4G の設置台数と設置場所を確認する。あわせてOCI・VMware環境に IX-V100 が居ないかをクラウド／仮想基盤側の担当に確認する。
  2. ソフトウェアバージョンの確認：Ver1.1〜1.3の全バージョン、Ver1.4.21〜1.4.28、Ver1.5.23 が対象。2025年9月の脆弱性対応で Ver1.3.27 に上げた機器も「Ver1.3」に含まれるので対象です。
  3. 設定の確認：コンフィグ内に http-server ip enable / http-server ipv6 enable があるか。あれば発生条件を満たします。
  4. 到達経路の確認：その機器のHTTP(S)ポートに、WAN側や信頼していないセグメントから到達できる状態になっていないか。フィルタで絞られているかを実機の設定で確認します。

1〜3はコンフィグのバックアップがあれば机上で一括確認できます。台数が多い環境では、まずコンフィグの全文検索で http-server を引くのが最短です。

見落としやすい落とし穴：Ver1.3系以前に修正版が示されていない

NECのアドバイザリで対処版として挙がっているのは Ver1.4.34 と Ver1.5.29 だけです。執筆時点で、Ver1.3系以前に対する修正版の記載はありません。影響範囲には「Ver1.1〜Ver1.3の全バージョン」が入っているので、次のような構図になります。

現在のバージョン 今回必要になる作業
Ver1.5.23 Ver1.5.29 へ更新（同系列内のマイナー更新）
Ver1.4.21〜1.4.28 Ver1.4.34 へ更新（同系列内のマイナー更新）
Ver1.1〜1.3の全バージョン 同系列の修正版が示されていない。Ver1.4系またはVer1.5系へのバージョンアップが必要

これは実務上、まったく重さの違う作業です。前者は計画停止1回で終わる話ですが、後者はメジャーバージョンをまたぐ更新になり、設定の互換性確認、機能差分の洗い出し、切り戻し手順の準備、拠点ごとの作業窓の調整がついて回ります。緊急パッチのつもりで着手すると、必要な工数を見誤ります。

さらに引っかかるのが、2025年9月の脆弱性（CVE-2025-8153、クロスサイトスクリプティング）で案内された IX-R/IX-V の対処版が Ver1.3.27 だった点です。当時の案内どおりに更新した組織ほど、いま Ver1.3系に居ることになり、今回は同じやり方では対処できません。「前回ちゃんと直したのに、今回は素直に当てられない」というのは、現場としてはかなり厳しい状況です。旧系列に修正版が提供されない構図は、WatchGuard Fireboxの事例でも起きています。

3回続けて同じ機能が起点になっている

NECの脆弱性情報ページを遡ると、IX-R/IX-Vシリーズで公表された脆弱性は、いずれもHTTP(S)サーバ機能（Webコンソール）を起点にしています。

公表日 脆弱性 CVE CVSS 成立の前提 IX-R/IX-V対処版
2024/11/29 コマンドインジェクション／CSRF CVE-2024-11013／CVE-2024-11014 7.2／4.3（v3.0） ログイン済みユーザーが必要 Ver1.2.22
2025/09/17 クロスサイトスクリプティング CVE-2025-8153 6.1（v3.0）／5.1（v4.0） 利用者に細工したURLをクリックさせる必要あり Ver1.3.27
2026/08/21 重要な機能に対する認証の欠如 CVE-2026-16876 9.4（v3.0）／9.3（v4.0） 前提なし（認証不要） Ver1.4.34、Ver1.5.29

注目したいのは右から2列目です。2024年版は「ログインしたユーザーが」、2025年版は「URLをクリックさせることで」という前提条件がありましたが、今回はその前提が消えています。攻撃者から見れば、同じ入口に対する条件が回を追うごとに緩くなってきた形です。

この並びが示す結論は明確です。この機能について「CVEが出るたびに1件ずつ潰す」運用は割に合いません。使っていないのであれば no http-server ip enable / no http-server ipv6 enable で機能自体を止め、必要な場合もフィルタで接続元を限定する。NECが回避策として挙げている内容は、そのまま更新後も残す常設の設定として扱うのが妥当だと考えます。管理インターフェースの露出を絞るという考え方自体は、NetScalerの認証バイパスなど他の境界機器の事例でも繰り返し確認されています。

CVEレコードは執筆時点でまだ公開されていない

もう一点、脆弱性管理の運用に関わる事実があります。CVE-2026-16876は、2026年8月21日時点でCVEプログラム本体（cve.org）およびNVDにレコードが公開されていません（いずれのAPIに問い合わせても「該当レコードなし」が返ります）。

つまり、NVDのフィードやCVE番号ベースの自動取り込みだけで脆弱性情報を集めている場合、この件は当面まったく引っかかりません。今回のように国内の届出制度（情報セキュリティ早期警戒パートナーシップ）経由で JVN#（JVN番号）として先に公表されるケースでは、海外データベースへの反映に時間差が生じます。国産のネットワーク機器を使っているのであれば、JVNとベンダー自身のセキュリティ情報ページを購読対象に入れておくことが実質的な必須要件になります。

なお、JVN・NECのいずれも、悪用や実証コードの公開には言及していません（執筆時点）。ただしCVSSの値と条件の緩さを踏まえると、悪用が確認されてから動けばよい案件ではありません。

現場目線で厳しいところ

正直なところ、この種の案件でいちばん時間を取られるのは技術的な判断ではなく、「どこに何台あって、いま何のバージョンで、どういう設定で動いているか」を集める作業です。拠点ルータは設置から数年触っていないことが珍しくなく、コンフィグの最新版が手元にない、担当していたSIerの窓口が変わっている、拠点での作業には現地の立ち会いが要る、といった障害が積み重なります。本社から拠点の機器の細部までは目が届かない、というのが実感に近いところではないでしょうか。

そこに今回は「1.3系以前はメジャーバージョンアップ」という条件が乗ります。稼働中の拠点回線を止める調整は情シスの一存では決められず、業務部門との交渉が要ります。だからこそ、先に回避策（HTTP(S)サーバ機能の停止、フィルタによる接続元制限）でリスクを下げ、バージョンアップは計画作業として別に組むという二段構えが現実的です。経営層への説明も「緊急パッチ」ではなく「バージョンアップを伴う保守案件」として早めに立てておいたほうが通りやすいはずです。

情シスはどうすべきか

本件そのものへの対応は、NECのアドバイザリ（2025年のNV25-005ではなくNV26-005）に記載された対処版と回避策に従うのが基本です。加えて、こうした境界に置かれたネットワーク機器の管理をどう仕組み化するかについては、公的機関の指針をそのまま社内の枠組みに使えます。

また、こうした通知は情シスだけが読んでいても回りません。拠点の機器を実際に触る担当者や委託先にも、脆弱性情報が届く経路を作っておくこと自体が地道ですが効きます。中期的には、管理インターフェースを外部に晒さない設計という観点でZTNAとVPNの違いやゼロトラストの考え方を押さえておくと、同種の案件が来るたびの場当たり対応から抜けやすくなります。

まとめ

  1. NEC UNIVERGE IX-R/IX-Vシリーズに、認証なしで任意のコマンドを実行される脆弱性（CVE-2026-16876、CVSS 9.4／9.3）。対処版は Ver1.4.34 と Ver1.5.29。仮想ルータ IX-V100 も対象なので、OCI・VMware環境も確認対象に入れる。
  2. 該当判定は「WebGUIを使っているか」ではなく http-server ip enable / http-server ipv6 enable の有無で行う。PAC配信やNetMeister子機接続のために有効化されていることがある。
  3. Ver1.1〜1.3系には同系列の修正版が示されておらず、メジャーバージョンアップが必要になる。まず回避策でリスクを下げ、バージョンアップは計画作業として組む。

出典

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