Summary
vault-java-driver can disable TLS certificate and hostname verification even when an application requests verification, causing it to trust any server certificate. If an attacker can intercept the connection to Vault, they may read tokens and secrets in transit or forge server responses.
vault-java-driver can disable TLS certificate and hostname verification even when an application requests verification, causing it to trust any server certificate. If an attacker can intercept the connection to Vault, they may read tokens and secrets in transit or forge server responses.
Affected context
The issue affects vault-java-driver versions 5.2.0 through 6.2.3 when TLS verification is requested but configuration handling causes SslConfig.isVerify() to return false. This can occur when an SslConfig is passed to VaultConfig without calling build(), when an SslConfig is restored through Java deserialization, or when VAULT_SSL_VERIFY is set to a truthy value other than the exact string "true". In these cases, the driver installs a trust-all SSL context, disabling certificate and hostname checks.
The issue affects vault-java-driver versions 5.2.0 through 6.2.3 when TLS verification is requested but configuration handling causes SslConfig.isVerify() to return false. This can occur when an SslConfig is passed to VaultConfig without calling build(), when an SslConfig is restored through Java deserialization, or when VAULT_SSL_VERIFY is set to a truthy value other than the exact string "true". In these cases, the driver installs a trust-all SSL context, disabling certificate and hostname checks.
Exploit preconditions
- Attack surface: The network connection between an application using the driver and its Vault server
- Required access: Ability to intercept or otherwise control traffic on the network path; access to the application's configuration or serialized object may also be needed to trigger the affected configuration state
- Trigger point: The driver establishes a TLS connection while
SslConfig.isVerify()is false - Why exploitation is possible: The driver accepts unverified certificates and hostnames, allowing an on-path attacker to impersonate the Vault server
- Attack surface: The network connection between an application using the driver and its Vault server
- Required access: Ability to intercept or otherwise control traffic on the network path; access to the application's configuration or serialized object may also be needed to trigger the affected configuration state
- Trigger point: The driver establishes a TLS connection while
SslConfig.isVerify()is false - Why exploitation is possible: The driver accepts unverified certificates and hostnames, allowing an on-path attacker to impersonate the Vault server
Why this happens
The underlying bug is improper certificate validation, mapped primarily to CWE-295. Configuration and deserialization paths can leave verification disabled, while truthy environment-variable values other than "true" are not interpreted as enabling it. The driver then uses a trust-all SSL context rather than failing closed. This also relates to CWE-297, because the server hostname is not reliably verified, and CWE-636, because a verification request can fail open.
The underlying bug is improper certificate validation, mapped primarily to CWE-295. Configuration and deserialization paths can leave verification disabled, while truthy environment-variable values other than "true" are not interpreted as enabling it. The driver then uses a trust-all SSL context rather than failing closed. This also relates to CWE-297, because the server hostname is not reliably verified, and CWE-636, because a verification request can fail open.
Potential impact
- An on-path attacker could read Vault tokens and secrets sent over the connection.
- An attacker could forge Vault responses that the client may trust.
- Compromised credentials could enable further access, depending on token permissions and environment controls.
- An on-path attacker could read Vault tokens and secrets sent over the connection.
- An attacker could forge Vault responses that the client may trust.
- Compromised credentials could enable further access, depending on token permissions and environment controls.
General mitigation guidance
Use secure-by-default TLS settings that always validate certificate chains and hostnames. Treat missing, malformed, or unexpected verification settings as errors rather than silently disabling checks, and use strict parsing for boolean configuration values. Reduce trust in mutable configuration and serialized objects, avoid trust-all SSL contexts, and limit Vault token permissions to the minimum required.
Use secure-by-default TLS settings that always validate certificate chains and hostnames. Treat missing, malformed, or unexpected verification settings as errors rather than silently disabling checks, and use strict parsing for boolean configuration values. Reduce trust in mutable configuration and serialized objects, avoid trust-all SSL contexts, and limit Vault token permissions to the minimum required.
How teams detect issues like this
Review code for trust-all SSL contexts, permissive trust managers, disabled hostname verification, and configuration paths where TLS verification can default to false. Static analysis and code review can check that every TLS client connection enforces both certificate-chain and hostname validation. Policy checks can reject ambiguous verification settings and require secure TLS defaults; runtime monitoring may also flag unexpected certificate-validation behavior.
Review code for trust-all SSL contexts, permissive trust managers, disabled hostname verification, and configuration paths where TLS verification can default to false. Static analysis and code review can check that every TLS client connection enforces both certificate-chain and hostname validation. Policy checks can reject ambiguous verification settings and require secure TLS defaults; runtime monitoring may also flag unexpected certificate-validation behavior.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| repo. | repo.maven.apache.org/ |
