HashiCorpのVault Terraform Providerに存在する新たな脆弱性により、攻撃者が認証情報なしで認証を通過し、機密性の高いシークレットやインフラデータが露出する可能性がある。
この欠陥は、プロバイダーのLDAP認証設定におけるデフォルト値の誤設定に起因する。
「基盤となるLDAPサーバーが匿名または未認証のバインドを許可していた場合、認証を回避される可能性がある」とHashiCorpは述べている。
VaultのLDAP誤設定による脆弱性の詳細
この脆弱性（CVE-2025-13357）は、Vault Terraform ProviderがLDAP認証用のdeny_null_bindパラメーターを処理する際のデフォルト動作の誤りに起因する。
影響を受けるバージョンでは、Terraformの設定で明示的に指定されていない場合、このパラメーターはfalseがデフォルト値になっていた。
基盤となるLDAPサーバーが匿名またはヌルバインドを許可している環境では、これにより、Vaultが空のパスワードを有効な認証試行として扱う、気づきにくく危険な状態が生じた。
Terraform ProviderがデフォルトのパラメーターでLDAP認証バックエンドを作成または更新すると、Vaultは未認証のLDAP接続を受け入れ、攻撃者が認証情報を提示せずに認証できる状態になった。
この誤設定は、Infrastructure as Code（IaC）で管理される環境全体に及ぶため、複数のVaultクラスターやネームスペースが、知らないうちに安全性の低い設定を引き継ぐ可能性があった。
HashiCorpは、この欠陥がTerraform Provider v4.2.0からv5.4.0、および修正前に空のパスワードを受け入れていたVaultのバージョンに影響すると確認している。
実際に悪用された事例は確認されていないものの、匿名LDAPバインドを許可する環境では、概念実証コードによる攻撃は容易に実行できる。
Vaultのデプロイメントを安全にする方法
Vaultはシークレットや暗号化マテリアルの中央保管場所として機能するため、不正アクセスやその後の侵害を防ぐには、この脆弱性を修正することが不可欠だ。
- VaultとTerraform Providerを最新バージョンにアップグレードする
- すべてのLDAP認証設定でdeny_null_bind = trueを明示的に設定し、すべての環境で未認証または匿名のバインドを防止する。
- LDAPサーバー自体で匿名バインドを無効化し、ディレクトリサービスがヌルまたは空のパスワードによる認証試行を受け付けないようにする。
- VaultのLDAP認証エンドポイントへのネットワークアクセスを制限・分離し、ファイアウォールルール、ACL、最小権限の接続制御を利用する。
- LDAP認証バックエンドとVaultのポリシーを監査・強化し、安全性の低いデフォルト設定が残っていないことを確認するとともに、LDAPベースのログインに紐づく権限を最小限に抑える。
- 疑わしい認証アクティビティを監視し、空のパスワードによる試行、予期しないトークンの作成、通常とは異なるVaultへのログインパターンなどを検知する。
- Vaultを取り巻く運用セキュリティを強化し、認証情報とトークンのローテーション、高権限ロールへのMFAの適用、Terraformの状態におけるドリフトの検証、プロバイダーのバージョン固定を実施する。
この欠陥への対処には、ソフトウェアの更新、設定変更、運用慣行の強化を組み合わせ、安全な認証を確保する必要がある。
なぜシークレットとID基盤が主要な標的になるのか
今回の事例は、Infrastructure as Codeツールにおける一見ささいな誤設定が、組織全体に影響を及ぼす深刻な認証障害へと発展し得ることを示している。
企業がセキュリティやID関連のワークフローを自動化し続ける中、Terraform Providerなどのツールにおけるデフォルト設定の信頼性は極めて重要になっている。
Vaultの脆弱性は、より広範な傾向も浮き彫りにしている。攻撃者はクラウド環境のID基盤やシークレット層をますます狙うようになっており、たった1つの誤設定でも、広範かつ非常に高い権限を持つアクセスを与えかねない。
このようにID基盤への圧力が高まる中、ゼロトラスト原則は誤設定の影響を抑えるうえで不可欠なものとなる。