Important changes

Last updated: 2025-08-13

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

Breaking changes

Explicit disable_mlock setting required for integrated storage

Prior to Vault 1.20, the default setting for disable_mlock was false, but as of Vault 1.20.0, disable_mlock is a required configuration setting for clusters using integrated storage. The change to disable_mlock affects all cluster types: primary, performance secondary, and DR secondary.

You do not need to update clusters that already set an explicit value for disable_mlock. Servers running in dev modealso start and run as usual because the default configuration setsdisable_mlockexplicitly anddevmode requires explicit values fordisable_mlock` when you provide a custom configuration for the server.

Recommendation

If your server configuration currently uses the default value for disable_mlock (false), and you want to maintain that behavior, you must you explicitly set disable_mlock = false in the outermost level of the server configuration for all server nodes.

Additionally:

• If you use autopilot for upgrades, Vault adds nodes running 1.20.x to the cluster until it reaches a quorum of upgraded nodes. You must set an explicit value for disable_mlock on each of the nodes before upgrading.

• If you use rolling upgrades, Vault stops and upgrades standby nodes one at a time. You must update the configuration for each node before restarting the vault process on that node.

Refer to the mlock-config server configuration documentation for more informaiton.

CVE-2025-6000: File audit devices cannot use executable file permissions

File audit devices require explicit configuration for prefixing and cannot use executable file permissions. You must set allow_audit_log_prefixing to true in your server configuration to enable file audit devices with the prefix option. Additionally, file audit devices cannot use file modes with executable permissions (e.g., 0777, 0755).

Recommendation

If you use file audit devices:

1. Add allow_audit_log_prefixing = true to your Vault server configuration if you want to use the prefix option.
2. Use non-executable file modes (e.g., 0644, 0666) for log files.

Rekey cancellations use a nonce

Vault 1.20.0, 1.19.6, 1.18.11, 1.17.18, and 1.16.21 require a nonce to cancel rekey and rekey recovery key operations within 10 minutes of initializing a rekey request. Cancellation requests after the 10 minute window do not require a nonce and succeed as expected.

Recommendation

To cancel a rekey operation, provide the nonce value from the /sys/rekey/init or sys/rekey-recovery-key/init response.

Auzre authentication requires bound group or service principal ID

Azure authentication roles must specify either bound_group_ids or bound_service_principal_ids in the role definition to prevent excessively permissive access.

Requiring a bound group or service principal ID ensures that policies for the role reflect the the specific needs of the application or service. For example:

$ vault write auth/azure/role/dev-role \
    policies="prod,dev" \
    bound_subscription_ids=6a1d5988-5917-4221-b224-904cd7e24a25 \
    bound_resource_groups=vault \
    bound_service_principal_ids=3cb88732-1356-4782-b671-4877166be01a

Refer to the Azure authentication plugin documentation for more information.

CVE-2025-6000: File audit devices cannot use executable file permissions

File audit devices require explicit configuration for prefixing and cannot use executable file permissions. You must set allow_audit_log_prefixing to true in your server configuration to enable file audit devices with the prefix option. Additionally, file audit devices cannot use file modes with executable permissions (e.g., 0777, 0755).

Recommendation

If you use file audit devices:

1. Add allow_audit_log_prefixing = true to your Vault server configuration if you want to use the prefix option.
2. Use non-executable file modes (e.g., 0644, 0666) for log files.

New behavior

Key pair authentication for Snowflake DB secrets engine

As of version 1.20.0, Vault supports Snowflake database authentication using key pairs as an alternative to password authentication, which Snowflake plans to disable in November 2025. Vault support for password authentication with Snowflake is now deprecated and will be removed in a future release.

Recommendation

Vault currently does not support rotate root for key pairs. To manually rotate key pairs:

1. Update the root configuration in Vault with the new private key
2. Update the public key associated with the user in Snowflake

For more information on rotating key pairs, please refer to the official Snowflake documentation.

Audience warning for Kubernetes authentication roles

Vault logs a warning when you create or update a Kubernetes auth role without an audience.

Recommendation

We recommend updating your policies before Vault makes the audience value required for all Kubernetes authentication roles so Vault can explicitly validate that the audience claim in JWT tokens (aud) is intended for Vault and not another service. For example:

$ vault write auth/kubernetes/role/demo      \
    bound_service_account_names=myapp        \
    bound_service_account_namespaces=default \
    policies=default                         \
    ttl=1h

Known issues

Duplicate unseal/seal wrap HSM keys EnterpriseEnterprise

In HSM-HA configurations migrating from Shamir to HSM-backed unseal/seal wraps, Vault may create duplicate HSM keys when you migrate from Shamir to an HSM-backed unseal configuration for high availability (HA) HSM deployments. Key duplication can happen even after a seal migration to HSM that initially appears successful.

Duplicate HSM keys can cause the following errors:

• intermittent read failures with errors like CKR_SIGNATURE_INVALID and CKR_KEY_HANDLE_INVALID for seal-wrapped values.
• nodes fail to unseal after a restart with errors such as CKR_DATA_INVALID.

Recommendation

Always run Vault with generate_key = false and manually create all required keys within the HSM during the setup process.

Secondary cluster reload overwrites development cluster setting EnterpriseEnterprise

If the Vault process receives a SIGHUP and reloads a secondary performance replication cluster, the cluster reverts to the locally configured development_cluster value instead of following the value configured on the primary cluster.

Recommendation

Ensure all clusters in a performance replication group have the same development_cluster value configured in HCL to prevent unexpected changes to the reported value.

GUI login fails for auth mounts with underscores and unauthenticated listing

Login requests to auth methods mounted at paths using underscores (e.g. oidc_test) with listing_visibility="unauth" fail because the GUI calls the wrong endpoint. Mounts with dashes (e.g. oidc-test) work correctly.

Recommendation

As a workaround, you can log in to the GUI using the following steps:

1. Navigate directly to the URL for the desired method type (e.g. ${VAULT_ADDR}/ui/vault/auth?with=oidc)
2. Click "Sign in with other methods →"
3. Select the method type from the dropdown
4. Click Advanced settings and provide the correct path (e.g., oidc_test).

We also recommend creating a custom GUI message describing the workaround steps for users.

GUI navigation error for KV v2 secret paths containing underscores

Users without policy permissions granting read access to the /subkeys endpoint receive an error when navigating to KV v2 secrets with an underscore in the name (e.g. my_secret).

Recommendation

As a workaround, you can use the GUI CLI emulator to read secret data or metadata.

You can also use the API explorer to make any HTTP request:

1. Select Tools from the Vault GUI sidebar.
2. Click API Explorer.
3. Enter the KV v2 plugin mount path in the "Filter by tag" search bar.
4. Expand the endpoint for the action you wish to perform and click Try it out.
5. Provide the required parameters. For example, to read a KV v2 secret the path must be provided.
6. Provide any optional parameters desired.
7. Click Execute to perform the HTTP request.

Failing credential refresh for Snowflake DB secrets engine key pair authentication

Users using keypair authentication with Snowflake databases may receive errors due to improper credential refreshes and stale connections in the connection pool. When two or more concurrent operations occur, Vault tries to reuse an idle connection from the pool and the request fails due to session timeout in the Snowflake database.

Recommendation

As a workaround, you can set the max_connection_lifetime to a value below SESSION_IDLE_TIMEOUT_MINS.

Duplicate LDAP password rotations on standby node check-in

Performing Vault check-ins for LDAP service accounts on a performance standby node or nodes in a performance standby cluster can trigger duplicate password changes on the LDAP server.

Duplication occurs when the LDAP client on the local node successfully modifies a password before Vault forwards the check-in request to the active node, which then performs a second password update.

While users still receive the latest password, the secondary update may lead to unexpected LDAP activity and cause confusion interpreting audit logs.

Recommendation

Send check-in requests directly to the active node of the primary cluster to prevent duplicate password rotations on the LDAP server.