Important changes

Last updated: 2026-05-07

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

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.

Transit support for Ed25519ph and Ed25519ctx signatures

In Vault deployments using Transit plugins with Ed25519 keys, prior versions of sign and verify API endpoints backed by an Ed25519 key ignored prehashed=true or hash_algorithm=sha2-512 parameters. As a result, the endpoint always returned or verified a Pure Ed25519 signature.

The Transit plugin now assumes input hashed using the SHA-512 algorithm and returns an Ed25519ph or Pure Ed25519 signature based on the configuration of prehashed and hash_algorithm parameters:

Identity system duplicate cleanup

Enterprise

Vault 1.19.0 includes a feature flag that, when enabled, forces deduplication of existing identities and forbids duplicate identities going forward. Once activated, the deduplication feature corrects historical identity bugs with a one-time deduplication process and restores Vault to secure, default behavior.

Vault does not enforce deduplication until you activate the relevant feature flag.

Recommendation

Vault 1.19.0 also includes improved reporting in server logs to help diagnose whether you have duplicate identities in your Vault instance.

After upgrading, review your server logs for identity duplicate reporting.

refer to the resolve duplicate identities guides to understand deduplication log messages, determine if you need to take action, make the necessary updates, and ensure the forced deduplication process resolves safely.

Anonymized cluster data returned with license utilization

Enterprise

As of version 1.19.0 Vault Enterprise collects anonymous usage data about the running Vault cluster and automatically sends the cluster usage data along with the standard utilization data currently reported through automated license reporting.

RADIUS authentication is no longer case sensitive

As of Vault 1.19.0 the RADIUS authentication plugin does not enforce case sensitivity on entered credentials.

Strict validation for Azure auth login requests

Azure auth plugin requires resource_group_name, vm_name, and vmss_name to match the JWT claims on login

Vault versions before 1.19.1, 1.18.7, 1.17.14, and 1.16.18 did not strictly validate the resource_group_name, vm_name, and vmss_name parameters against their token claims for clients logging in with Azure authentication.

Recommendation

Review the Token validation section of the Azure authN plugin guide for more information on the new validation requirements.

File audit devices require explicit configuration for prefixing and cannot use executable file permissions (CVE-2025-6000)

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, you need to:

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.

Rotation manager schedule 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.

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.

Breaking changes

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.

LDAP user DN search with upndomain

Security improvements to hashicorp/cap/ldap ensure that user DN searches with upndomain configured return an error if the search returns more than one result.

Recommendation

In previous Vault versions, DN searches with upndomain configured returned the last user found for searches with multiple results. Review and update any code that performs DN searches to handle multi-result errors and/or revise the search to ensure a single result.

Refer to the Github PR for more details.

Previously unauthenticated endpoints require authentication

Enterprise

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.

Bugs

Vault log file missing subsystem logs

Log entries, including plugin logs, for Vault deployments using log_file do not capture all relevant information even though the information appears as expected in standard error and standard output.

Workaround

Upgrade to one of the following Vault versions: 1.16.18+, 1.17.14+, 1.18.7+, 1.19.1+

Automated rotation stops after unseal

After unsealing Vault, the rotation manager does not reinstate the rotation queue. The stopped queue then causes automated root credential rotations to stop.

Workaround

Update the root configuration on affected backends to recreate the rotation schedule with the previous values.

$ vault write aws/config/root          \
    rotation_schedule="<old_schedule>" \
    rotation_window="<old_window>"

$ vault write gcp/config/root rotation_period="<old_period>"

Azure authentication fails to authenticate Uniform VMSS instances

A previous update to validate JWT claims against the provided VM, VMSS, and resource group names without accounting for the uniform VMSS format introduced a regression that causes Azure authentication from a uniform VMSS instance with a user assigned managed identity on the VMSS to incorrectly return an error.

Workaround

Upgrade to one of the following Vault versions: 1.16.21+, 1.17.17+, 1.18.10+, 1.19.4+

External Enterprise plugins cannot run on a standby node when it becomes active

External Enterprise plugins can't run on a standby node when it becomes active because standby nodes don't extract the artifact when the plugin is registered.

Workaround

As a workaround, add the plugin .zip artifact on every node and register the plugin on the active node. Then, extract the contents of the zip file on the follower nodes similar to the following folder structure for vault-plugin-secrets-keymgmt_0.16.0+ent_darwin_arm64.zip.

<plugin-directory>/vault-plugin-secrets-keymgmt_0.16.0+ent_darwin_arm64
├── metadata.json
├── metadata.json.sig
└── vault-plugin-secrets-keymgmt

Alternatively, upgrade to one of the following Vault versions: 1.16.21+, 1.17.17+, 1.18.10+, 1.19.4+. See Register external plugins for more details.

AWS STS configuration can fail with unspecified STS endpoints

If you leave sts_endpoint unset and configure an STS endpoint in the AWS secrets plugin or upgrade Vault with sts_endpoint unset on an existing mount, the AWS plugin returns an error that the number of endpoints and regions do not match:

{"errors":["number of regions does not match number of endpoints"]}

Workaround

Explicitly set the default endpoint and region when configuring sts:

{
...
  sts_region = "us-east-1"
  sts_endpoint = "https://sts.amazonaws.com"
...
}

Known issues

Rotation registrations failing

Rotation manager configurations and jobs may cause Vault to hold a lock indefinitely and cause multiple downstream effects including failures to create new rotation jobs and failed authentication for methods configured to use rotation manager.

Workaround

Upgrade to 1.19.10 or the latest version of 1.20.x or 1.21.x.

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

Enterprise

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 such as 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.

Workaround

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

Login/token renewal failures after group changes

Performance standby nodes cannot persist updated group membership to storage. As a result, standby nodes return a 500 error during login or token renewal if the external group associated with the client entity changes.

Workaround

Direct all logins and token renewals to the active/primary node. Or upgrade to Vault 1.19.3+

Unexpected DB static role rotations on upgrade

Any database static role that was created prior to Vault 1.15.0 will be affected upon upgrading to the affected Vault versions. Vault will automatically rotate static database credentials once, for all roles created prior to 1.15.0, when upgrading to affected versions. After the one-time rotation, the static roles behave as expected.

Workaround

Upgrade to 1.19.3+, 1.18.9+, 1.17.16, 1.16.20+

Unexpected LDAP static role rotations on upgrade

Vault automatically rotates existing static roles tied to LDAP credentials once when upgrading to an affected version. After the one-time rotation, the static roles behave as expected.

Workaround

If you rely on LDAP static roles, upgrade to Vault 1.19.3+, 1.18.9+, 1.17.16+, or 1.16.20+.

Unwanted secret rotation for DB and LDAP roles on restart

Database and LDAP secrets engines both support skipping automatic import rotation of static roles with the config-level field skip_static_role_import_rotation and the static role-level field skip_import_rotation.

When either field is true, Vault automatically rotates the configured static roles when Vault restarts. Vault skips password rotation if the password was already rotated before the restart.

Workaround

Upgrade to 1.18.9+ or 1.19.3+. If you cannot upgrade, the only workaround is to avoid restarting the backend.

Counters API requires start time in Vault Community

Vault Community requires the start_time parameter for /sys/internal/counters/activity. Unlike Enterprise Vault, Vault Commuity does not define a billing start time, and ommitting start_time may lead to unexpected behavior in affected versions (1.18.x and 1.19.x).

You can safely omit start_time for Vault Enterprise as start_time defaults to the billing start date for the cluster.

Workaround

To avoid issues and unexpected behavior with Vault Community, always provide a valid start_time value when calling /sys/internal/counters/activity or upgrade to v1.20.x.

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.

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
• LDAP

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

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 ((#self-managed-openldap-fails))

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.