Veeam ONEに脆弱性6件 CVSS10.0の未認証RCE

【更新 2026-08-06】本記事を見直し、修正しました。主な修正点：脆弱性の公表日を一次情報にもとづき修正（Veeam KB4892の公開は2026年8月4日、NVDのCVE公開も同日。2026年7月29日は修正版ビルド13.1.0.7034の提供開始日）。出典欄のKB4892の公開日表記もあわせて修正。

Veeam Softwareは2026年8月4日、バックアップ環境の運用管理・監視製品「Veeam ONE」の脆弱性6件を修正したと公表しました（KB4892。修正版ビルド13.1.0.7034の提供開始は2026年7月29日）。最大深刻度はCVSS v4.0で10.0（Critical）の未認証リモートコード実行（CVE-2026-64633）で、認証なしでコード実行に至る可能性があります。

影響を受けるのはVeeam ONE 13.0.2.6723および、それ以前のバージョン13系ビルドです。修正版は13.1.0.7034。バックアップ基盤に付随する「監視・レポート用の脇役」として運用されがちな製品ですが、置かれている場所を考えると優先度は高く見積もるべきです。

この記事でわかること

• 修正された6件の脆弱性の内容と深刻度
• 自社が対象かどうかの確認ポイント（バージョンの見方）
• バックアップ「監視」製品の脆弱性がなぜ重いのか
• すぐに更新できない場合に現場で考えるべきこと

何が起きたのか

Veeam ONEは、Veeam Backup & Replicationなどのバックアップ環境や仮想基盤を監視し、ジョブの成否・容量・性能をレポートする運用管理製品です。今回はこの製品に対して6件の脆弱性が修正されました。Veeamによれば、1件は社内テストで、残る5件はバグバウンティ経由で報告されたものです。

最も深刻なCVE-2026-64633は、Veeamの説明では「エージェントホスト上での未認証のリモートコード実行」とされています。認証を必要としない点がCVSS v4.0で10.0という最高値につながっています。

修正された脆弱性6件

注目したいのは、上位2件が認証不要である一方、残りの4件が「低権限ユーザー」「高権限ユーザー」を前提としている点です。後者は一見ハードルが高そうに見えますが、レポート閲覧のために営業部門や経営層にまで参照アカウントを配っている環境では、「低権限ユーザー」の数は想像以上に多いことがあります。CVE-2026-64631のSQLインジェクションは、その低権限アカウントが1つ漏れるだけでデータベースの中身に手が届く、という構図です（仕組みはSQLインジェクションとは？仕組みと情シスの対策を解説で解説しています）。

自社は影響を受けるのか

KB4892が影響対象として明示しているのはVeeam ONE 13.0.2.6723および、それ以前のバージョン13系ビルドです。修正版の13.1.0.7034へ更新することで、6件すべてが解消されます。

確認の順序としては、まずVeeam ONEを導入しているかどうか、次にそのビルド番号、という単純な2段階です。ただし後述するとおり、この「導入しているかどうか」の把握が実は一番厄介です。

なお、本記事の執筆時点で公開されているKB4892の記載範囲はバージョン13系です。それ以前のバージョン12系などを使い続けている場合、同等の修正が提供されるかは公開情報からは確認できませんでした。古いバージョンを運用している場合は、サポートライフサイクル上の位置づけも含めてベンダーに確認することをおすすめします。「記載がない＝安全」と読み替えるのは危険です。

パッチ公開後こそ危ないのはなぜ？

修正内容が公開されると、攻撃者が差分を解析して悪用手法を組み立てられるためです。Veeam自身も、脆弱性の公表とパッチ提供が攻撃者によるリバースエンジニアリングを促し、未更新の環境を狙うエクスプロイト開発につながりうる、と注意を促しています。現時点で悪用が確認されていなくても、時間的な猶予は長くないと考えるのが妥当です。

「監視製品」の脆弱性が重い理由

Veeam ONEはバックアップそのものを取る製品ではありません。だからこそ軽く見られがちなのですが、置かれている位置が問題です。監視製品は、監視対象であるバックアップサーバや仮想基盤に対して情報を集められるだけの経路と権限を持ちます。つまりバックアップ環境という「最後の砦」の内側に、常時つながっている構成要素です。

ランサムウェア攻撃で最初に狙われるのはバックアップです。復旧手段を潰されれば、支払い交渉のテーブルに着かざるを得なくなる。IPAの調査でもランサムウェア感染は依然として高い水準にあり（関連：企業のセキュリティ被害実態2026 ランサム感染は45.8%）、バックアップ基盤の防御はもはや「あれば安心」ではなく「攻撃対象そのもの」として扱う段階に来ています。バックアップアプライアンスの大量の脆弱性修正（Dell PowerProtect脆弱性359件を修正、更新の要点）も記憶に新しいところです。

現場目線の課題

率直に言うと、この手の製品でいちばん困るのは「うちに入っているんだっけ？」から始まることです。Veeam ONEはバックアップ担当者や、場合によっては構築を請け負ったベンダーがセットで導入していることがあり、情シスの資産台帳に主役級の製品として載っていないケースが少なくありません。ライセンスの紐づけも本体製品とまとめて管理されがちで、単体では見えにくい。脆弱性情報が出たときに、まず棚卸しから始めなければならないもどかしさがあります（脆弱性管理とは？プロセスと情シスの進め方を解説）。

もう一つは、更新のハードルです。13.0系から13.1系への移行は、月例パッチを当てるような手軽な作業ではなく、事前検証と作業時間の確保が必要になります。バックアップの監視を止めている間にジョブの失敗を見逃さないよう段取りを組む必要もあり、「今日中に全部適用」とはいきません。だからこそ、更新が完了するまでの間に何をするかを決めておくことが実務上は重要になります。

更新までの間に検討できるのは、Veeam ONE Web Clientへのアクセス元をIP制限や管理セグメントに限定すること、レポート閲覧目的で発行している共有リンクや低権限アカウントを棚卸しして不要なものを止めること、そしてVeeam ONEサーバの認証ログ・プロセス起動を監視対象に加えることです。いずれも根本対策ではありませんが、認証不要の攻撃に対しては「そもそも到達させない」ことが効きます。

情シスはどうすべきか

個別の対策手順を自前で並べるより、公的機関がまとめた指針を土台にするほうが確実です。バックアップ基盤の防御は、ランサムウェア対策の文脈で整理されています。

• IPA「ランサムウェア対策特設ページ」：バックアップの隔離・多重化の考え方がまとまっています。今回のような「バックアップ周辺機器の脆弱性」を、感染前提の設計にどう織り込むかの参考になります。
• IPA「中小企業の情報セキュリティ対策ガイドライン」：資産の把握と管理責任の割り当てという、今回の「台帳に載っていない問題」の根っこに効く部分です。
• IPA「セキュリティインシデント対応 机上演習教材」：バックアップが使えない前提で復旧を考える演習は、一度やっておくと優先度の議論が早くなります。

あわせて、バックアップ製品や監視製品を「業務システムではないから」と説明対象から外さないことも大切です。経営層への説明では、この製品が止まる・乗っ取られると復旧計画そのものが崩れる、という一点に絞ると伝わりやすくなります。

中長期の視点

今回の6件は、1件が社内テスト、5件がバグバウンティ経由での発見でした。外部研究者による報告が製品の安全性を押し上げている一方で、報告が増えるほど利用側の更新頻度も上がります。バックアップ関連製品は、いまや「安定して動いていれば触らない」対象ではなく、定期的な更新前提のシステムとして運用計画に組み込む必要があります。

その意味で、年に数回の更新作業をあらかじめ年間計画に置き、停止調整の手続きを定型化しておくことが、結果として最速のパッチ適用につながります。緊急対応の回数を減らすのではなく、緊急対応を平常運転に近づける発想です。

まとめ

• Veeam ONEに6件の脆弱性。最大はCVSS v4.0で10.0のCVE-2026-64633（認証不要のリモートコード実行）で、修正版は13.1.0.7034。
• 影響対象はVeeam ONE 13.0.2.6723および、それ以前のバージョン13系ビルド。まず導入有無とビルド番号の確認から。バージョン12系以前の扱いは公開情報からは確認できず、ベンダー確認が必要。
• 監視製品はバックアップ環境の内側にある構成要素。更新までの間はアクセス元の限定と低権限アカウント・共有リンクの棚卸しで到達経路を絞る。

出典

• Veeam KB4892: Vulnerabilities Resolved in Veeam ONE 13.1（2026年8月4日公開／最終更新2026年8月5日）
• Security NEXT「バックアップ運用管理製品『Veeam ONE』に深刻な脆弱性」
• IPA「ランサムウェア対策特設ページ」