Veeamの閲覧ロールからコード実行の可能性｜12.3.2 P4への更新を確認

Veeamは2026年10月6日、Backup & Replication 12.3.2 P4で修正した複数の脆弱性をKB4934で公表しました。CVE-2025-64393では、Backup Viewerロールを持つ低権限の利用者が、Mount Serviceを通じてバックアップサーバーでリモートコードを実行できる可能性が説明されています。CVSS v4.0は9.4、Criticalです。

本記事の情報確認日は10月18日です。CVE識別子に2025が含まれていても、今回参照したKBの公表日は2026年10月6日です。識別子の年を公表日へ読み替えません。告知から実際の悪用は確定できず、18日に新しい被害が発生したと報じる記事でもありません。

出典：Veeam：KB4934 12.3.2 P4の脆弱性修正。

バックアップの保存先ではなく管理サーバーの修正

この問題の説明は、信頼できないデータの安全でないデシリアライズに関するものです。一般にデシリアライズは、保存や通信のための形式をプログラム内の構造へ戻す処理です。単にファイルの内容を読むだけのつもりでも、受け取った内容の扱い方によって実行境界へ影響することがあります。

今回の公式説明で重要なのは、Backup Viewerという役割が前提になる点です。インターネットから誰でも認証なしで成立する問題とは説明されていません。一方、画面上で閲覧するためのロールだから影響は読み取りだけ、と判断することもできません。

保存物を削除から守るObject Lockなどの対策と、この製品の脆弱性修正は別です。保存先に強い保護があっても、管理サーバーのコード実行に関する問題が解消された証拠にはなりません。バックアップのデータ、管理サービス、利用者の権限を分けて確認します。

対象ビルドと13系を混同しない

KB4934は、掲載する脆弱性が12.3.2 P3のbuild 12.3.2.4854とそれ以前の12系に影響し、12.3.2 P4のbuild 12.3.2.4934で解決したと説明しています。また、13系のビルドはこれらの問題の対象外としています。

台帳に12.3.2とだけ書かれている場合、P3とP4の違いを判断できません。本サイトでは、画面上の製品名、完全なビルド番号、管理サーバー名、構成、担当を対応付けることを提案します。修正ファイルを保管した場所ではなく、稼働している実体を確認してください。

対象外の13系でも、すべての将来の問題がないという意味ではありません。今回のKBに対する判定と、通常の保守状況は別に管理します。12系から13系への移行を検討する場合も、本記事だけで互換性や移行経路を判断せず、公式手順と利用中の構成を確認してください。

同じ閲覧ロールに関わる別の問題もある

KBはCVE-2026-93026として、Backup Viewerを持つ認証済み利用者がEnterprise Managerのmaster keyを変更・削除し、保存されたウイルス対策更新用の資格情報を読み取り・上書きできる問題も説明しています。この評価はCVSS v4.0で6.1、Mediumです。

二つを一つの脆弱性として扱わないでください。コード実行、鍵の改変、資格情報への影響は、確認すべき資産と復旧の判断が異なります。本記事の構造化スコア9.4は、CVE-2025-64393の評価です。KBにあるすべての問題が同じスコアだという意味ではありません。

運用上は、対象の鍵や資格情報を扱う担当を把握し、必要な場合に交換・復旧できるかを確認します。ここで公開されていない漏えい事実を前提に、一斉変更を指示するものではありません。不審な事実がある場合の対応と、予防的な権限点検を分けます。

閲覧権限は付与先と接続元をセットで見直す

本サイトの提案は、Backup Viewerを誰へ、何のために付与しているかを棚卸しすることです。監査担当、運用担当、委託先、過去の担当者を分け、現在も必要かを確認します。共有アカウントでは、個々の操作と利用者を追えないことがあるため、管理方法も点検します。

ログインできることと、その接続元から管理サービスへ到達する必要があることは別です。管理端末、踏み台、VPNなどの正規経路を把握し、不要な接続を減らします。ただし通信制限だけでこのCVEが修正済みになるわけではなく、更新を先延ばしにする理由にはしません。

権限を外す際は、監査や日常確認が止まらない代替手段も用意します。全員へ管理者権限を渡して解決するのではなく、必要な情報を限定して確認できる経路を考えます。例外が残る場合は所有者と見直し期限を記録してください。

更新前に復元の判断材料を保全する

バックアップ製品の更新では、その製品の構成をどう復旧するかも重要です。設定、現在のビルド、ジョブ、接続先、必要なバックアップと公式の前提条件を作業前に確認する方法を提案します。運用中のジョブと保守作業が衝突しない時間帯を決めます。

構成情報の保全では、秘密の値を作業票へ書き出す必要はありません。どこで管理し、誰が復旧時に取り出せるかを記録します。バックアップサーバーと同じ資格情報だけでしか復旧手順へ入れない場合には、緊急時のアクセス方法も確認してください。

侵害が疑われる環境では、単に更新して戻す手順が適切とは限りません。調査材料を保全し、組織の対応担当と隔離・再構築の要否を決めます。更新による予防と、侵害後の信頼性回復を同じ作業として閉じないことが大切です。

ジョブの成功と復元の成功は別に検証する

更新後は、代表するジョブが動いたこと、保存先へ到達したこと、保持設定が意図どおりであることを確かめます。過去のジョブに成功マークがあるだけで、新しいビルドでの処理が成功したとは判断しません。対象時刻と稼働版を対応付けて記録します。

その上で、許可された隔離環境へ少量のデータを復元する方法を提案します。取り出せることだけでなく、内容が読めることと、復元先が本番の通信や通知へ誤接続しないことを確認します。試験のために本番データを無制限に複製する必要はありません。

復元に失敗した場合は、更新の影響か、以前からの設定・資格情報の問題かを分けて調べます。更新前に基準となる試験結果があると比較できます。復元が重要な業務では、更新後の確認担当と再開の承認者も事前に決めておきます。

委託先へ依頼するときは閲覧ロールの範囲も確認する

自社でバックアップサーバーを操作できない場合、保守会社へ「パッチは入っていますか」と尋ねるだけでは、どの製品と環境の話かが曖昧になります。本サイトでは、KB4934、対象ビルド、管理対象のサーバー、更新後の完全なビルド番号を指定して確認する方法を勧めます。

同時に、自社と委託先のどちらがBackup Viewerの付与先を管理するのかを確認します。契約終了した担当者や、過去の監査のために一時付与したアカウントが残るなら、必要性を判断する責任者を決めます。技術的な更新と利用者の棚卸しは担当が違っていても、一つの対応票で進捗を追えます。

復元試験を委託する場合は、試験対象、復元先、取り扱うデータ、終了後の削除を事前に合意します。試験が成功したという報告には、どの保存時点から何を復元し、どこまで内容を確認したかを含めてもらいます。単に管理画面へログインできたことを、復元成功と表現しないようにします。

資格情報の交換が必要になったときも、誰が秘密の値へ触れ、どのサービスを止める可能性があるかを整理します。侵害が疑われる端末や管理サーバーへ新しい資格情報を先に入力せず、信頼できる作業環境を確保する判断を対応担当と進めてください。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
稼働版	管理サーバーごとの完全なビルド	12系の修正済み状態を確認
利用者	Backup Viewerの付与先と目的	過去の一時付与や委託終了を見直す
変更準備	構成・ジョブ・戻し方	秘密を広く複製せず復旧の材料を保全
保存処理	更新後の対象ジョブと保存先	過去の成功表示を更新後の結果に使わない
復元試験	保存時点・隔離先・検証内容	取り出せることと読めることを確認

保守期限まで含めて更新を継続できる状態にする

KB4934は12系のサポート終了日を2027年2月28日と案内しています。これは今回の修正を待たせるための期限ではありません。提供済みのパッチへの対応を進めながら、次の系列へ移行する準備を別の計画として管理する必要があります。

本サイトでは、直近の修正対応と中期の移行を分けて、構成、契約、互換性、試験環境、担当を確認することを勧めます。保守期限の直前になって接続する装置やライセンスの条件が分からなくなると、脆弱な旧環境を使い続ける原因になります。

今回の対応の要点は、保存物があることを安心材料にし過ぎないことです。保存を管理する基盤の版と権限を更新し、実際に復元できることを確かめて初めて、障害や侵害の後に使える備えとして説明できます。