Vault 2.2.0, 2.2.1 and 2.2.2: Breaking Changes and ACL Bypass Fixes

Breaking Changes in Vault 2.2.0 and Who Must Act #

The two container entries contradict each other. One says the build no longer sets cap_ipc_lock, so Vault cannot call mlock() and operators should set disable_mlock = true and turn off swap. The other says the build sets cap_ipc_lock, so the runtime must grant IPC_LOCK. The notes do not say which image carries which, so the capability on the binary in the image in use decides it; the check at the end of this article reads it.

Two more changes in the CHANGES section can break existing setups. LIST requests with a trailing slash now respect a more-specific deny, so a LIST kv/private/ that a broad allow used to let through is now denied. A new listener option, max_token_header_size, limits X-Vault-Token and Authorization: Bearer headers to 8 KB by default; clients that send larger tokens fail until the limit is raised or set to -1.

ACL Deny Rules and Case: Three Releases, One Problem #

Most of the ACL fixes concern names and paths that differ only in case. In 2.2.0, a denied_parameters rule on the policies field could be bypassed with a mixed-case policy name such as Super-Admin, which the notes call a privilege-escalation vulnerability; Vault now lowercases that parameter before checking it. 2.2.0 also stopped case-variant role names, policy names, userpass usernames and GitHub mapping keys from slipping past an exact deny on AppRole, AWS, Azure, GCP, Kubernetes, SCEP, TPM and certificate paths.

"Okta group names, LDAP and RADIUS names on mounts left in their default case-insensitive configuration, and Enterprise SCIM client names (identity/scim/client/<name>, where a case-variant write overwrites the existing client) are not covered by this fix and remain subject to the same bypass; avoid combining a wildcard allow with an exact deny on those mounts and paths." (Vault 2.2.0 release notes)

2.2.2 adds a general rule: explicit deny rules now match the requested path case-insensitively, subject to the usual rule specificity, so a deny on secret/data/example also denies secret/data/EXAMPLE. 2.2.0 also gives the RADIUS method a case_insensitive_names toggle against username collisions.

Root Policy Aliases in 2.2.1 #

2.2.1 fixes a cache-key collision through which policy-name aliases could resolve to the immutable root policy. Names such as ./root or a/../root were accepted before and are now rejected wherever a policy is assigned: on entities, groups, tokens, authentication responses and the agent registry. The notes give no CVE or advisory ID. 2.2.0 had already hardened request-time ACL construction to ignore legacy policy references with . or .. segments. Any entity, group or token that carries such a name should be found and corrected, because the assignment will be refused from 2.2.1 on.

Other Security Fixes in Vault 2.2.0 #

• auth/aws: incorrect caching of the AWS client could let a user bypass authentication.
• auth/cert: a renewed certificate must now match the certificate attached to the session.
• Plugin catalog entries restored from a raft snapshot, written through sys/raw or replicated could run a binary outside plugin_directory.
• Vault tokens are removed from a forwarded Authorization header, which reaches plugin backends only when it is listed in the passthrough request headers.
• Recovery tokens are compared in constant time, URL-encoded paths that are not canonical are rejected, and rendered identity templates reject wildcards.
• Identity: entity batch delete can no longer remove entities of another namespace, and entity name updates reject mismatched id or external_id selectors.
• secrets/ssh: RSA keys are limited to 8192 bits, addressing CVE-2026-39829.

Dependency Advisories in 2.2.0, 2.2.1 and 2.2.2 #

2.2.0 updates libraries for these advisories: CVE-2026-1229 (cloudflare/circl), CVE-2026-39883 (OpenTelemetry SDK), CVE-2026-34986 and GHSA-78h2-9frx-2jm8 (go-jose), GHSA-j88v-2chj-qfwx and GHSA-jqcq-xjh3-6g23 (pgx), GHSA-wf45-q9ch-q8gh and GHSA-8wv5-x4w7-5gww (Apache Thrift), GHSA-xmrv-pmrh-hhx2 (AWS SDK), GHSA-92mm-2pjq-r785 (go-getter), GHSA-2v4p-qf9q-27wj (gRPC), GHSA-x744-4wpc-v9h2 and GHSA-pxq6-2prw-chj9 (the docker to moby move), GHSA-f6x5-jh6r-wrfv and GHSA-j5w8-q4qc-rx2x (golang.org/x/crypto) and CVE-2025-63811 (jose2go). It also fixes a regression from the CVE-2025-6000 fix that broke enabling audit devices on Windows with a plugin directory. 2.2.1 moves to Go 1.27.3 for CVE-2026-111943 and distrusts the eMudhra intermediate chains in the Alpine and UBI images; 2.2.2 moves to Go 1.27.4 and updates several plugins.

Upgrading Vault to 2.2.2 #

1. Install 2.2.2. It carries the 2.2.0 changes, the 2.2.1 root alias fix and the 2.2.2 deny matching.
2. Before the upgrade, search entities, groups and token roles for policy names with . or .. segments or other spellings of root, and replace them.
3. Review policies that combine a wildcard allow with an exact deny, especially on Okta, LDAP, RADIUS and SCIM paths, which the 2.2.0 notes leave open.
4. For containers, read the capability on the Vault binary and set disable_mlock or IPC_LOCK to match; replace any probe that relies on procps or openssl in UBI images.
5. On Azure PostgreSQL storage, ACME issuance and JWT revocation, apply the actions in the table; check clients with large tokens against the 8 KB header limit.
6. After 2.2.2, custom plugins or integrations that return interactive HTML through Vault Agent or Proxy no longer render it interactively in a browser.

Checking a Vault Deployment Before the Upgrade #

The commands print the version, the capability on the binary inside the image, the relevant configuration keys and the policies assigned to identity groups, which the root alias search then filters.

vault version
getcap "$(command -v vault)"
grep -nE "disable_mlock|max_token_header_size|default_directory_policy" /etc/vault.d/*.hcl
for g in $(vault list -format=json identity/group/name | jq -r '.[]'); do
  vault read -format=json "identity/group/name/$g" | jq -r '.data.policies[]?'
done | grep -nE '(^|/)\.\.?(/|$)|root'