HashiCorpのシークレット同期ツール「Vault Secrets Operator（VSO）」に、CVSS 9.6の緊急脆弱性 CVE-2026-8715 が公表されました（2026年8月13日、HCSEC-2026-28）。影響を受けるのは 1.3.0〜1.4.1。修正版は 1.5.0 のみで、1.4系へのバックポートはありません。
怖いのは、悪用の前提が「クラスタ内の一般的な編集権限を持つ認証済みユーザー」で足りる点です。つまり社内の開発者に普段渡している権限の範囲で成立します。回避策の公表はなく、対応は実質1.5.0へのアップグレード一択。ただし設定変更を伴う破壊的変更が含まれるため「上げれば終わり」にはなりません。
この記事でわかること
- Vault Secrets Operatorとは何をするもので、誰が入れているのか
- CVE-2026-8715で何が読み取られ、なぜCVSS 9.6なのか
- 「うちはAppRole認証を使っていない」でも影響を受けうる理由
- 自社のクラスタに入っているかを確認する具体的な手順
- 修正版1.5.0の破壊的変更と、アップグレード後にやるべきこと
Vault Secrets Operatorとは何か（知らなくても入っている可能性がある）
Vault Secrets Operator（VSO）とは、HashiCorp Vaultなどに保管されたシークレット（パスワード・APIキー・証明書）を、Kubernetesの Secret リソースへ自動的に同期するためのオペレーターです。
アプリケーション側にVaultと直接やり取りするコードを書かせず、「いつも通りKubernetes Secretを読むだけ」にしておくための仲介役です。導入するのは情シスというより社内のプラットフォームチームや開発基盤の担当者であることが多く、Helmチャート（hashicorp/vault-secrets-operator）やKustomizeで数コマンドで入ります。
ここが本題です。「うちはHashiCorp Vaultを契約していない」と思っている情シスでも、無関係とは限りません。
- VSOはVaultのサーバ製品とは別配布のコンポーネントで、開発チームがEKS/AKS/GKEやOpenShiftのクラスタへ独自に導入していることがあります。資産管理台帳には何も載らないため、存在に気づきにくい構成です。
- 同期元は自社運用のVaultだけではありません。導入時に作成されるCRDには
hcpvaultsecretsapps.secrets.hashicorp.comが含まれ、SaaS版のHCP Vault Secretsからの同期にも対応します。自前のVaultサーバがなくてもVSOだけが動いている構成があり得ます。
「入れた記憶がない」で終わらせず、まずはクラスタに存在するかを機械的に確認してください。
何が起きたのか：任意ファイルの読み取りと外部送信
問題は、AppRole認証の設定項目 secretIDPath の検証不足にありました。HashiCorpのアドバイザリは、このフィールドについて「パストラバーサルのシーケンスの確認とファイルサイズの確認は行っていたが、オペレーターのPod上のどのファイルを参照できるかを制限していなかった」と説明しています。
さらに、攻撃者は接続先を指定する VaultConnection.spec.address も自分で設定できます。結果として、オペレーターPodのファイルを任意に読み取り、その内容を攻撃者が用意したエンドポイントへ送信できる——これが本脆弱性の実害です。
| CVE番号 | CVE-2026-8715（アドバイザリ: HCSEC-2026-28） |
|---|---|
| CVSS v3.1 | 9.6（Critical）／ AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
| CWE | CWE-552（外部から到達可能なファイル／ディレクトリ） |
| 影響バージョン | Vault Secrets Operator 1.3.0 〜 1.4.1 |
| 修正版 | 1.5.0（1.4系へのバックポートなし） |
| 公表日 | 2026年8月13日 |
| 回避策 | 公表されていない（アップグレードが必要） |
| 報告者 | Trung Nguyen氏（CyStack）、Artem Cherezov氏 |
なぜCVSS 9.6と高いのか
ベクトルは PR:L（低い権限で足りる）かつ S:C（スコープ変更）。低い権限しか持たない利用者が自分の権限の外側にある情報まで手を伸ばせることを示しています。
VSOのPodは複数の名前空間にSecretを書き込むという役割上、クラスタ内でも強い権限を持つ位置にいます。アドバイザリはPod上のどのファイルが実際に窃取可能かまで列挙していないため断定は避けますが、「シークレットを配る係のPodの中身が覗ける」という構図そのものが最悪の部類です。
「うちはAppRole認証を使っていない」は安全の理由にならない
本件で最も見落とされやすい点です。secretIDPath はAppRole認証の設定項目なので、「自社のVaultAuthはKubernetes認証方式だから関係ない」と判断したくなります。
しかしアドバイザリが挙げる前提条件は、「VaultAuth、VaultConnection、VaultStaticSecret に対する作成（create）と取得（get）の権限を持つ、認証済みのKubernetesユーザー」であり、「標準のHelmチャートが定義するeditorロールの権限に相当する」と明記されています。つまり攻撃者は既存設定を書き換えるのではなく、AppRole構成のVaultAuthと、自分のサーバを指すVaultConnectionを新規に作るだけでよい、と読めます。
自社の現行構成が何認証かは、影響判定の決め手になりません。軸は「脆弱なバージョンのVSOが動いているか」と「誰がこれらのリソースを作れるか」の2点です。
自社に影響があるかをどう確認するか
クラスタへアクセスできる担当者に、次の確認を依頼してください。いずれも参照系のコマンドです。
1. VSOが導入されているか（CRDの有無で判定）
kubectl get crd | grep secrets.hashicorp.comvaultauths.secrets.hashicorp.com や vaultconnections.secrets.hashicorp.com が返れば、VSOが入っています。
2. 稼働中のバージョンを確認する
helm list -A | grep vault-secrets-operator
kubectl get deployment -A -o wide | grep vault-secrets-operatorDeploymentのイメージタグが 1.3.x〜1.4.1 なら該当します。既定の導入先名前空間は vault-secrets-operator ですが、変更されている場合があるため全名前空間を対象にしてください。
3. 該当フィールドの利用状況を確認する
kubectl get vaultauth -A -o yaml | grep -n secretIDPathヒットすれば、1.5.0へ上げる際に設定移行が必須です（後述）。ヒットしなくても脆弱性の対象外にはならない点は、前節のとおりです。
4. 権限の棚卸し
上記CRDに対して create 権限を持つ主体を洗い出します。開発者・CI/CDのサービスアカウント・外部委託先のアカウントが含まれていないかを確認してください。
修正版1.5.0は「上げるだけ」では済まない
1.5.0では VaultAuth / VaultAuthGlobal の spec.appRole.secretIDPath が削除されました。リリースノートに破壊的変更として明示されており、代替は spec.appRole.secretRef——Kubernetes Secretを参照する方式です（参照先のSecretは id というキーにAppRoleのSecretIDを保持する必要があります）。
脆弱なフィールドを直すのではなく丸ごと廃止した、という設計判断です。堅い対応だと思いますが、運用側から見ればセキュリティ修正と設定変更が同時に降ってくることを意味します。AppRole認証をファイル経由で構成していた環境ではアップグレード時に同期が止まる可能性があるため、検証環境での事前確認を強く勧めます。
また、脆弱なバージョンが長く動いていた環境では、アップグレード後に「漏れたかもしれない資格情報の入れ替え」まで踏み込むかの判断が必要です。すでに読み取られていた場合、パッチを当てても盗まれた鍵は有効なままだからです。同種の論点はRailsの脆弱性CVE-2026-66066で鍵の再発行まで必要になった件でも扱っています。まずは監査ログで、当該CRDに対する想定外の作成操作がなかったかを確認するのが現実的な第一歩です。
現場目線の課題：台帳に載らないものは守れない
この手のニュースで毎回突きつけられるのは、「情シスが把握していない基盤が社内で動いている」という構造的な問題です。VSOはサーバ製品でもエージェントでもなく、稟議も資産登録もないままコマンド数本で入る一コンポーネントにすぎません。社内LLM基盤をめぐるNVIDIA Dynamoの脆弱性のときと、まったく同じ構図です。
そして今回の悪用条件は「編集権限を持つ認証済みユーザー」。外部からの侵入を前提としない、いわば内側の権限がそのまま攻撃面になるタイプです。権限を絞れという正論は簡単に言えますが、絞りすぎれば開発が回らなくなるのも現場の実感で、ここは常にせめぎ合いになります。AWS IoTのポリシー設計で個別確認では不十分だった事例と同じく、権限は「一つひとつ妥当か」ではなく「組み合わせて何ができてしまうか」で見ないと見落とします。
正直なところ、情シスがクラスタの隅々まで目を届かせるのは人員的に無理があります。「新しい基盤コンポーネントを入れたら申告する」という運用ルールと、CRD一覧を定期的に取る機械的な棚卸しの二段構えに落とし込むしかない、というのが現実的な結論だと感じます。
情シスはどうすべきか
個別の対応は上記のとおりですが、「シークレット管理をどう組織的に回すか」という土台は、公的機関の指針を出発点にするのが早道です。自前で長大なチェックリストを作る前に、次を参照してください。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：資産の把握と管理体制の作り方が体系的にまとまっており、今回のような「台帳に載らない資産」の問題に効きます。
- IPA「セキュリティインシデント対応 机上演習教材」：資格情報が漏えいした前提でどう動くかを、平時に一度通しておく価値があります。
- IPA「対策のしおり」：開発者を含むエンドユーザへの啓発資料として使えます。
あわせて、漏えいした資格情報を検知する取り組みについては認証情報の漏えいをAIエージェントで検出する研究も参考になります。
まとめ
- Vault Secrets Operator 1.3.0〜1.4.1 にCVSS 9.6の脆弱性（CVE-2026-8715）。オペレーターPod上の任意ファイルを読み取り、外部へ送信されうる。修正は1.5.0のみで回避策はない。
- 悪用の前提は「編集権限を持つ認証済みKubernetesユーザー」。自社がAppRole認証を使っていなくても、対象CRDを作成できる主体がいれば影響を受けうる。
- 1.5.0は
secretIDPathを削除する破壊的変更を含む。設定移行の検証と、漏えいを前提とした資格情報ローテーションの要否判断まで含めて計画すること。
