公開日: 2026年8月17日
カテゴリ: Security News
対象読者: 一人情シス・情シス担当者
概要
HashiCorp は、Kubernetes 向けのシークレット同期製品「Vault Secrets
Operator」に重大な脆弱性を公表しました。2026年8月13日に公開された「HCSEC-2026-28」では、AppRole
認証設定で利用される secretIDPath
に不備があり、Kubernetes
の認証済みユーザーが制限を越えて任意のファイルを読み取れることが明らかになっています。
脆弱性の識別番号は CVE-2026-8715 で、CVSS v3.1
のベーススコアは 9.6（Critical）
と評価されています。攻撃条件は一定の Kubernetes 権限を持つユーザーが
VaultAuth、VaultConnection、VaultStaticSecret
を作成・取得できることが必要ですが、権限を持つテナントが
operator pod
内のファイルを参照し、認証情報の窃取につながる点が懸念されます。
本件は「Vault を Kubernetes に導入しているが、日常運用では権限設計を深く見ていない企業」にとっては、シークレット管理基盤そのものが脅威の入口になる事例です。特にマルチテナント運用や共有 Kubernetes クラスタでは、権限の最小化とアップデートの優先度が高い課題となります。
目次
1. 何が起きたか
2026年8月13日、HashiCorp は Kubernetes 向けシークレット同期製品である Vault Secrets Operator の不備を告知しました。対象バージョンは 1.3.0 から 1.4.1 で、修正済みの 1.5.0 で対策が入っています。
問題の本体は spec.appRole.secretIDPath
という設定です。Vault Secrets Operator は AppRole 認証時に、認証用の
Secret ID
をどこから読み込むかをこのパラメータで定義します。しかし実装上、対象ファイルの参照範囲を十分に制限しておらず、operator
pod 内で閲覧可能なファイルを自由に指定できる状態になっていました。
この不備が悪用されると、攻撃者が Kubernetes 上で所持する権限を使って Pod のファイルシステム内を横断し、トークンや証明書、その他の機密情報を読み出すことが可能になります。場合によっては、Vault への認証情報やクラスタ内のシークレットが盗み出されるリスクがあります。
2. 脆弱性の概要と影響
HashiCorp のアドバイザリでは、本件は「AppRole の
secretIDPath
を悪用した任意ファイル読み取り」と説明されています。secretIDPath
は、秘密情報の読み取り元を制限しようとしていたはずですが、パストラバーサル対策が不十分で、通常はアクセスできないファイルも参照可能でした。
さらに、VaultConnection.spec.address も
tenant-controlled
な設定として扱われており、攻撃者がその値を利用してファイルの内容を外部エンドポイントへ送信するような姿勢に持ち込める構造でした。つまり、単なる「設定ミス」ではなく、認証情報窃取の入口として機能しうる脆弱性でした。
影響範囲の要点
- 対象: Vault Secrets Operator 1.3.0 〜 1.4.1
- 修正版: 1.5.0
- 攻撃条件: 一定の Kubernetes 権限を持つ認証済みユーザー
- 主要影響: 任意ファイル読取、認証情報窃取、クラスタ内権限の悪用
- 重大度: CVSS v3.1 9.6（Critical）
重要なのは、現在の VaultAuth 設定で
secretIDPathを使っていない場合は影響が限定されるものの、運用上は「使っていない」と言い切れないケースがある点です。特に既存構成の棚卸しが必要です。
3. なぜ情シス担当者に関係があるのか
この脆弱性は、Kubernetes や HashiCorp Vault を社内で運用している企業だけでなく、クラスタ共有の運用設計をしている情シス担当者にも関係します。理由は、攻撃の前提が「認証済みの一般ユーザーに与えられた権限」だからです。
例えば、以下のような運用ではリスクが高くなります。
- Kubernetes の namespace 単位で
VaultAuthやVaultConnectionを作成可能なユーザーがいる - 複数のテナントが同じクラスタを共有している
- 管理者権限を必要最小限に絞れていない
- シークレットの置き場所や Pod のマウントパスを十分に管理できていない
攻撃者がこの条件を満たせば、Vault Secrets Operator を経由してクラスタ内部の秘密情報や認証情報にアクセスできる可能性があります。実際には、初期アクセスは「対象の権限のある利用者」からの攻撃が前提ですが、その攻撃が成立すると、業務系システムやクラウド基盤の信頼性が一気に揺らぐことがあります。
4. 今すぐ確認すべき対応
1) まずは影響範囲とバージョン確認
Vault Secrets Operator のバージョンを確認してください。修正対象は 1.3.0〜1.4.1 で、1.5.0 で修正済みです。もし 1.5.0 未満を利用している場合は早急なアップデートが必要です。
2)
secretIDPath の利用有無を棚卸しする
今の運用で spec.appRole.secretIDPath
を使用しているか、既存の VaultAuth
定義を確認してください。HashiCorp の案内どおり、1.5.0 では
secretIDPath
そのものが削除されており、secretRef
への移行が必要です。
3) Kubernetes の権限制御を最小権限化する
VaultAuth、VaultConnection、VaultStaticSecret
の作成・取得権限を、必要なユーザーに限定してください。特にクラスタ共有環境では、“閲覧権限が広すぎる”こと自体が脅威の入口になり得ます。
4) シークレットと認証情報を再点検する
改ざんや漏えいに備えて、以下の見直しが必要です。
- Vault で管理している認証情報の利用範囲を再確認
- AppRole と Kubernetes Secret の紐付け方法を検証
- 既存のマウントパスとファイル権限を見直し
- 変更監査ログや Kubernetes の audit log を確認
5) 影響調査の準備をしておく
この脆弱性は「特定ファイルが読まれた」という事実そのものが検出しづらく、ログや監査出力の有無で初期被害を見逃す可能性があります。監視基盤の見直しと、インシデント対応フローの事前準備が重要です。
5. まとめ・YJK からのコメント
今回の HashiCorp Vault Secrets Operator の脆弱性は、シークレット管理基盤の“設定ミス”がそのままクラスタ基盤の信頼性を揺らすことを示しています。特に、運用上は「少数の管理者が使うだけ」と見なされていても、テナントや namespace の権限設計が甘いと、認証済みユーザーからの横移動が成立します。
この種の脆弱性は、最新版への更新だけでなく、設定の棚卸し、権限制御の見直し、Kubernetes 監査の強化まで含めた対策が必要です。特に、シークレットを管理するツールほど、利用済みの設定や過去の構成を“一度見直す”ことが重要です。
YJK では、Vault・Kubernetes・クラウド基盤にまたがるセキュリティ診断、権限制御設計、インシデント対応支援を行っています。もし「Vault の運用と権限設計を見直したい」「Kubernetes で利用している設定が安全か確認したい」と感じた場合は、まずは利用中の構成を整理して支援できます。
HashiCorp Vault Secrets Operator に深刻な脆弱性、AppRole の secretIDPath で任意ファイル読取可能のような「見えない脅威」は、通常のレビューでは見落とされやすく、開発基盤の信頼を揺らします。YJK では、開発環境の棚卸し、依存関係の監査、認証情報の見直し、サプライチェーンリスク評価まで一貫して支援します。まずは現在の利用ツールとアクセス権限の確認からご相談ください。