# HCSEC-2020-07 - Vault Enterprise Prefixed Mount Policies May Result In Unauthorized Namespace Access

**URL:** <https://discuss.hashicorp.com/t/hcsec-2020-07-vault-enterprise-prefixed-mount-policies-may-result-in-unauthorized-namespace-access/18090>\
**Category:** Security\
**Tags:** security-vault\
**Created:** [November 25, 2020, 7:07pm UTC](https://discuss.hashicorp.com/t/hcsec-2020-07-vault-enterprise-prefixed-mount-policies-may-result-in-unauthorized-namespace-access/18090 "2020-11-25T19:07:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jfinnigan](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jfinnigan/32/3834_2.png) [@jfinnigan](https://discuss.hashicorp.com/u/jfinnigan)\
**Post date:** [November 25, 2020, 7:07pm UTC](https://discuss.hashicorp.com/t/hcsec-2020-07-vault-enterprise-prefixed-mount-policies-may-result-in-unauthorized-namespace-access/18090/1 "2020-11-25T19:07:17Z")

</div>

**Bulletin ID:** HCSEC-2020-07  
**Affected Products / Versions:** Vault Enterprise 0.11.0 and newer; fixed in 1.3.4.  
**Publication Date:** 19 March, 2020

**Summary**  
A vulnerability was identified in Vault Enterprise such that, under certain circumstances, existing nested-path policies may give access to Namespaces created after-the-fact. This vulnerability, CVE-2020-10661, affects Vault Enterprise versions 0.11 and newer and is fixed in 1.3.4.

**Background**  
Vault allows nested-paths when configuring a [Secrets Engine](https://www.vaultproject.io/docs/secrets/). In addition, associated [Policies](https://www.vaultproject.io/docs/concepts/policies/) can also be configured referring to the nested-path’s prefix.

An example of this is shown here:

```auto
# create mounts
vault secrets enable -path=foo/kv1 kv
vault secrets enable -path=foo/kv2 kv

# create a policy with foo/* permissions
vault policy write foo-kvs - <<EOF
path "foo/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
EOF

```

**Details**  
it was possible to configure a [Namespace](https://www.vaultproject.io/docs/enterprise/namespaces/) with the same name as an already existing, nested-path’s prefix.

For example:

```auto
# create a namespace
vault namespace create foo

```

Any entities with the previously created policy applied to them will be able to access resources inside this new Namespace.

Conditions required were:

- Run Vault Enterprise version 0.11.0 or above.
- Have configured Namespaces with the same name as existing, mounted prefixes.
- Have configured Policies for these Secrets Engines.

**Remediation**  
As described above, this is a vulnerability with conditions existing only in a subset of Vault deployments and use-cases.

To address for existing namespaces/mounts:

- Remount any mounts that collide with an existing namespace to a different path. (Note: This will revoke any leases that exist for that mount.)
- Check on the policies on the current namespace that might be affected by a path overlap. Note that each affected policy should be checked since the intent could indeed be to grant access to a child namespace.
- Update affected policies to be on the newly remounted prefix path.

To prevent this behavior from occurring operators should upgrade to Vault 1.3.4 or newer.

Please refer to [Upgrading Vault](https://www.vaultproject.io/docs/upgrading/index.html) for general guidance and version-specific upgrade notes.

**Acknowledgement**  
This issue was identified by the Vault engineering team.

_We deeply appreciate any effort to discover and disclose security vulnerabilities responsibly. For information about security at HashiCorp and the reporting of security vulnerabilities, please see [https://hashicorp.com/security](https://hashicorp.com/security)._