--- title: "Synology DSM 脆弱性 SA-26:19：CVSS 9.8の修正版と版の確認・更新手順" url: "https://www.issoh.co.jp/tech/details/19735/" published: 2026-11-14 updated: 2026-11-14 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Synology DSM 脆弱性 SA-26:19：CVSS 9.8の修正版と版の確認・更新手順 Synologyは2026年11月10日、DSMの脆弱性をまとめた2本のアドバイザリを公開しました。Critical のSynology-SA-26:19には、認証なしでファイルの読み書きを許すCVSS 9.8のSQLインジェクションが含まれるという内容です。この記事では、DSM 7.4・7.3・7.2.2・7.2.1の修正版、手元のNASの版を修正版と照合する方法、更新までの間に外部公開のポートを確かめる手順を整理します。内容は11月14日時点で公開されている一次情報にもとづきます。 ## まとめ：Synology DSMの脆弱性は修正版への更新が唯一の対策、通知待ちにしない Synologyは回避策を「None」としており、塞ぐ手段はDSMの更新だけです。修正版は7.4.1-90080-1、7.3.2-86009-5、7.2.2-72806-10、7.2.1-69057-13で、いずれも10月12日に配信が始まっています。ただし、リリースノートには「NASが更新を通知しない場合がある」と書かれています。通知が来ていないことを、対応済みの根拠にしないでください。 まず版番号を見ます。修正版より古ければ、今週中に更新します。管理画面やrsyncをインターネットへ出しているNASは、その日のうちに優先してください。台数が多く点検が追いつかない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で公開範囲と設定の確認を受け付けています。 ## Synology-SA-26:19とSA-26:18で公表されたDSMの脆弱性と修正版 同じ日に公開された2本は、深刻度と対象の系列が異なります。[Synology-SA-26:19](https://www.synology.com/ja-jp/security/advisory/Synology%5FSA%5F26%5F19)はCriticalで2件、[Synology-SA-26:18](https://www.synology.com/ja-jp/security/advisory/Synology%5FSA%5F26%5F18)はImportantで25件を扱います。 ### CVE-2026-76954とCVE-2026-85101の深刻度と攻撃の前提条件 CVE-2026-76954は、DSMのAuth APIにあるSQLインジェクションです。分類は[CWE-89](https://cwe.mitre.org/data/definitions/89.html)で、CVSS 3.1の基本値は9.8。ベクトルは`AV:N/AC:L/PR:N/UI:N`で、ネットワーク越しに、認証も利用者の操作もなしに攻撃が成り立つ評価です。影響は任意ファイルの読み書きとサービス妨害とされています。 CVE-2026-85101は、rsyncの認証回避です。分類は別経路による認証回避の[CWE-288](https://cwe.mitre.org/data/definitions/288.html)で、基本値は8.6。こちらも認証は不要で、特定ファイルの読み取り、任意ファイルの書き込み、限定的なサービス妨害を許します。書き込みの影響が「高」と評価されている点に注意が要ります。 悪用の報告は、11月14日時点でアドバイザリに記載がありません。CISAの[KEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)（11月10日版）にも2件は載っていません。NVDには11月12日にCVE-2026-76954が登録され、分析待ちの状態です。 ### DSM 7.4・7.3・7.2.2・7.2.1の系列別に見る修正版の対応表 | 系列 | SA-26:19の修正版 | SA-26:18の修正版 | 配信日 | | --------- | ---------------- | --------------- | ---------- | | DSM 7.4 | 7.4.1-90080-1以降 | 7.4.1-90080-1以降 | 2026-10-12 | | DSM 7.3 | 7.3.2-86009-5以降 | 7.3.2-86009-5以降 | 2026-10-12 | | DSM 7.2.2 | 7.2.2-72806-10以降 | 対象表に記載なし | 2026-10-12 | | DSM 7.2.1 | 7.2.1-69057-13以降 | 対象表に記載なし | 2026-10-12 | 画面上の表記は「7.4.1-90080 Update 1」のように、末尾の数字がUpdateの番号になります。配信日は[DSMのリリースノート](https://www.synology.com/en-global/releaseNote/DSM)で確認した公開日です。4本とも修正内容は「Fixed security vulnerabilities.」の1行だけでした。 ### SA-26:18の25件のうち認証なしで届く4件と2段階認証の回避 SA-26:18の多くは、ログインできる利用者を前提にしています。認証なしで届くのは、nfsdのサービス妨害（CVE-2026-18633・7.5）、WebDAV APIの認証欠落による特定ファイルの読み取り（CVE-2026-15198・6.5）、Security Advisorの認可不備（CVE-2026-124993・5.3）、synoscgiのサービス妨害（CVE-2026-85098・5.3）の4件です。 見落としやすいのが、OTPの認証回避（CVE-2026-18596・8.1）です。有効な資格情報を持つ攻撃者が対象とされており、漏れたパスワードと組み合わさると2段階認証が歯止めになりません。社員のパスワード使い回しを把握しきれない組織ほど、この1件を重く見てください。認証済みの利用者が任意ファイルを読み書きできるSSOAuth・Sharing API・Auth APIの3件（いずれも8.8）は、退職者や共用アカウントが残る環境で効いてきます。 ## 修正版は10月12日に配信済み、それでも通知が来ないNASが残る理由 アドバイザリの公開より約4週間早く、修正版は配られていました。自動更新に任せている組織では「もう当たっているはず」と考えがちです。リリースノートの注意書きは、その前提を崩します。 ### リリースノートに書かれたNASへ更新を通知しない2つの条件と地域差 4本のリリースノートの冒頭には、更新が通知されない理由が2つ書かれています。1つは、地域ごとに配信の時期がずれ、まだ届いていない場合です。もう1つは「DSMが更新しなくても問題なく動いている」場合で、システムがサービスの状態と設定を評価して、更新の要否を決めるとされています。 後者は、セキュリティ修正であっても、評価の結果しだいで通知が出ない可能性を示します。通知の有無ではなく、版番号で判定するのが確実です。どのNASに何の版が入っているかを台帳で持っていない場合は、[パッチ管理でKEVを使って優先度を決める手順](https://www.issoh.co.jp/tech/details/19309/)の考え方で、NASも管理対象に加えてください。 ### DS918+やDS218jなど7.4.1の通知対象外となる旧機種の扱い 7月23日公開の7.4.1-90080のリリースノートには、この版の更新通知を受け取らず、各機種に適した版に留まるモデルが列挙されています。DS918+、DS718+、DS218+、DS216j、DS218j、DS418jなど、中小企業の事務所でいまも見かける機種が含まれます。これらは[ダウンロードセンター](https://www.synology.com/ja-jp/support/download)から手動で入れない限り、7.4.1へ上がりません。 こうした機種がどの系列に留まっているかは、個体ごとの更新履歴で変わります。系列ごとに修正版が出ているので、まず版番号で系列を確かめ、その系列の修正版を当てます。ただし前章の表のとおり、SA-26:18の対象表に7.2系は載っていません。7.2系の利用者は、SA-26:18の25件への手当てが示されていない状態です。 ## 手元のNASでDSMの版番号を確かめ、修正版と照合する2つの方法 台数が数台なら画面で、10台を超えるならSSHでの一括確認が向いています。どちらも読み取りだけで、サービスには影響しません。 ### コントロールパネルの情報センターでDSMの版番号を読む画面の操作 Synologyの[DSMのバージョン確認方法](https://kb.synology.com/ja-jp/DSM/tutorial/How%5Fto%5Fcheck%5FDSM%5Fversion%5Fon%5FSynology%5FNAS)では、3つの経路が案内されています。 1. \[コントロール パネル\] > \[アップデートと復元\] > \[DSM アップデート\] で、現在のDSMバージョンを見る 2. \[コントロール パネル\] > \[情報センター\] > \[全般\] で、DSMのバージョンを見る 3. 同じLANにあるPCのブラウザでfind.synology.comを開き、一覧の版を見る 3番目はサインインが要らないため、管理者のパスワードが分からなくなった古いNASの洗い出しに向いています。表示された版を、前章の対応表と比べてください。 ### SSHで/etc.defaults/VERSIONを読み修正版と比べるシェルスクリプト SSHを有効にしているNASでは、版の情報が書かれたファイルを読んで判定できます。次のスクリプトは、SA-26:19の修正版と照合した結果を1行で出すものです。値は11月14日時点のアドバイザリにもとづきます。 ``` #!/bin/sh # DSMの版を読み、Synology-SA-26:19の修正版と照合する（2026-11-14時点） . /etc.defaults/VERSION b="$buildnumber" s="${smallfixnumber:-0}" echo "現在の版: ${productversion}-${b} Update ${s}" result="要更新" if [ "$b" -gt 90080 ]; then result="修正済み" elif [ "$b" -eq 90080 ] && [ "$s" -ge 1 ]; then result="修正済み" elif [ "$b" -eq 86009 ] && [ "$s" -ge 5 ]; then result="修正済み" elif [ "$b" -eq 72806 ] && [ "$s" -ge 10 ]; then result="修正済み" elif [ "$b" -eq 69057 ] && [ "$s" -ge 13 ]; then result="修正済み" elif [ "$b" -lt 69057 ]; then result="対象表にない旧版（修正版なし）" fi echo "SA-26:19: ${result}" ``` ビルド番号が同じ系列の中でUpdateの番号を比べ、7.4.0や7.3.1のように修正版の系列より古いビルドは「要更新」と判定します。このファイルのキー名は、Synologyの公開文書には説明がありません。判定が画面の表示と食い違ったときは、情報センターの表示を正としてください。 ## DSMを修正版へ更新する手順と、更新前に済ませておく互換性の確認 修正版はすべて再起動を伴います。共有フォルダを業務で開いている時間帯は避け、利用者へ停止を知らせてから進めます。 ### 更新前の控え：構成のバックアップと以前の版へ戻せないDSMの確認 7.4.1-90080のリリースノートには、適用後に以前の版へ戻せないと明記されています。7.2系から7.4.1へ系列をまたいで上げる場合は、パッケージの互換性を先に確かめてください。Updateの番号を上げるだけなら、系列は変わりません。 ランサムウェアへの備えとして、スナップショットとオフラインの世代が揃っているかも、この機会に確かめます。設定の具体例は[NASのランサムウェア対策とスナップショット・世代の設定](https://www.issoh.co.jp/tech/details/19293/)にまとめたとおりです。今回の欠陥は任意ファイルの書き込みを許すため、侵害されたときに戻せる世代があるかどうかで被害の大きさが変わります。 ### 通知が来ないときに機種別のアーカイブから.patを入れる手動更新 更新が表示されない場合は、Synologyのアーカイブから機種に合う更新ファイル（.pat）を取得し、\[DSM アップデート\] の手動更新で読み込みます。修正版の置き場所は、[7.4.1-90080-1](https://archive.synology.com/download/Os/DSM/7.4.1-90080-1)、[7.3.2-86009-5](https://archive.synology.com/download/Os/DSM/7.3.2-86009-5)、[7.2.2-72806-10](https://archive.synology.com/download/Os/DSM/7.2.2-72806-10)、[7.2.1-69057-13](https://archive.synology.com/download/Os/DSM/7.2.1-69057-13)です。 ファイル名には機種名が入ります。別の機種向けのファイルを選ぶと適用できないので、型番を照らし合わせてから入れてください。更新後は、前章のスクリプトか情報センターで版番号をもう一度確かめます。ここまでやって、初めて対応済みと言えます。 ## 更新までの間に塞ぐ露出：DSM管理画面とrsyncの873番ポート アドバイザリが示す対策は更新だけで、ここで述べる手当ては欠陥を直すものではありません。更新までの数日に、外から届く経路を減らすための措置です。LANの内側からの攻撃は防げません。 ### nmapで社外から5000・5001・873番の開放を確かめるコマンド Synologyの[ネットワークポートの一覧](https://kb.synology.com/ja-jp/DSM/tutorial/What%5Fnetwork%5Fports%5Fare%5Fused%5Fby%5FSynology%5Fservices)によると、DSMの管理画面は5000番（HTTP）と5001番（HTTPS）、rsyncは873番（SSHで暗号化する場合は22番）、WebDAVは5005番と5006番を使います。ルーターのポート転送で、これらが外へ出ていないかを社外の回線から確かめます。 ``` # 社外の回線（モバイル回線など）につないだPCから、事務所のグローバルIPへ実行する nmap -Pn -p 22,873,5000,5001,5005,5006 203.0.113.10 ``` `-p`は調べるポートの指定で、書式は[nmapのポート指定の文書](https://nmap.org/book/man-port-specification.html)にあります。結果が`open`なら外から届く状態です。`filtered`や`closed`の意味は[ポートスキャンの基本](https://nmap.org/book/man-port-scanning-basics.html)で確認できます。自社が管理していないIPには実行しないでください。公開資産の洗い出しを継続的に行う方法は[EASMで外部公開資産を洗い出す手順](https://www.issoh.co.jp/tech/details/19307/)で扱っています。 ### rsyncサービスを使っていないNASで無効化する設定の場所 rsyncの設定は、DSMヘルプの[rsyncの項目](https://kb.synology.com/ja-jp/DSM/help/DSM/AdminCenter/file%5Frsync)にあるとおり、\[コントロールパネル\] > \[ファイル サービス\] > \[rsync\] の \[rsync サービスを有効にする\] です。他のNASや Linux サーバーからのバックアップを受けていないなら、チェックを外します。 外す前に、このNASが別のNASのバックアップ先になっていないかを確かめてください。Hyper Backupの保存先や共有フォルダーの同期、LUNバックアップは、受け側のrsyncを使います。止めると翌朝のバックアップが失敗するため、停止の影響に注意が必要です。使っている場合は無効化せず、ルーターで873番を外へ出さないことと、rsyncの権限設定で許可するIPアドレスを送り元に絞ることで対応します。 ### 管理画面をインターネットへ出さず社外から届く経路へ切り替える DSMの管理画面をポート転送で公開している構成は、今回を機にやめる判断をおすすめします。CVE-2026-76954のように認証前のAPIに欠陥があると、パスワードの強さは関係ありません。社外から管理する必要があるなら、受信ポートを開けない[Cloudflare Tunnelとcloudflaredの設定](https://www.issoh.co.jp/tech/details/8634/)や、端末単位で認証する[Tailscaleのポリシー設定](https://www.issoh.co.jp/tech/details/18058/)へ切り替えます。どちらも、外から5001番へ直接届く経路を消せます。 ## 判断：今週中に更新すべきNASと、買い替えや移行を検討するNAS 対象のNASが修正版より古い以上、更新するかどうかを迷う余地はありません。決めるべきは、いつ止めるかと、更新を受け取れない機種をどう扱うかです。 ### 外部公開しているNASは業務時間内でも更新を優先するポートの条件 前章のnmapで5000番・5001番・873番のいずれかが`open`だったNASは、業務時間中でも再起動を伴う更新を優先します。CVSS 9.8で認証が要らず、修正版の配信から1か月が経っているため、差分から欠陥の場所を突き止められる期間はすでに過ぎていると見るべきです。悪用の報告がまだ無いことは、待つ理由になりません。 外へ出ていないNASは、週内の保守枠で構いません。ただし、社内の端末が1台でも乗っ取られれば、LANの内側から同じ欠陥を突かれます。後回しにするのは数日までです。 ### 7.2系に留まる旧機種を使い続けてよい条件と対応機種へ移行する条件 7.2.1や7.2.2の旧機種は、SA-26:19の修正版を当てれば今回のCriticalの2件は塞げます。一方、SA-26:18の25件について、7.2系への修正版は示されていません。使い続けてよいのは、外部公開がなく、LANの利用者が限られ、更新や廃止の時期が決まっている場合に限ります。 次の条件に1つでも当てはまるなら、7.3以降に対応した機種への置き換えを今年度の予算に入れてください。顧客情報や人事資料を置いている、社外からアクセスする運用がある、管理者が1人しかおらず版の確認が続かない、の3つです。DSMの管理画面に複数のAPIの欠陥が一度に出た今回の公表は、NASを「置いておけば動く箱」として扱う運用の限界を示しています。 ## よくある質問 Synology DSMの脆弱性（SA-26:19とSA-26:18）について、運用の現場で迷いやすい点に答えます。 ### QuickConnectだけで社外から使っている場合も対象ですか？ 対象です。アドバイザリは接続方法で対象を分けておらず、判定の基準はDSMの版だけです。QuickConnectは、ルーターのポートを開けずにDSMのサインイン画面へ社外から届く仕組みなので、管理画面を公開しているのと同じ扱いで更新を優先してください。QuickConnectを止めても、LANの内側からの攻撃経路は残ります。止める措置は、更新までの時間を稼ぐ手段にとどまります。 ### 自動更新を有効にしていれば対応は済んでいますか？ 済んでいるとは限りません。修正版のリリースノートには、地域ごとの配信の遅れと、システムが更新の要否を評価した結果として、通知されない場合があると書かれています。自動更新の設定の有無にかかわらず、情報センターの表示かSSHのスクリプトで版番号を確かめ、修正版以上であることを見てから対応済みとしてください。 ### すでに攻撃を受けたかどうかは調べられますか？ 11月14日時点で、Synologyは侵害の痕跡や判定方法を公表していません。アドバイザリが示す影響はファイルの読み書きとサービス妨害で、具体的な攻撃の手順も示されていません。確認するなら、ログセンターで見覚えのないサインインや、共有フォルダーに知らないファイルが増えていないかを見ます。不審な点があれば、更新の前にディスクの状態を保全し、調査を依頼するほうが原因を追えます。 ### DSM 7.1や6.2を使っているNASはどうすればよいですか？ SA-26:19とSA-26:18の対象表には、7.1と6.2が載っていません。対象外という意味ではなく、修正版が示されていない状態です。機種が7.2.1以降に対応していれば、その系列の修正版まで上げてください。対応していない機種は、外部公開をすべて止め、利用者を絞ったうえで置き換えの時期を決めます。データの移し替えには、世代を残したバックアップを先に用意しておくと安全です。 ### 更新後に元の版へ戻すことはできますか？ 7.4.1-90080のリリースノートには、適用後に以前のDSMへ戻せないと書かれています。系列をまたぐ更新は戻せない前提で、使っているパッケージが新しい版に対応しているかを先に確かめてください。同じ系列の中でUpdateの番号を上げるだけなら、系列が変わらないぶん影響は小さく済みます。迷う場合は、今回の修正版で系列を変えずに塞ぐのが手堅い選択です。 ## 関連記事 - [VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】](https://www.issoh.co.jp/tech/details/18740/)：NASと同じく社外に出る機器の版確認と移行判断を扱います。 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：今回のAuth APIやSharing APIのような認証・認可の欠陥を、自社APIで防ぐ実装です。 - [イミュータブルバックアップとは：S3 Object Lock・Vault Lockの実装手順と保持期間の決め方](https://www.issoh.co.jp/tech/details/18742/)：NASが書き換えられても消されない世代をクラウドに置く方法です。 - [3-2-1ルールとは：AWS Backupのクロスリージョン・別アカウントコピーで組む設定例](https://www.issoh.co.jp/tech/details/19311/)：NASを含めたバックアップ全体の世代の組み方を解説しています。 - [佐賀大学のランサムウェア被害：約8万人分と患者情報に流出の可能性、事務NASの経緯](https://www.issoh.co.jp/tech/details/18097/)：事務NASが暗号化された実際の事案と初動の経過です。 --- 出典: [Synology DSM 脆弱性 SA-26:19：CVSS 9.8の修正版と版の確認・更新手順]()（株式会社一創）