NEC UNIVERGE IX-R/IX-Vに認証不要のコマンド実行（CVE-2026-16876）｜機種・版数・設定の3点で該当が決まる

事実関係

NECは2026年8月21日、企業向けルータUNIVERGE IX-R/IX-VシリーズのWebコンソール機能における認証処理の脆弱性を、脆弱性レポートNV26-005として公表しました。同日、JVNにもJVN#81414813として掲載されています。

深刻度は、CVSS 4.0の基本値で9.3、CVSS 3.0の基本値で9.4です。NECの記載によれば、攻撃者が当該製品のWebコンソールへ細工したメッセージを送信した場合、認証なしで任意のコマンドを実行される可能性があります。脆弱性の種別は、重要な機能に対する認証の欠如です。

対象は次のとおりです。

「Webコンソールは使っていない」では判定できない

この脆弱性でもっとも見落とされやすいのが発生条件です。NECは、HTTP(S)サーバ機能で次のいずれかを利用している場合に発生すると記載しています。

• Webコンソール
• PAC配信
• NetMeister子機接続

そして具体的には、http-server ip enable または http-server ipv6 enable のいずれか、または両方が設定されている場合が該当するとしています。

ここが実務上の分岐点です。現場に「ルータの管理画面をブラウザで開いていますか」と聞いても、答えは「使っていません」になりがちです。日常の運用をコマンドラインで行っていれば、担当者の認識としては正しい回答です。しかし、PAC配信を使っていたり、NECのクラウド管理サービスであるNetMeisterで子機を接続していたりすると、同じHTTP(S)サーバ機能が有効になっています。

したがって確認すべきは、利用者の記憶ではなく設定です。http-server ip enable と http-server ipv6 enable が投入されているかどうかを、機器ごとに実機で確認してください。

確認から対応までの順序

1. 台数の確定：対象5機種が社内に何台あるかを、拠点・工場・店舗・倉庫まで含めて数える。予備機や、休止拠点に残った機器も数える。
2. 版数の取得：各機器のソフトウェアバージョンを取得し、対象範囲に入るかを判定する。
3. 設定の確認：http-server の設定有無を確認する。ここまでで該当・非該当が確定する。
4. 到達経路の確認：該当機器について、インターネット側からHTTP(S)へ到達できるかを確認する。WAN側で開いている場合は最優先。
5. 対処：Ver1.4.34またはVer1.5.29へ更新する。更新できない場合は下記の代替策を期限付きで適用する。
6. 記録：確認日、確認者、判定結果、対処内容、次回確認予定日を残す。

更新できない場合の代替策と、その限界

NECは、バージョンアップ以外に次を示しています。それぞれの位置づけを取り違えないことが重要です。

回避策（脆弱性の前提を成立させない）

• no http-server ip enable および no http-server ipv6 enable を投入し、HTTP(S)サーバ機能を停止する。

これは条件そのものを外す対応です。ただし、PAC配信やNetMeister子機接続に依存した運用をしている場合、停止すると業務側に影響が出ます。停止して何が動かなくなるかを、投入前に洗い出してください。

軽減策（リスクを下げるが、前提は残る）

• フィルタ機能で接続元をIPアドレス、MACアドレスにより制限する。
• 対象装置のIPアドレスを変更し、かつTCPポート80または443を予想されにくい番号へ変更する。

NECはこれらを、回避策を適用できない場合のリスク軽減として位置づけています。ポート番号の変更は探索の手間を増やしますが、脆弱性そのものを取り除くものではありません。恒久対応までのつなぎとして、期限と再確認日を決めて運用してください。

なぜ拠点ルータは放置されるのか

この種の機器が更新されないまま残る理由は、技術ではなく体制にあります。中堅企業でよくある構造は次のとおりです。

• 導入時は工事業者が設定し、以後は誰も触っていない
• 保守契約はハードウェア故障時の交換が中心で、ソフトウェア更新の実施主体が書かれていない
• 拠点の機器は本社の資産台帳に載っていない、または機種名だけで版数の欄がない
• 夜間・休日に止められる時間帯の合意がなく、更新の話が出るたびに先送りされる

つまり、脆弱性が公表されてから慌てるのは、公表そのものが原因ではありません。平時に「誰が版数を見るか」が決まっていないことが原因です。今回はその点検の機会として使えます。

保守契約で確認すべき5項目

拠点ネットワークの保守を外部に委託している場合、契約書と実際の運用の差を確認してください。次の5点は、実務でよく食い違います。

契約に通知義務が書かれていない場合、「通知が来なかったから対応が遅れた」という説明は、当事者間で受け入れられるとは限りません。今回の対応と同時に、契約側の穴を塞いでおくことをおすすめします。

機器台帳を今日から作る場合の最小項目

台帳が存在しない会社が、いきなり完全な構成管理を始めるのは現実的ではありません。次の6項目だけで、脆弱性公表時の初動が大きく変わります。

• 設置場所（拠点名・フロア）
• 機種名と製造番号
• ソフトウェアバージョンと、その確認日
• インターネット側に開いているサービスの有無
• 保守委託先と連絡先
• 更新作業に必要な停止時間と、停止可能な時間帯

この6項目は、Excelの1シートで足ります。重要なのは項目数ではなく、更新日が入っていることです。

GXOへの相談が向いているケース

拠点が複数あり、機器の一覧も版数も社内で把握できていない場合、まず何から手を付けるかを決める段階で止まりがちです。着手順の整理はセキュリティ対策の優先順位整理、外部から到達できる資産の実地確認は脆弱性診断で扱います。公表が出るたびに社内が止まる状況そのものを変えるなら、通知の受け取りから判断までを外部に持たせるセキュリティ運用伴走という選択肢があります。ネットワークを含む社内システム全体の作り替えを視野に入れているならシステム開発の発注前相談の範囲です。

拠点の数だけ増える確認コストをどう抑えるか

拠点数と1拠点あたりの台数が増えるほど、機器ごとの確認を手作業で行う負荷は上がります。どこで手作業が回らなくなるかは体制によりますが、選択肢は概ね3つです。

3つ目には落とし穴があります。集中管理の対象になっている機器だけを見て「全台確認済み」としてしまうと、後から導入した機器や、拠点で個別に追加した機器が漏れます。管理下の台数と、実際の設置台数が一致しているかを別途確認してください。

資産の一覧がない場合でも、突合に使える情報源があります。固定資産台帳、保守契約の対象機器一覧、購入時の発注記録、拠点への回線契約の一覧などです。複数を突き合わせれば差分から漏れの手がかりが得られますが、いずれの資料にも載っていない機器は残ります。最終的な該当判定は、実機で版数と設定を確認する必要があります。

更新作業の見積りを比較する観点

委託先から更新作業の見積りを受け取ったとき、金額だけでは妥当性を判断できません。次の項目が書かれているかで比較してください。

作業単位：1台あたりか、拠点あたりか、一式か。一式の場合、台数が増えたときにどうなるかを確認します。

作業時間帯：日中か夜間か。夜間・休日の加算があるか。同時に何拠点を実施するか。

事前バックアップ：現行設定の保存が作業に含まれるか。含まれない場合、設定が失われたときの復旧をどうするか。

切り戻し：更新後に問題が発生した場合の切り戻し手順と、その作業が見積りに含まれるか。

確認作業：更新後に通信が正常であることをどう確認するか。確認の範囲（拠点内の通信のみか、拠点間や外部との通信まで含むか）。

立ち会い：拠点側の立ち会いが必要か。必要なら、その人員は自社が用意するのか。

このうち切り戻しの記載がない見積りは、追加費用が発生する余地を残しています。ネットワーク機器の更新は、まれに想定外の挙動を起こします。戻せる前提で計画するのが実務です。

「今回だけ」で終わらせないための3つの決めごと

今回の公表への対応が終わったあと、次に同じ状況を作らないために決めておくことがあります。

決めごと1：機器の版数を確認する頻度 定期確認の間隔は、機器の台数、外部への公開状況、保守体制によって変わります。ただし、定期確認だけでは今回のように公表直後の対応には間に合いません。定期確認と、公表を受けて動く随時対応を、別の仕組みとして用意してください。定期確認については、頻度そのものより実施する月を決めておくことが重要です。「必要なときに」では実施されません。

決めごと2：ネットワーク機器の管理画面を、外部から到達させない方針 今回のような脆弱性は今後も出ます。管理系の機能を外部から到達できる状態に置かない、という方針を先に決めておけば、個別の脆弱性が出るたびの緊急度が下がります。運用上どうしても外部からの管理が必要な場合は、接続元の制限を条件にします。

決めごと3：機器の更新期限と保守期限の一覧 機器には保守が提供される期間があります。期間が終わった機器では、脆弱性が公表されても修正版が提供されない場合があります。個別の延長契約や例外的な対応があり得るため、実際の扱いはベンダーへ確認してください。保守期限の一覧を持っていれば、更新の予算を計画に入れられます。期限切れの機器が拠点に残っていることに、脆弱性の公表で初めて気づく場合もあります。

経営会議への報告の形

情報システム部門から経営へ報告する際、技術的な説明ではなく次の形にすると意思決定が進みます。

• 対象となり得る機器：○台（うち確認済み○台、未確認○台）
• 該当が確定した機器：○台
• そのうち外部から到達し得るもの：○台
• 対応済み：○台、対応予定：○台（実施予定日）
• 対応できない機器：○台（理由と代替策、恒久対応の期限）
• 想定される追加費用：○円

この6行があれば、経営は判断できます。逆に「重大な脆弱性が公表されました。対応中です」という報告では、判断する材料がありません。

FAQ

Q1. 対象機種を使っていますが、WAN側からWebコンソールは見えません。対応は不要ですか

外部から到達できないことは重要な緩和条件ですが、それだけで対応不要とは判断できません。社内ネットワークからの到達、拠点間VPN経由の到達、無線LAN経由の到達も経路になり得ます。到達範囲を確認したうえで、更新の時期を決めてください。

Q2. IX-R/IX-V以外のUNIVERGE IXシリーズは対象ですか

NV26-005の対象製品として記載されているのは、IX-R2510、IX-R2520、IX-R2530、IX-R2610-4G、IX-V100です。それ以外の機種については、公式の脆弱性情報一覧で個別に確認してください。過去にも別番号の脆弱性が公表されています。

Q3. バージョンが対象範囲より新しい場合はどうなりますか

NECが示す対象は、Ver1.1〜Ver1.3の全バージョン、Ver1.4.21〜Ver1.4.28の全バージョン、Ver1.5.23です。対処版はVer1.4.34およびVer1.5.29です。自社の版数がこの範囲のどこに位置するかを、番号で確認してください。

Q4. ポート番号を変えれば当面は安全ですか

NECが軽減策として示しているのは、ポート番号の変更単独ではありません。対象装置のIPアドレスを変更し、かつTCPポート80または443の番号を予想されにくい番号へ変更する、という組み合わせです。これは回避策とは区別されており、探索されにくくなるだけで脆弱性そのものは残ります。恒久対応の期限を決めたうえでの暫定措置として扱ってください。

Q5. 更新作業を委託先に頼むと費用がかかると言われました

費用の妥当性は、契約の記載と作業内容で判断します。年間の更新回数が契約に含まれているか、作業時間帯の指定で加算があるかを確認してください。判断が難しい場合は、他社の見積りと比較する形で第三者に意見を求める方法もあります。

参考情報

• NEC 脆弱性レポート NV26-005（2026年8月21日）
• NEC UNIVERGE IX-R/IX-V 脆弱性問題に関するお知らせ
• JVN#81414813
• GXO 脆弱性診断
• GXO セキュリティ運用伴走

記載した対象機種、対象バージョン、対処版、回避策は、NECが公開している脆弱性レポートNV26-005の本記事公開時点の版から書き起こしています。改版される可能性があるため、作業の実施前に公式ページで最新の版を確認してください。自社構成での影響範囲の判断は、実機の設定確認が前提となります。