Vault Terraform Provider: LDAP auth method defaulted deny_null_bind to false, allowing authentication bypass

Impact

Any Vault LDAP auth mount created or managed through the Terraform provider was configured with deny_null_bind set to false instead of the safe default. If the backing LDAP or Active Directory server accepts anonymous or unauthenticated binds, a login attempt with an empty password can succeed, so an attacker who knows or guesses a username can authenticate to Vault without a credential. For a GPU fleet that keeps registry pulls, storage keys, node-provisioning secrets and CI tokens in Vault, that is unauthenticated access to whatever policies that identity carries. The exposure depends on the LDAP server's own configuration, which is why this is a misconfiguration-by-default rather than a Vault code flaw.

Who can reach it

Network, unauthenticated: anyone who can reach the Vault API and name a valid directory user, provided the LDAP server permits null binds. No prior Vault credential needed.

What to do

Upgrade the Vault Terraform Provider to v5.5.0 and re-apply, or set deny_null_bind explicitly on every LDAP auth mount. Critically, upgrading the provider alone does not repair mounts already written with the bad value - audit each existing LDAP mount's configuration in Vault and correct it, and confirm your directory servers reject anonymous binds. This is a configuration change applied through the Vault API, not a Vault server upgrade: no node drain and no restart of Vault is required, but review audit logs for successful empty-password logins before closing the issue.

References

Related entries

• Fortinet FortiOS and FortiSwitchManager: heap overflow in packet handling gives unauthenticated code executionCVE-2025-25249 · Fortinet FortiOS / FortiSwitchManager (packet handling path)Critical
• Fortinet FortiWeb: Unauthenticated SQL injectionCVE-2025-25257 · Fortinet FortiWebCritical
• GitLab (ruby-saml): ReXML/Nokogiri parser differentialCVE-2025-25291 · GitLab (ruby-saml)Critical
• HPE StoreOnce: unauthenticated command injection allows remote code execution on the backup applianceCVE-2025-37089 · HPE StoreOnce (command injection RCE)Critical
• HPE StoreOnce (server-side request forgery): SSRF from the backup appliance, letting an unauthenticated attacker pivotCVE-2025-37090 · HPE StoreOnce (server-side request forgery)Critical
• HPE StoreOnce (authentication bypass): Unauthenticated attacker bypasses authentication on StoreOnce entirely, gainingCVE-2025-37093 · HPE StoreOnce (authentication bypass)Critical