Important changes

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

Transit support for Ed25519ph and Ed25519ctx signatures

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 EnterpriseEnterprise

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.

LDAP user DN search with upndomain ((#ldap))

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.

Duplicate unseal/seal wrap HSM keys EnterpriseEnterprise

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.

Recommendation

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

Anonymized cluster data returned with license utilization EnterpriseEnterprise

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.

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.

Recommendation

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

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.

Static LDAP 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.

Recommendation

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

Static DB 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.

Recommendation

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

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.

Recommendation

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.

Recommendation

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 Auth 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.

Recommendation

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

External Vault Enterprise plugins can't 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.

Recommendation

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.