QNAP NASにCSRF脆弱性、深刻度が割れる理由

【更新 2026-08-10】本記事を見直し、修正しました。主な修正点：CVSS v3とv4の違いに関する説明のうち、「利用者の操作が成立条件になる脆弱性はv4のほうが低く出やすい」という記述を、FIRSTの計算式で検証した結果にもとづき訂正しました（5.1と8.8の差はほぼ影響の見積もり方の違いによるものです）。

QNAP製NASの標準アプリ「Notification Center」に、クロスサイトリクエストフォージェリ（CSRF）の脆弱性（CVE-2025-58468）が公表されました。修正済みバージョンは 1.10.0.3291 以降で、App Centerからの更新で対処できます。緊急パッチ扱いにするほどではないものの、NASは資産台帳から漏れやすく、更新が何年も放置されがちな機器です。この機会に棚卸しまで含めて手を付けるのが実務的です。

そしてこの脆弱性は、もうひとつ厄介な特徴を持っています。深刻度スコアが評価者によって5.1（中）と8.8（高）に割れていることです。上司や運用チームに「これは急ぎか」と聞かれたとき、どちらの数字を根拠に答えるべきか——本記事ではその判断の仕方まで踏み込みます。

この記事でわかること

• CVE-2025-58468の概要と、影響を受けるバージョン・修正版
• CSRFで実際に何をされうるのか（管理者が踏むと何が起きるか）
• 深刻度が5.1と8.8に割れている理由と、情シスがどちらを採るべきか
• NASという「見落とされがちな資産」を運用に組み込む考え方

何が起きたのか

QNAP Systems は、NAS向けOS「QTS」「QuTS hero」上で動作するアプリ Notification Center に、CSRF脆弱性が存在するとしてセキュリティアドバイザリ QSA-26-13 を公開しました。QNAPの説明では、リモートの攻撃者がこれを悪用すると権限を取得したり、利用者のID（身元）を乗っ取ったりする可能性があるとされています。

本稿執筆時点（2026年8月）で、この脆弱性が実際に悪用されたという公開情報は確認できていません。ただし「悪用報告がない」ことは「悪用されない」ことを意味しません。修正版は既に提供されているため、対応を先送りする理由は乏しいと考えます。

自社は影響を受けるのか？

QNAP製NASを使っているなら、原則として影響対象と考えてください。Notification Centerは、メール・SMS・プッシュ通知などの警告通知をまとめて設定するためのアプリで、QTS／QuTS heroの環境で標準的に導入されています。「うちはそんなアプリ入れていない」と思っていても、実際にはApp Centerに入っているケースがほとんどです。

確認と更新の手順は、QNAPのアドバイザリに記載されたとおりシンプルです。

1. 管理者アカウントで QTS または QuTS hero にログインする
2. App Center を開き、検索から「Notification Center」を探す
3. 表示されたバージョンが 1.10.0.3291 未満なら「更新」を実行する（既に最新の場合、更新ボタンは押せません）
4. 確認ダイアログで更新を承認し、完了を待つ

なお、同じCSRFという分類では、QNAPのログ管理アプリ QuLog Center でも過去に同種の脆弱性（CVE-2025-58469）が公表されています。NAS本体のファームウェアだけを見ていると、こうしたアプリ側の更新は取りこぼします。本体OSとApp Centerのアプリは別管理である、という前提を運用に落とし込んでおく必要があります。

CSRFで何をされるのか？

CSRFとは、ログイン中の利用者のブラウザを踏み台にして、本人が意図しない操作をサーバに送らせる攻撃です。攻撃者がNASのパスワードを知っている必要はありません。狙われるのは「認証済みのセッションを持ったブラウザ」そのものです。

典型的な流れはこうなります。

1. 管理者がNASの管理画面にログインしたまま、同じブラウザで別のタブを開く
2. そのタブで、攻撃者が用意した罠のページ（あるいは細工されたリンクを含むメール）を開く
3. 罠のページから、NASに対する設定変更リクエストが管理者のブラウザ経由で自動送信される
4. NAS側は「ログイン中の管理者からの正規の操作」として処理してしまう

Notification Centerの文脈で怖いのは、これが「通知の設定」を扱うアプリだという点です。異常検知や不正ログインの通知先を書き換えられれば、その後の侵入が管理者に届かなくなります。攻撃そのものより、攻撃に気づく手段を先に潰されるほうが実害としては大きい。ここは意識しておきたいところです。

深刻度が5.1と8.8に割れているのはなぜか

同じCVEなのに、参照する情報源によってスコアが大きく異なります。

差が出ている核心は「影響（Impact）をどこまで見積もったか」の一点です。

• QNAPの評価：機密性への影響なし（VC:N）、完全性への影響は「低」（VI:L）、可用性への影響なし（VA:N）。つまり「設定の一部を書き換えられる程度」という見立てです。
• NVDの評価：機密性・完全性・可用性のすべてが「高」。つまり「対象アプリでできる操作は一通り奪われうる」という、影響を広く取った見立てです。

加えてCVSS v3とv4という評価体系そのものの違いもあります。v4は利用者の関与を「不要（UI:N）／受動（UI:P）／能動（UI:A）」の3段階に分けるなど、成立条件をv3より細かく反映します。ただしこの件で5.1と8.8の差を生んでいるのは、ほぼ影響（Impact）の見積もりの違いです。FIRSTの計算式で採点し直すと、QNAPと同じ影響の見立て（機密性なし・完全性「低」・可用性なし）はv3.1でも4.3、NVDと同じ見立て（すべて「高」）はv4.0でも8.6となり、評価体系の違いだけで動く幅は1点に届きません（むしろ影響を狭く見た場合は、v4のほうが高く出ます）。この2つの数字は同じものさしで測られていませんが、差のほとんどは「影響をどこまで広く見積もるか」という判断の差だと押さえておくのが実務的です。

実務ではどちらを採るべきか

結論から言えば、どちらか一方を「正解」として選ぶのではなく、自社の設置状況で補正するのが妥当です。判断材料を整理します。

• 製品を最もよく知るのはベンダー（CNA）です。実装上どこまで操作できるかを踏まえた5.1という数字には、それなりの合理性があります。
• 一方で、ベンダー評価は自社製品への評価であるという構造的な性質は頭に置いておくべきです。第三者であるNVDの評価を併せて見る意味はここにあります。
• 最終的に効くのは環境要因です。「NASの管理画面がインターネットから到達可能か」「管理者が同じブラウザで日常的にWeb閲覧やメール確認をしているか」——ここが該当するなら、公表スコアが5.1でも自社にとっての優先度は上がります。

公表スコアはあくまで出発点です。CVSSの読み方そのものはCVSSとは？脆弱性の深刻度を評価する仕組みと使い方で解説しています。また、評価者によって深刻度が割れる事象はこの件に限りません（例：Firefox for Androidの情報漏えい脆弱性）。「スコアが割れていたら、環境要因で自社の数字を出す」という進め方を、一度手順として決めてしまうのが現実的だと感じます。

現場目線の課題──NASは「影の資産」になりやすい

正直なところ、この種の脆弱性で一番厄介なのは技術的な難しさではありません。「そのNAS、誰が管理しているんですか」に即答できないことのほうです。

NASは導入のハードルが低く、部門が自前で買って設置してしまうことが珍しくありません。設計部門の図面共有用、営業部門のカタログ置き場、工場の検査データ保管用——情シスの資産台帳に載らないまま、重要データを何年も抱えている個体があります。ファームウェアの更新どころか、初期パスワードのまま動いていることさえあります。

そのためアドバイザリが出ても、そもそも台数を把握していないので影響範囲が算定できない。「うちは何台あって、何台が未対応なんだ」と聞かれて答えられない。限られた人員で全社の機器を見ている情シスにとって、この「見えていない機器」のもどかしさは相当なものだと思います。

NASが狙われる理由もはっきりしています。データが集約されていて、バックアップの保存先にもなっていることが多いからです。ランサムウェアの攻撃者にとっては、本番データとバックアップを一度に押さえられる格好の標的です。CSRF単体の深刻度が中程度でも、NASという資産の重要度を掛け合わせれば、優先度の判断は変わってきます。

情シスはどうすべきか

個別の対策チェックリストを長々と並べるより、公的機関が整備している指針を土台にするほうが確実です。以下を出発点にしてください。

• IPA 脆弱性対策：脆弱性情報の入手から対応までの流れがまとまっています。「アドバイザリが出たとき誰が何をするか」を決めていない組織は、まずここから。
• 中小企業の情報セキュリティ対策ガイドライン：資産の把握とルール整備が体系的に整理されています。NASのような「部門が勝手に買った機器」を台帳に載せる作業の根拠として使えます。
• IPA ランサムウェア対策特設ページ：NASを含む共有ストレージの保護とバックアップの考え方に直結します。
• 対策のしおり：CSRFのように利用者の操作が成立条件になる攻撃は、技術対策だけでは塞ぎきれません。「心当たりのないリンクを開かない」という地道な啓発を、管理者権限を持つメンバーにこそ徹底したいところです。

そのうえで、今回の件で具体的に効く運用上の勘所を3つ挙げます。

• NAS管理画面をインターネットに直接公開しない：外部アクセスが必要ならVPNや専用経路を挟む。CSRFに限らず、NASを守るうえで最も効く一手です。
• 管理者の作業ブラウザを分ける：管理画面用と日常のWeb閲覧・メール用を分離し、作業後はログアウトする。CSRFは「ログインしっぱなし」が前提なので、これだけで成立条件を崩せます。
• App Centerのアプリ更新を運用に組み込む：本体ファームウェアだけでなくアプリも更新対象であることを、定期点検の手順に明記する。

中長期の視点

「深刻度は中程度、修正版は提供済み、悪用報告なし」という案件は、放置されやすい典型です。緊急ではないので後回しにされ、そのまま忘れられる。半年後に別の重大な脆弱性が出たときに「そういえば前の更新もしていなかった」と気づく——このパターンが本当に多い。

だからこそ、個別対応の巧拙より、脆弱性情報を受け取ってから対応完了までを回す「型」を持っているかどうかが効いてきます。対象資産の特定、優先度の判断、対応期限の設定、完了確認。この流れが手順として存在していれば、中程度の脆弱性も自動的に処理されます。考え方は脆弱性管理とは？プロセスと情シスの進め方を解説で整理しています。あわせて、部門が独自に機器を買える状態そのものにも手を打ちたいところです。禁止するだけでは隠れて買われるだけなので、「買ってもいいが情シスに登録する」という落としどころを作るほうが、結果的に可視化は進みます。

まとめ

1. QNAP NASの標準アプリ Notification Center にCSRF脆弱性（CVE-2025-58468）。修正版は 1.10.0.3291 以降で、App Centerから更新できます。QNAP製NASを使っているなら原則対象と考えてください。
2. 深刻度はQNAP評価5.1（v4.0）とNVD評価8.8（v3）に割れています。影響の見積もり方と評価体系の違いによるものです。公表スコアを鵜呑みにせず、管理画面の露出状況と管理者の運用実態で自社の優先度を出してください。
3. 本質的な課題はNASの可視化。台帳に載っていないNASは更新対象にもなりません。今回のアドバイザリを、社内のNASを棚卸しするきっかけとして使うのが最も費用対効果の高い動き方です。

出典

• QNAP Security Advisory QSA-26-13: Vulnerability in Notification Center
• JVNDB-2026-027135 QNAP SystemsのNotification Centerにおけるクロスサイトリクエストフォージェリの脆弱性
• CVE Record: CVE-2025-58468
• NVD: CVE-2025-58468
• IPA 脆弱性対策