The vault that let you spell your way past a deny rule

How bad it is

The record rates it High, 7.6 of 10, on CVSS 4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N. Network, low complexity, no click. Two conditions are built in, and this is our reading of them. The attacker already holds a token with some access (PR:L), and the target has a policy of the shape the first advisory describes, a broad grant with a specific deny under it (AT:P). The impact is high on confidentiality and integrity.

The record carries no CVSS 3.1 score. Our own report estimated 3.1 scores between 6.5 and 8.1, depending on how much privilege you think deleting a certificate revocation list needs. That is an estimate on a different scale, so we print the record’s number and not ours.

A deny is how operators carve an exception out of a broad grant: this team may issue credentials for every AppRole role except the production one. When the carve-out fails, the broad grant is all that is left. In a secrets manager, that is the part everyone relies on.

This is the sequel

The first case, GHSA-fg5x-7whg-6c28 (CVE-2026-104093), was published on 23 September and fixed in 2.7.0 and 2.6.3. Its text says several places in OpenBao allow access to a resource through a non-canonical name. For policies and workflows that includes names that are case-insensitive, whitespace-trimmed or path-simplified. For roles, users and PKI references, the names are case-insensitive. A policy checks the name in the request, the backend resolves it to another, and a deny on one spelling does not stop the other. The maintainers add that the flaw is original to HashiCorp Vault.

That advisory names certificate and Kubernetes roles, Userpass users, PKI references and policies. It does not name certificate revocation lists or AppRole. The record we are writing about adds those two, and adds LDAP and RADIUS.

Our report traced why those two were left out. The first fix works backend by backend. Each backend that changes a name before it looks the resource up has to say so, so the policy check can use the same name. Backends that were not changed kept answering to the name in the request. A fix that each backend must add by hand will miss some backends.

How we know

A description is not a finding. We ran OpenBao v2.7.1, a release that already carried the first fix, on local development servers with no outside network. The root token was used only to set things up and to check results.

For certificate revocation lists, a limited token had a deny on one list. The deny held for the name as written in the policy and failed for the same name spelled differently. With delete rights under the wildcard, that token removed the list. The revoked certificate logged in again and received its entry’s policies, which read a secret the limited token could not. The control: with the list put back, a delete under the denied name was refused, and so was the revoked certificate.

For AppRole, a delegated token could create credentials for every role but one. Through the other spelling it reached the denied role, created credentials for it, and logged in as that role. In our lab, its policy could read, change and delete one protected secret.

Our report covered those two of the four. We did not test LDAP or RADIUS. For AppRole we read the 2.6 source and ran nothing there. For revocation lists we did not check 2.6. We did not show an outage or a host compromise. The delegated AppRole token could not create or change roles. We filed it on 26 October through GitHub’s private reporting, the day the advisory went public. Three other reporters are credited with us, and a maintainer is credited separately for the remediation, so we claim neither first nor alone. The record carries no CVE identifier.

Three questions for anything that enforces access rules

None of this is specific to one product. If a policy engine sits in front of a set of backends, these are worth asking.

1. Do the policy engine and the backend agree on what a name is? If the engine checks the name in the request and the backend resolves it to another, every deny rests on the two matching.
2. Is the name made canonical once, at the door, or by each backend? A rule that each backend must remember will be forgotten by one of them, and the next backend written will not know it exists.
3. When a fix covers a class, who checks the rest of the class? Search for every place a name is changed before it is stored. Each one is a candidate. Add a test that a deny on one name stops every spelling of it.

None of it needs exotic tooling. It needs the first fix read as a list of what it covered, and the rest of the list written down.

What it proves, and what it doesn’t

It proves that on v2.7.1, a release that carried the first fix, a limited token deleted a revocation list its policy denied. The revoked certificate then logged in again. In the control, with the list back, a delete under the denied name was refused, and so was the certificate.

We reported two of the four. We did not look at LDAP or RADIUS, and we cannot say we found either of our two first. The finding does not show anyone getting past a deny on a live deployment, or what any operator’s policies look like. It says nothing about how OpenBao compares with other secrets managers. The maintainers say the flaw is original to HashiCorp Vault. We did not test that.