Affected and fixed versions

1. The walkthrough (vault-cve-2026-5006-walkthrough.html)

A single self-contained HTML file. Open it in any browser.

What it covers

1. The attack. A plain-language explanation plus a live path renderer. Pick or type an identity value and watch Vault build the path as segments. A clean value stays one segment; a value with a slash splits into an extra segment marked as injected. A toggle flips deny_slash_in_templated_paths on and off so you can see the fix blocking the rule in real time.
2. Check your environment. The same checks the audit script automates, shown as copy-paste commands with a note on namespaces and the HCP root you cannot see.
3. Remediate. A sub-toggle between HCP Vault Dedicated and self-managed on Kubernetes. The HCP path covers the platform upgrade, the support questions to ask about the flag, and the policy audit you own. The Kubernetes path covers the snapshot, the combined image-and-flag helm upgrade, the ordered pod cycling (standbys first, active last), and verification.

Who it is for

Platform or security teams. Start with the attack tab to gain context of the issue, use the check tab to hand off the commands, and switch the remediate tab to whichever deployment they run.

2. The audit script (vault-cve-2026-5006-audit.sh)

Walks every namespace you can reach and writes four Markdown reports. It never modifies Vault; every call is a list or a read.

Requirements

• vault CLI and jq on your PATH
• VAULT_ADDR set to the cluster address
• An authenticated token: either VAULT_TOKEN in the environment or a prior vault login. On HCP, a token scoped to your admin namespace.

Usage

Start at admin on HCP because the true root namespace is not visible to you there. Use -n "" only when you hold a root token on a self-managed cluster.

Output

Each file opens with the advisory reference, a UTC timestamp, the cluster address, the start namespace, and the number of namespaces scanned.

What gets flagged

policies.md lists only policies whose path is rendered from identity data (a {{identity...}} reference). Those are the ones that can be widened by a slash.

The three identity reports add a Slash? column. A row is flagged when the name or any metadata value contains a /. Checking the name matters: an alias named admin/injected is an exposure even when its metadata is clean, because the name itself can feed a template.

A flag marks exposure surface, not proof of compromise. For each one, confirm who is allowed to write that value and restructure the policy where a slash would widen scope.

How namespaces are handled

Vault Enterprise and HCP isolate both policies and the identity store per namespace, so the script runs every check in each namespace. vault namespace list returns only direct children as partial paths, so the script recurses and rebuilds each full path as it descends, then sets VAULT_NAMESPACE for every call.

A note on scale

On deep namespace trees this makes a lot of API calls and can run slowly. Point -n at a subtree for a fast first pass before scanning everything.

Remediation summary

1. Upgrade to a fixed build from the table above. On HCP this arrives through the platform; confirm the schedule in the portal or with support.
2. Enable deny_slash_in_templated_paths = true and restart each server. On HCP this is a support request, since the server config is not yours to edit. On self-managed you set it yourself.
3. Review the audit output first. Once the flag is on, a legitimate value that contains a slash will also be blocked, so clean those up before you switch it.

The walkthrough's remediate tab has the step-by-step for both HCP and Kubernetes.

Sources

• Advisory: HCSEC-2026-32 on the HashiCorp discussion forum
• deny_slash_in_templated_paths in the Vault configuration reference
• Templated policies in the Vault policy concepts docs

Disclaimer

These tools are an aid, not an official HashiCorp statement.