Dell Cloud DRに脆弱性5件、最大CVSS9.1

Dellの災害復旧製品「Dell Cloud Disaster Recovery（Cloud DR）」に、OSコマンドインジェクションを含む5件の脆弱性が公表されました（アドバイザリ DSA-2026-353、2026年8月24日公開）。最大深刻度はCVE-2026-70419のCVSS v3.1基本値9.1（Critical）。影響を受けるのはバージョン20.2およびそれ以前で、修正版は20.3です。回避策は案内されておらず、対応はアップデート一択になります。

ただし、これを「未認証RCE」として経営層に説明すると誤りになります。5件はいずれも認証済みの権限を前提とした脆弱性で、4件が高権限、1件が低権限を必要とします。それでも後回しにできないのは、この製品が守っている対象がバックアップとDR（災害復旧）そのものだからです。

この記事でわかること

  • Dell Cloud Disaster Recoveryとは何をする製品で、どの製品に組み込まれて動いているか
  • 公表された5件のCVEと深刻度、「高権限が必要」なのにCVSS9.1が付いた理由
  • 自社が該当するかを確認する道筋
  • 認証が必要な脆弱性を、それでも優先すべきかどうかの判断材料

Dell Cloud Disaster Recoveryとは何者か

Dell Cloud Disaster Recovery（CDR）とは、オンプレミスで取得した仮想マシンのバックアップをパブリッククラウドへ複製し、災害時にクラウド上でVMを起動して業務を継続させるための災害復旧ソリューションです。

Dellの公式ドキュメントによれば、オンプレミスのAvamarおよびPowerProtect DD（旧Data Domain）と連携し、VMイメージバックアップをAWS、AWS GovCloud、Microsoft Azureのオブジェクトストレージへ転送します。クラウド側での復旧・フェイルオーバーに加え、DRテストや、オンプレミスのVMware vCenterへ戻すフェイルバックまでを担います。使うのは情報システム部門やインフラ運用部門で、DRサイトをもう1拠点構える代わりに復旧先をクラウドに置く、というBCP（事業継続計画）の現実解として導入されます。

「うちは導入していない」と即断できない理由

この製品を単体で発注した記憶がなくても、無関係とは限りません。Dellの公式マニュアルには、Cloud Disaster RecoveryがPowerProtect Data Managerに統合されている旨が明記されています。また、Avamar＋PowerProtect DD環境向けには「Data Domain Cloud DR for Avamar」という名称で提供されており、Dell公式サポートサイト上の製品パスもこの名前になっています。既存のDellデータ保護基盤の一機能として、意識しないまま動いているケースがあり得るということです。資産管理台帳に「Dell Cloud Disaster Recovery」という行がないことは、該当しないことの証明にはなりません。

該当判定の入り口は次の3つです。

  • PowerProtect Data Managerを使っている場合、Cloud DR（Cloud Disaster Recovery）機能を有効化しているか
  • Avamar＋PowerProtect DD構成で、クラウドへのDRコピーを運用しているか
  • Dellのサポートポータル上で、自社資産にCloud Disaster Recoveryの登録があるか。ある場合、そのバージョンが20.2以前か

バージョンが自力で確認できない場合は、Dellのサポート窓口または保守ベンダーに「DSA-2026-353の該当有無」として問い合わせるのが最短です。アドバイザリ番号を指定すると、確認の往復が減ります。

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

Dellが公開したアドバイザリDSA-2026-353の内容は次のとおりです。いずれも修正版は20.3で、個別の回避策（ワークアラウンド）は案内されていません。

CVE番号 種別 CVSS v3.1 必要な権限 想定される影響
CVE-2026-70419 OSコマンドインジェクション 9.1（Critical） 高権限 OSレベルでの任意コマンド実行
CVE-2026-71171 OSコマンドインジェクション（REST API） 7.2 高権限 リモートからの任意コード実行
CVE-2026-68865 リモートコード実行 7.2 高権限 リモートからの任意コード実行
CVE-2026-71173 パストラバーサル 6.5 高権限 ファイルパス検証不備による完全性・可用性への影響
CVE-2026-71172 SSRF（サーバサイドリクエストフォージェリ） 4.3 低権限 限定的な情報の窃取

なぜ「高権限が必要」なのにCVSS9.1なのか

CVE-2026-70419のCVSSベクタは CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H です。攻撃に高権限（PR:H）を要するにもかかわらず9.1という値が付いているのは、スコープが変更される（S:C）と評価されているためです。

CVSSにおけるスコープ変更とは、脆弱なコンポーネントの権限境界を越えて、別の管理下にあるリソースにまで影響が及ぶことを指します。Cloud DRの管理機能の内側で完結せず、その下で動くOSや周辺の基盤側にまで手が伸びる、という読み方になります。残る4件はスコープ変更なし（S:U）で、7.2〜4.3に収まっています。

高権限が必要なら、対応は後回しでよいのでしょうか

いいえ。バックアップ／DR基盤の管理者権限は、ランサムウェア攻撃者が最優先で奪いにくる資産だからです。

暗号化の前にバックアップを潰す、という手順は珍しくありません。復旧手段を先に断てば身代金の交渉力が上がるためです。攻撃者にとってDR基盤の管理者アカウントは「最後に取るご褒美」ではなく「最初に取りにいく前提条件」に近い位置づけになります。

この視点で読み直すと、今回の5件は「侵入されなければ関係ない脆弱性」ではなく、管理者権限が奪われた後に、被害をDR基盤の内側から基盤全体へ拡大させる踏み台と評価すべきものです。管理画面で許された操作の範囲を越えてOSコマンドを実行できてしまう——それがCVE-2026-70419の意味するところです。権限設計の考え方は最小権限の原則とは？情シスが押さえる基本と実務も併せてご覧ください。

想定されるリスクと、優先度の判断材料

優先度を決めるうえで見るべきは、深刻度の数字よりも「そのCloud DRの管理面が、どこから触れる状態に置かれているか」です。

  • 管理インターフェースの露出範囲：管理用セグメントに閉じているか、業務ネットワークから到達できてしまうか。5件すべてがAV:N（ネットワーク経由）である以上、到達性がそのまま実質的な露出面になります。
  • REST APIの利用状況：CVE-2026-71171はREST API経路の脆弱性です。自動化スクリプトや監視ツールからAPIを叩いている環境では、そのAPIトークンの保管状況もあわせて棚卸ししてください。
  • 認証情報の共用：DR基盤の管理者アカウントが、他システムと同じパスワードやID基盤を使っていないか。ここが共用だと、他システムの侵害がそのままDR基盤の侵害になります。

なお、バックアップ製品そのものが狙われる流れは今回に限りません。当サイトでもVeeam ONEに脆弱性6件 CVSS10.0の未認証RCEやDell PowerProtect脆弱性359件を修正、更新の要点を取り上げてきました。「守る側の道具」が攻撃対象になるという構図は、もはや例外ではなく前提です。

現場目線の課題

正直なところ、DR基盤は最も更新が後回しになりやすい領域です。理由ははっきりしていて、止まっている影響が普段は見えないからです。業務システムの更新は「動かないと困る人」がすぐ声を上げますが、DR基盤は数か月放置しても誰も困りません。困るのは、実際に災害やランサムウェアが起きたその日だけです。

加えて、Cloud DRのように「別製品の一機能として入ってくる」コンポーネントは、資産管理台帳から抜け落ちます。台帳に載っているのは「PowerProtect Data Manager」であって、その内側で動くCloud DRのバージョンまでは追えていない、という状態は珍しくありません。今回のアドバイザリは、台帳の粒度を見直す口実として使うのが現実的だと考えます。

更新作業そのものの心理的な重さもあります。バックアップ基盤の更新は「作業中に障害が起きたらバックアップが取れない」という不安と隣り合わせで、担当者はどうしても保守ベンダーの立ち会いを待ちがちです。だからこそ、アドバイザリが出た日のうちに保守窓口へ日程を投げておく、という段取りだけでも遅延はかなり縮みます。

情シスはどうすべきか

個別の手順書を自前で作り込むより、公的機関が整備した指針に沿って全体を点検するほうが確実です。

あわせて、特権アカウントを扱う担当者への地道な啓発も欠かせません。DR基盤の管理者権限は、フィッシング1通で失われうるものです。技術的な更新と同じだけの重みで、日常の運用習慣にも目を向ける必要があります。

中長期の視点：同じ製品で1年に2度目

見落としたくないのは、この製品でOSコマンドインジェクションが公表されたのが初めてではないという点です。2025年9月23日には、同じくCloud Disaster Recoveryに対してDSA-2025-354（CVE-2025-43943、CVSS 6.7）が公開されており、これもOSコマンドインジェクションでした。修正版は19.20でした。

注目すべきは深刻度の推移です。2025年の案件は攻撃元がローカル（AV:L）に限られていましたが、今回はネットワーク経由（AV:N）に変わり、スコープ変更まで伴っています。同種の弱点が、より外側から届く形で残っていたことになります。

この製品を運用しているなら、単発の更新で終わらせず、Dellのセキュリティアドバイザリを定期的に確認する運用に組み込むほうが安全です。年に1回は同種の指摘が出うる、という前提で予定を組んでおくのが現実的でしょう。

まとめ

  1. Dell Cloud Disaster Recovery 20.2以前に脆弱性5件。修正版は20.3（DSA-2026-353、2026年8月24日）。最大はCVE-2026-70419のCVSS 9.1で、回避策は案内されていません。
  2. 単体導入の記憶がなくても該当しうる。Cloud DRはPowerProtect Data Managerに統合されており、Avamar＋PowerProtect DD環境では「Data Domain Cloud DR for Avamar」として動いています。台帳の製品名だけで判断しないでください。
  3. 「高権限が必要」は後回しの理由になりません。DR基盤の管理者権限は攻撃者が最初に狙う資産であり、これらの脆弱性は侵害後の被害拡大を加速させます。

出典

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