Important changes

Last updated: 2026-10-21

Always review important or breaking changes and remediation recommendations before upgrading Vault.

Breaking changes

PostgreSQL storage backend Azure auth prefers workload identity

When auth_mode is set to azure or azure_msi for the PostgreSQL storage backend, Vault now checks for Azure workload identity before managed identity. Previously, Vault used only managed identity.

azure is the new name for the auth mode. Vault continues to accept azure_msi as an alias, so you do not need to change your configuration to upgrade.

If Vault runs in an environment with workload identity configured, such as an Azure Kubernetes Service (AKS) pod with the AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID, and AZURE_TENANT_ID environment variables, Vault authenticates to PostgreSQL with the workload identity. The azure_client_id parameter does not override this behavior. If only the managed identity has a PostgreSQL role, Vault cannot connect to storage after the upgrade.

Recommendation

Before upgrading, check whether the Vault pod has workload identity configured. If it does, either grant the PostgreSQL role to the workload identity, or remove the workload identity configuration from the pod so that Vault uses the managed identity.

AWS credential precedence change for AWS auth method and AWS secrets engine

If you have Workload Identity Federation (WIF) credentials and AWS environment variables configured, the AWS auth method and the AWS secrets engine now always use the explicitly configured WIF credentials.

In previous versions, environment variables took precedence over explicitly configured WIF credentials during credential resolution. But Vault now ignores environment variables in favor of WIF credentials.

Recommendation

Review any deployments where you configured WIF alongside AWS environment variables to confirm your intended credential precedence. If your workflow relied on environment variables taking precedence, update your configuration prior to upgrading to Vault 2.2.0.

SCIM requests must declare their extension schema

Enterprise

Vault now rejects SCIM requests that include an extension block without declaring its schema URI, and rejects requests that combine the deprecated 2.0:Metadata extension with the 2.2:User extension.

Recommendation

Update each connector to declare urn:ietf:params:scim:schemas:extension:vault:2.0:Metadata when it sends the deprecated metadata extension, or migrate to urn:ietf:params:scim:schemas:extension:vault:2.2:User.

SCIM client deletion requires an explicit cleanup strategy

Enterprise

Deleting a SCIM client that owns resources no longer deletes those resources by default. DELETE requests must include delete-linked-resources=true as a query string to delete owned resources, or unlink-resources=true to preserve them and remove SCIM ownership.

Recommendation

Update client-deletion automation to select one cleanup strategy explicitly.

SCIM client names are now case-insensitive

Enterprise

Vault now treats SCIM client names as case-insensitive, so client-name automations that rely on case-only distinctions no longer work.

Recommendation

Remove case-only duplicate client names.

Entity merge rejects SCIM-managed entities

Enterprise

Vault rejects identity/entity/merge requests that include a SCIM-managed entity, preventing operators from moving aliases, group memberships, or policies across SCIM ownership boundaries.

Recommendation

Use the SCIM link and unlink endpoints instead of merging SCIM-managed entities.

Identity API writes cannot change SCIM-managed external IDs

Enterprise

Vault rejects normal identity API writes that change the external ID of a SCIM-managed entity.

Recommendation

To assign a different external ID, unlink the entity and link it again with the desired externalId. Unlinking an entity clears its external ID.

SCIM 2.2 clients manage group metadata

Enterprise

For SCIM clients configured to use the 2.2 schema by default, group metadata is SCIM-managed and cannot be changed through the normal identity API. Clients using the earlier 2.0 default retain the previous behavior.

Recommendation

Use the SCIM client to manage group metadata.

Precedence change for Azure authentication

Azure auth now gives values set in auth/azure/config precedence over AZURE_* environment variables.

Recommendation

Review any deployments where you rely on environment variables to confirm whether they currently override stored configuration and update the plugin configuration to your preferred behavior.

Duplicate HCL attributes always fail

Vault no longer supports duplicate attributes in HCL configuration files or policy definitions. As a result, Vault now returns an error when it detects the same argument more than once and ignores the VAULT_ALLOW_PENDING_REMOVAL_DUPLICATE_HCL_ATTRIBUTES environment variable that previously enabled the legacy behavior.

Recommendation

Remove duplicate attributes from your Vault configuration files and policy definitions before upgrading.

Vault now authenticates the following endpoint families to prevent attackers from sending key-update requests with bogus key fragments with the aim of preventing legitimate use of the endpoints:

• sys/rekey
• sys/generate-root
• sys/replication/dr/secondary/generate-operation-token

Previous versions only required authentication with a seal or recovery keys to be provided. Authenticating to the affected endpoints now requires seal/recovery key fragments and a valid Vault token.

Recommendation

Modify callers of these endpoints to provide a vault token if they weren't already, or populate enable_unauthenticated_access. Note that the reason for this change is to prevent an attacker from taking advantage of these endpoints being unauthenticated, by sending key-update requests with bogus key fragments which prevent legitimate use. Modify callers of these endpoints to always provide a valid Vault token.

If you must continue to use the endpoints unauthenticated, set the enable_unauthenticated_access, configuration parameter to provide backward compatability with existing clients.

Docker image requires IPC_LOCK capability

The Vault docker image requires the IPC_LOCK capability to run. In prior versions of the Vault container we'd set IPC_LOCK on the vault binary at runtime via the entrypoint scripts. As we now run the Vault container as an unprivileged user we have to set it at build time in order for the binary to have the capabilities necessary to lock the memory.

Recommendation

Add the IPC_LOCK capability to the container or pod, or run the container as root.

The latter is not recommended from a security perspective, but is an option if you are unable to add the capability to the container or pod.

Vault rejects uncleaned paths

Vault requires request paths to be canonicalized paths. Vault will reject requests with relative references, such as /../, /./ or //.

Recommendation

Update requests to Vault to use cleaned paths.

CVE-2026-39829: Enfore a maximum RSA key modulus size of 8192 bits

We have addressed CVE-2026-39829, a potential denial-of-service vulnerability in the RSA key parser, to prioritize system stability and protection against resource exhaustion attacks and align with the updated golang.org/x/crypto library.

As part of the remediation, Vault now enforces a maximum RSA key modulus size of 8192 bits, which means you cannot use or sign RSA keys exceeding 8192 bits.

Recommendation

If you use RSA keys with Vault, we recommend using RSA keys with moduli of 2048-8192 bits to provide strong security while maintaining compatibility:

1. Audit your existing RSA keys to identify any with moduli exceeding 8192 bits.
2. Generate new RSA keys with moduli between 2048-8192 bits.
3. Update your applications and services to use the new keys before upgrading Vault.
4. Test the new keys in a non-production environment to ensure compatibility.

Wildcards and globs not permitted in templated policy paths

Vault does not permit wildcards (+) and globs (*) in the rendered output for identity templates and returns a "permission denied" response.

For example, the following policy template fails if you set region="amer/+/us-west" in the education group's metadata:

path "group-kv/data/education/{{identity.groups.names.education.metadata.region}}/*" {
    capabilities = [ "create", "update", "read", "delete", "list" ]
}

Recommendation

Avoid wildcards and globs in the rendered output for identity templates.

New behavior

IPC_LOCK requirement removed

We removed the IPC_LOCK Linux capability requirement from official Vault container images while preserving the non-root vault user runtime model.

The change better aligns the images with hardened container platforms that already enforce non-root execution and restrict added capabilities, including many Kubernetes, OpenShift, and managed container environments.

Recommendation

To avoid leaking data, especially if swap is part of the host memory plan, run Vault on hosts with swap disabled or encrypted, and set disable_mlock to true.

Refer to the Vault Kubernetes security considerations tutorial and the disable_mlock configuration reference for more information.

LDAP static role rotation migrates to a centralized automated rotation system

Enterprise

For existing LDAP static roles, Vault Enterprise migrates the assocaited credential rotation period from the LDAP plugin to the central rotation manager during plugin initialization. During migration, rotation timing may shift slightly. You can track migration status in the LDAP static role migration API.

After migration completes, Vault no longer retries static role credential rotation every 10 seconds indefinitely. Vault uses exponential backoff and stops retrying after it reaches the retry limit configured on the role.

Configuration for IBM Passport Advantage Online license keys

Enterprise

Vault Enterprise customers who use a license key issued by IBM Passport Advantage Online must add a license_entitlement configuration to their Vault nodes. Refer to IBM Passport Advantage Online license keys for more information.

Token header size limit for authentication headers

Vault now enforces a configurable maximum size limit on the X-Vault-Token and Authorization: Bearer headers. The default limit is 8 KB (8192 bytes), which is well above the size of any current opaque Vault token.

Requests whose authentication token header exceeds the limit receive an HTTP 431 (Request Header Fields Too Large) response before token validation occurs.

The new limit does not affect existing deployments that only use opaque Vault tokens. The limit becomes customer-visible in deployments that use External JWT Tokens, especially tokens with rich authorization_details claims, can be significantly larger than opaque tokens.

Recommendation

No action is required for standard deployments. If you use enterprise JWT tokens or OIDC tokens with large authorization_details payloads, evaluate your largest token sizes and raise max_token_header_size in your listener configuration:

listener "tcp" {
  address               = "127.0.0.1:8200"
  max_token_header_size = 16384  # raise to 16 KB for large JWT claims
}

Refer to the TCP listener configuration for the full set of options, including cluster listener behaviours.

DR secondaries now accept root tokens from the primary

Enterprise

Vault now allows authentication against secondary DR nodes with a root token generated on the primary. Previous versions of Vault only allowed requests against secondary nodes to authenticate using a batch token or DR operation token created by sys/replication/dr/secondary/generate-operation-token.

Known issues

LDAP static role rotation issues after manual rotation

Enterprise

Manual rotation of LDAP secrets engine static roles can cause the following issues, depending on your Vault version:

• Manual rotation does not reset the rotation time to live (TTL), and the next automated rotation still occurs at the originally scheduled time.
• Manual rotation updates the reported ttl and next_vault_rotation values, but leaves the original automated rotation job active. Credentials rotate earlier than the API reports. Vault may also log errors about an unrecognized rotation management path.
• Manual rotation can register an automated rotation job for a role with rotation_period configured, even when disable_automated_rotation is true. This can cause unexpected automated credential rotations.

Recommendation

If you use the LDAP secrets engine on Vault 2.x, we recommend upgrading to Vault 2.2.0 or later to avoid all three issues. Vault 2.2.0 resets the rotation schedule after manual rotation, keeps the reported rotation metadata consistent with the actual schedule, and respects disable_automated_rotation.

If you cannot upgrade and the role should rotate automatically, you can reset its rotation cadence after a manual rotation:

1. Deregister the rotation entry by setting disable_automated_rotation to true on the static role.
2. Reregister the rotation entry by setting disable_automated_rotation back to false.

When you reactivate rotation, Vault resets the initial rotation time and recalculates the next_vault_rotation timestamp. Do not re-enable automated rotation for roles that must remain manually managed.

Database plugin resources may remain after connection initialization fails

Enterprise

Issue

When initialization of a database connection fails, Vault may not clean up the database plugin subprocesses and associated resources. Repeated failures can increase resource usage over time.

The issue affects Oracle Enterprise database plugin versions 0.14.1+ent, 0.14.0+ent, 0.13.0+ent, 0.12.3+ent, and 0.11.0+ent.

The issue is also reported for Vault Enterprise 1.18.5+, 1.17.12+, and 1.16.16+.

Recommendation

Monitor Vault's memory usage and open file descriptors if you use external Enterprise database plugins. Also track vault.runtime.num_goroutines through the sys/metrics API as a general indicator of resource growth.

Contact HashiCorp Support if resource usage grows over time.

Okta SCIM group membership removal does not revoke Vault group access

Enterprise

Vault Enterprise exposes SCIM as a beta feature in Vault 2.0.0. When you use Okta Group Push with Vault SCIM, removing a user from an Okta group does not remove that user from the corresponding Vault group. Okta sends a SCIM PATCH request for member removal that Vault 2.0.0 does not support. As a result, the user remains in the Vault group and retains any policies that the group grants.

Recommendation

As a workaround, unlink and relink the Okta push group to recreate the corresponding Vault group with the intended membership.

Root token KV access blocked by EGP policy

Enterprise

Issue

If you use a root token in the Vault GUI to access a child namespace protected by an Endpoint Governing Policy (EGP), Vault may deny the request unexpectedly.

The unexpected rejection affects GUI flows that call sys/internal/ui/mounts with a namespace header. In affected cases, the GUI shows a permission denied error even though root tokens typically bypass Sentinel policy checks. Equivalent CLI and API workflows are unaffected.

Workaround

Use the CLI or API for the affected workflow.

If you require GUI access for an expected workflow, update the EGP policy logic to explicitly allow requests to sys/internal/ui/mounts for the affected namespace.

Sidebar menu reloads on engine-scoped pages

Issue

On some engine-scoped GUI routes, the Vault sidebar can briefly render the wrong menu or reload during navigation before settling on the correct section.

The menu flicker is most noticeable on subpages like the Custom messages page under Operational tools, and secret-detail routes. The flicker occurs during page transitions and does not affect the underlying operation.

Recommendation

Continue with the affected workflow after the page finishes loading and the sidebar settles into the correct state.

Secrets Engines items-per-page change can hide results

Issue

Changing the number of items per page on the Secrets Engines page in the Vault GUI from anything other than the first page of results can leave the table empty even when the item count indicates available results.

For example, if a user starts on page 3 with 5 results per page, then increases the page size to 25. The list view still only shows the 5 original results. The empty display table is strictly a cosmetic issue and does not affect the underlying mounts.

Workaround

Return to page 1 before increasing Items per page.

If the table still appears empty after changing the page size, refresh the page and retry the action from the first results page.

LDAP plugins must use ldap type for self-managed static roles

Enterprise

Issue

Self-managed static roles do not work when using the openldap built-in TYPE alias for the LDAP Secrets plugin. Enabling a new LDAP mount with the openldap built-in TYPE alias with self-managed static roles returns the following error:

* 1 error occurred:
        * self-managed static roles feature requires a valid Vault Enterprise license

Workaround

1. Enable a new LDAP plugin for self-managed static roles:
   $ vault secrets enable -path=<mount_path> ldap
   

2. Use the ldap plugin type to configure the new mount:
   $ vault write <mount_path>/config \
       self_managed=true
   

When you set self_managed to true, Vault verifies your enterprise license and enables the feature for the new mount.

Azure rotate static credentials cannot run in quick succession

Issue

Azure is eventually consistent, so internal state propagation may lag after updates. When Vault attempts a rotation before synchronization completes, it may fail to remove the old credential. You must clean up orphaned credentials manually.

For example:

$ vault write -f azure/rotate-role/my-role

Workaround

Wait a few minutes before each static-rotate call.

Plugin signature verification failures

Enterprise

Issue

Vault Enterprise fails to verify external enterprise plugins released since April 21, 2026 that are signed with the renewed HashiCorp PGP signing key.

The registration issue only affects new plugin registrations for Enterprise plugins released since April 21, 2026. Existing registered plugins will not be affected.

Affected workflows can return errors similar to the following:

openpgp: key expired
Signature Verification Error: Invalid signature caused by openpgp: key expired

Workaround

Vault can now verify plugins released before or after April 21, 2026. We recommend upgrading to the latest patch release of Vault Enterprise in the affected series.

Rotation Manager incorrectly routes local mount entries under namespaces

Enterprise

Issue

On performance primary Vault clusters, the rotation manager incorrectly routes rotation entries for local mounts created under a namespace to the shared rotation manager storage instead of local storage.

As a result, the rotation manager can lose track of these entries when Vault restarts because the rotation entries are stored in the wrong location.

Recommendation

1. Before upgrading to a fixed version, set disable_automated_rotation=true on your root or static role config to clean up the rotation entry in shared storage. For example, to clean entries for the LDAP Secrets plugin:

     $ vault write ldap/config \
         disable_automated_rotation=true
   

2. After upgrading, you can set disable_automated_rotation back to false to have the rotation manager re-register and store entries in local storage going forward:

     $ vault write ldap/config \
         disable_automated_rotation=false
   

Rotation Manager loses track of entries after mount migration

Enterprise

Issue

The rotation manager loses track and de-registers rotation entries if the underlying mount for the rotation entry gets migrated under a different name.

Workaround

None.

Docker image startup failures

Issue

Previously, Vault ran containers as root. Now, Vault checks explicit capability permissions when the Docker container starts. As a result, Docker containers may fail to start with the following error:

unable to set CAP_SETFCAP effective capability: Operation not permitted

Workaround

While undesirable from a security perspective, you can continue to run the container as root or specify the environment variable SKIP_SETCAP=1 to bypass the capability check.

Requests for sealwrapped values can lead to raft quorum failures

In Vault 1.17.0 a change was made to assist in diagnosing deadlocks in the sealwrap code. The deadlock detector adds overhead, and in extreme cases can prevent the Go scheduler from scheduling the goroutines needed to maintain Raft quorum. This would typically be seen on clusters receiving a high volume of requests to sealwrapped mounts, particularly after a restart or leadership change, since these result in Vault flushing its internal cache. Vault 1.17.0 changed the sealwrap code to assist in diagnosing deadlocks. The deadlock detector adds overhead and, in extreme cases, can prevent the Go scheduler from scheduling the goroutines needed to maintain Raft quorum.

Reads of cached sealwrapped values do not require locking, so the Go scheduler interference typically occurred on clusters receiving a high volume of requests to sealwrapped mounts after a restart or leadership change due to Vault flushing its internal cache.

Even without quorum loss, less extreme cases could still increase request latency and CPU and memory usage and result in log entries of POTENTIAL DEADLOCK followed by stack traces.

The log entries do not necessarily indicate a deadlock occured, just that a goroutine had to wait over 30s to acquire a lock.

Recommendation

Upgrade to a fixed version that disables the deadlock detector by default.

You can safely leave the detector disabled. If support asks you to enable the detector to help diagnose a deadlock issue, set the detect_deadlocks field in your sever configuration to "sealwrap":

Azure dynamic roles may intermittently fail to provision credentials

Issue

Azure is eventually consistent, so internal state propagation may lag when Vault creates or modifies an object. When Vault returns a credential for a dynamic role, it must create an application, instantiate a service principal, and then provision a new credential.

When the service principal is in an inconsistent state, Vault may intermittently return an error similar to the following when the credential requests fails:

The service principal cannot be created, updated, or restored because the service principal name {guid} is already in use.

Workaround

Ugrade to latest patch release of Vault. As of the latest Vault versions, the Azure secrets engine uses of more efficient API calls to better avoid inconsistent states.

Azure secrets engine roles can target Vault's own service principal

Issue

The Azure secrets engine does not prevent a role from targeting the same Azure AD application that Vault uses as its service principal. The problem affects static and dynamic roles with an explicit `application_object_id

Workaround

Step 1: Audit for poisoned roles

Before applying any code fixes, audit your Azure deployment for static roles that target the service principal used by Vault.

On Vault Enterprise, repeat the following steps for every namespace with an Azure secrets engine mount:

1. Fetch and save all the Azure mount paths under the current namespace:

   $ export MOUNT_PATHS=$(                                          \
   vault secrets list -format=json |                            \
   jq -r 'to_entries[] | select(.value.type == "azure") | .key' \
   )
   

2. Compare the client ID (client_id) for each Azure mount path to the application object ID (application_object_id) for the available static roles:

   $ for mount in ${MOUNT_PATHS} ; do
       CLIENTID=$(vault read -format=json ${mount}config | jq '.data.client_id')
       echo "${mount} ($CLIENTID) static roles:"
       vault list -format=json ${mount}static-roles | \
       jq --arg client ${CLIENTID} -r 'to_entries[] | select(.value.application_object_id == "$client") | .key'
   done
   

3. Compare the client ID (client_id) for each Azure mount path to the application object ID (application_object_id) for the available dynamic roles :

   $ for mount in ${MOUNT_PATHS} ; do
       CLIENTID=$(vault read -format=json ${mount}config | jq '.data.client_id')
       echo "${mount} ($CLIENTID) dynamic roles:"
       vault list -format=json ${mount}roles | \
       jq --arg client ${CLIENTID} -r 'to_entries[] | select(.value.application_object_id == "$client") | .key'
   done
   

4. Delete any static role whose application_object_id matches the client ID (Azure app ID) of the associated mount path:

   $ vault delete <mount>/static-roles/<name>
   

5. Revoke the corresponding credentials directly in Azure AD by removing the associated application password (client secret) from the app registration. You cannot rely on Vault lease revocation to remove access for the static role.

6. Revoke active leases for the applicable dynamic roles so that Azure removes any already-issued credentials from the app registration immediately rather than waiting for lease expiry:

   $ vault lease revoke -prefix <mount>/creds/<name>
   

7. Delete any dynamic role whose application_object_id matches the client ID (Azure app ID) of the associated mount path:

   $ vault delete <mount>/roles/<name>
   

Step 2: Upgrade

Upgrade to a patched version of the Azure secrets engine plugin once we release it.

TPMGroup membership/deletion not reflected in auth roles on primary node

Enterprise

Issue

If you update the membership of a TPMGroup or delete the TPMGroup is deleted using the identity/tpmgroup/name/:name endpoint, auth and TPM roles that reference the group will not see the change on the primary active node. Downstream nodes will see the change, so a leadership change or seal/unseal eventually makes the change visible to auth/tpm roles.

Workaround

Lookup the ID of the TPMGroup to modify, then use the identity/tpmgroup/id/:id endpoint to make the change.

Transit CMAC endpoint fails for keys rotated to a CMAC key

Enterprise

Issue

The Transit cmac endpoint returns an error if the provided key version is a aes128-cmac, aes192-cmac, or aes256-cmac type that Vault created using the Rotate with Algorithm Change endpoint from a key whose original algorithm does not support CMAC.

Workaround

Create a new Transit key to use for CMAC.

Vault Agent reissues PKI external CA certificates on every re-authentication

Enterprise

Issue

When you configure Vault Agent with a pki_external_ca stanza, Vault Agent requests a new certificate every time auto-auth re-authenticates and receives a new token, even if the current certificate is valid. Vault Agent ignores the percent_renew_before_expiry setting and the scheduled renewal time for the certificate.

On each re-authentication, Vault Agent logs Manual renewal triggered, creates a new ACME order, generates a new private key, and writes the new certificate and key to the configured destination. Token renewals do not trigger reissuance.

Workaround

None.

Azure static credentials display incorrect last rotation time when seamless rotation is enabled

Enterprise

Issue

The static credential endpoint returns an incorrect value for the last_vault_rotation field when seamless rotation has been enabled.

Workaround

Manually calculate the last_vault_rotation by subtracting the rotation_period configured the static role from the expiration date returned when reading the credentials.

Transit datakey and datakeys endpoints fail for keys rotated to a managed key

Enterprise

Issue

The Transit datakey and datakeys endpoints return an error if the provided key version is a managed_key type that Vault created using the Rotate with Algorithm Change endpoint from a key whose original algorithm was not managed_key.

Workaround

Create a new Transit key configured with the desired managed key.

GUI default auth returns null after upgrade from 1.20.x or 1.21.x

Enterprise

If you are upgrading from an affected 1.20.x or 1.21.x release, default auth rules targeting the root namespace may cause GET /v1/sys/internal/ui/default-auth-methods to return data: null. Refer to Vault 1.21.x important changes for the root cause and remediation steps.