CVE-2025-13357 is a high severity insecure default in the HashiCorp Vault Terraform Provider, scored 7.4 by CVSS 3.1. Versions 4.2.0 through 5.4.0 set the LDAP auth method option deny_null_bind to false. Upgrade to v5.5.0, or set deny_null_bind = true in your Terraform files and apply.
What's affected
The HashiCorp advisory (HCSEC-2025-33) lists Vault Terraform Provider v4.2.0 through v5.4.0. The fixed version is v5.5.0.
When an LDAP auth backend was created without a value for deny_null_bind, the provider set it to false. If the LDAP server behind that backend allows anonymous or unauthenticated binds, this could allow authentication bypass. The risk therefore depends on how your LDAP server is set up, which is why the CVSS vector lists high attack complexity.
The record does not mark the flaw as a CISA Known Exploited Vulnerability and neither source claims exploitation in the wild.
How to check if you're exposed
Search your Terraform code for the LDAP auth backend resource and look at whether deny_null_bind is set. If it is missing, the provider version decides the default.
grep -rn "vault_ldap_auth_backend" --include="*.tf" .
grep -rn "deny_null_bind" --include="*.tf" .
terraform version
The last command shows the installed provider versions. Anything from 4.2.0 up to 5.4.0 with an LDAP backend that omits the setting is in scope. Check the live Vault configuration too, because a backend created earlier keeps the value it was created with until you apply a change.
Also ask your directory team whether the LDAP server accepts anonymous or unauthenticated binds. If it rejects them, the practical exposure is lower, though you should still fix the default.
What to do now
- Find every Terraform configuration that manages a Vault LDAP auth backend.
- Set
deny_null_bind = trueexplicitly. This works on any provider version. - Upgrade the provider to v5.5.0 and run a plan to see what changes.
- Apply the change so that the live backend is updated.
- Upgrade Vault to a fixed release listed in the advisory: 1.21.1, 1.20.6, 1.19.12 or 1.16.28. These no longer accept empty password strings, which blocks null binds at the server.
- Plan ahead, because the advisory says
deny_null_bindis deprecated and will be removed in a future Vault version. - Review the LDAP server settings and disable anonymous binds if you do not need them.
Why it matters
The class is CWE-1188 (insecure default initialization of a resource). The code is not wrong in how it handles a request. The default is wrong. Anyone who created the backend with defaults inherited an unsafe setting without ever writing it, which makes the problem easy to miss in code review.
An LDAP bind with an empty password can succeed on some servers and be read as a valid login. In a secrets manager that outcome is serious, because the identity may map to policies that read secrets. Infrastructure as code can help here: the fix lives in version control, can be reviewed, and rolls out the same everywhere.
Dependency tracking helps too. Provider versions are dependencies, and a scan of your lock files tells you quickly which projects use an affected one.
Quick check
Which Vault Terraform Provider versions are affected by CVE-2025-13357?
Versions 4.2.0 through 5.4.0. Version 5.5.0 changes the default of deny_null_bind to true.
Do I have to upgrade the provider to be safe?
Not strictly. Setting deny_null_bind = true explicitly in your Terraform files protects any provider version once applied. Upgrading Vault to a fixed release also blocks null binds at the server.
Sources
Last reviewed: 19 October 2026.