Important changes

Last updated: 2025-09-12

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.

Vault will not unseal on upgrade if your only configured audit device is a file device with the executable mode set.

Vault file audit devices cannot use file modes with executable permissions (e.g., 0777, 0755), and should be configured with 0644 permissions (or similar).

Additionally, to enable file audit devices with the prefix option, you must set allow_audit_log_prefixing to true in your server configuration on each node in your cluster.

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.

Go mod tidy failures on community edition

The go.mod file lists a private repo that causes the go mod tidy command to fail.

Recommendation

Update the go.mod file to remove the line referencing hashicorp/go-cmp or build from main.

New behavior

JSON Payload Limits

To guard against potential Denial-of-Service (DoS) attacks, Vault now supports several listener options to enforce payload size limits for to incoming JSON request bodies.

You can configure the payload limits individullly on each listener and give administrators granular control over the:

• maximum allowed nesting depth of a JSON object or array (max_json_depth).
• maximum allowed length for any single string value in the payload (max_json_string_value_length.)
• maximum number of key-value pairs allowed in a single JSON object (max_json_object_entry_count).
• maximum number of elements permitted in a single JSON array max_json_array_element_count.

The configuration defaults provide intentionally generous limits to accommodate a wide range of legitimate use cases while still guarding against most malicious or malformed requests.

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

There are cases where configuring audience details can interfere with your workflow. For example, tokens created using kubernetes.io/service-account-token do not include an aud claim. But we recommend configuring an audience value for Kubernetes authentication roles whenever possible. Setting explicit audience details is best practice because it reduces the risk of token misuse by other services. Vault can use the configured values to validate that the aud (audience) claim in JWT tokens is intended for Vault.

For example:

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

You would then authenticate with the command below.

$ vault write auth/kubernetes/login role=demo audience="my_audience" jwt=...

Rotation manager schedue strings in UTC

Vault interprets rotation_schedule strings relative to UTC to match the behavior of static role rotations in the database plugin. Old rotations use their existing schedule until you manually update rotation with an API call.

Known issues

AWS auto join fails on startup.

After unsealing Vault and attempting to autojoin nodes to the cluster, if Dual Stack endpoints are not enabled in that region.

Workaround

Auto join will not work with this issue existing. If you need to rely on auto join for your nodes, do not upgrade.

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 or username and password 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.

Writing configuration to local auth mount (ldap, aws, gcp, azure) ignores local flag

Vault incorrectly forwards write operations targeting a local authentication mounts on a performance replication secondary to the primary cluster for processing. Forwarding the request prevents independent configuration of local mounts on secondary clusters for the following authentication methods:

• Azure
• GCP
• AWS
• LDA

Incorrect forwarding leads to two distinct failure modes:

1. If a local auth mount with the same path exists on the primary, Vault incorrectly applies the write operation to the primary node mount.

2. If the auth mount path does not exist on the primary, the secondary cluster panics with a nil pointer dereference error and the Vault node crashes.

Recommendation

Do not attempt to configure local auth mounts on performance replication secondaries.

Missed events with multiple event clients EnterpriseEnterprise

Users may miss events when multiple clients subscribe to the same performance standby node in a cluster with the same namespace and event type filters because one client disconnecting effectively unsubscribes the remaining clients who no longer receive events.

Recommendation

If you have multiple event subscribers with the same namespace and event type filters you have two options:

1. Spread them out among the nodes of the Vault cluster.
2. Only subscribe to events on the active node of the cluster.

Full seal rewraps occur on DR/PR failover with multi-seal enabled EnterpriseEnterprise

A full rewrap happens when Vault fails over to a DR or performance cluster with enable_multiseal = true. The rewrap can lead to performance degradation until the rewrap operation completes.

Recommendation

The only workaround is to disable multi-seal support.