Vault Enterprise by HashiCorp is a powerhouse when it comes to managing secrets and protecting sensitive data. However, a vulnerability (CVE-2023-3775) discovered in its Sentinel Role Governing Policy (RGP) logic showed just how a well-intentioned policy could be used to restrict — or even disrupt — unrelated parts of your infrastructure.

This long read explains in clear terms what happened, how it could have been exploited, code snippets showing the problem in action, and the steps taken to fix it. Whether you’re a Vault admin or just curious about security, this post will walk you through what you need to know about CVE-2023-3775.

What is CVE-2023-3775?

CVE-2023-3775 is a vulnerability in Vault Enterprise's Sentinel Role Governing Policies (RGP), where a policy designed to limit access in one namespace could unintentionally apply to requests in a completely unrelated namespace. Basically, a restriction meant for Namespace A could fire on Namespace B or C, blocking access to resources that should have been unaffected.

This bug potentially let a privileged operator (intentionally or accidentally) create a denial-of-service condition for unrelated users or teams.

How Do Sentinel RGPs Work?

Role Governing Policies in Vault are Sentinel policies used to restrict what actions can be done on roles (like PKI certificates, dynamic credentials, etc.). They're typically scoped to a specific namespace, so an operator can enforce, for example, that only certain users can issue a specific type of certificate.

Here’s a sample Sentinel RGP

import "vault"

param entity

main = rule {
  # Forbid issuing certificates outside the /pki namespace
  vault.request.namespace == "pki"
}

The expectation: This policy only guards the “pki” namespace. However, before this bug was fixed, Vault Enterprise could mistakenly apply this policy much more broadly…

Let's suppose the admin of "dev" namespace writes a Sentinel RGP to lock down some resources

import "vault"

main = rule {
  # Allow only actions from users in "devs" group
  vault.token.entity.groups contains "devs" 
}

Bug: If a request is made to *another* namespace — say, "prod", even by a user that doesn’t belong to "dev" — Vault could incorrectly evaluate this "dev" policy and block the request. Requests outside of the original namespace and its descendants shouldn't be affected, but they were.

Impact:
- Denial of Service: Users and apps could lose access to secrets, certificates, or resources they were never supposed to be restricted from.
- Cross-namespace Policy Bleed: One operator’s policy could accidentally (or maliciously) overreach into areas they shouldn't control.

Here’s a step-by-step outline of how this could be abused

1. Operator in "dev" namespace creates a strict Role Governing Policy, perhaps even an accidental "deny all".

Vault applies the "dev" policy to "prod" role request.

4. Request is denied — prod team puzzled, suddenly their system goes down, all thanks to an unrelated policy elsewhere.

Let’s simulate with pseudo Python (using hvac, the Vault client)

import hvac

client = hvac.Client(url='https://vault.company.com';, token=os.environ["VAULT_TOKEN"])

# This request is to the "prod" namespace, should not be affected by "dev" policies
try:
    client.secrets.kv.read_secret_version(
        path='database/creds/app',
        mount_point='secret',
        namespace='prod'
    )
except Exception as e:
    print(f"Access blocked unexpectedly: {e}")

If “dev” adds a deny-all RGP policy, this prod request could now fail.

Official References

- HashiCorp Security Bulletin - CVE-2023-3775
- Vault GitHub Issue/PR for Fix
- What’s New in Vault 1.15.

How Was It Fixed?

According to HashiCorp, the fixes in Vault Enterprise 1.15., 1.14.4, and 1.13.8 restrict RGPs to only apply to their namespace and any direct descendants as originally intended.

Key fix in pseudo code

func applyRGP(policy, requestNamespace, policyNamespace string) bool {
    // Check: Is requestNamespace == policyNamespace, or a descendant?
    return isDescendant(requestNamespace, policyNamespace)
}

Now, a policy only applies if you’re in the exact namespace or a child realm.

1.13.8+

Audit Sentinel RGPs. Ensure no one has created overly broad or unintended policies.

3. Monitor for Denials. If users in one namespace report sudden denials but policies weren’t supposed to affect them, it may be a sign this bug hit you.

Conclusion

CVE-2023-3775 shows how complex policy logic can sometimes go haywire — even with the best intentions. For Vault admins, it's a lesson in always scoping policies as narrowly as possible and staying current with updates.

If you want more details, see HashiCorp’s advisory and check your Vault installation’s version — don’t let someone else’s policy block your service.

Stay safe, keep secrets secret, and keep policies in their lane.

*Exclusive content for learning and awareness. You’re encouraged to patch and test responsibly.*

Timeline

Published on: 09/29/2023 00:15:00 UTC
Last modified on: 10/02/2023 20:04:00 UTC