CVE-2026-109408: vault-java-driver: SslConfig silently disables requested TLS verification
vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULTSSLVERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.github.jopenlibs:vault-java-driverto a version that resolves this vulnerability.Fixed in 7.0.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using io.github.jopenlibs:vault-java-driver versions 5.2.0 through 6.2.3 are exposed only when they use one of the affected verification-requesting states: an SslConfig passed without build(), a deserialized SslConfig, or VAULT_SSL_VERIFY set to a truthy value other than exactly "true".
What must an attacker be able to do to exploit this?
An attacker must be on the network path between the application and the Vault server. In an affected state, the driver installs a trust-all SSLContext, allowing the attacker to intercept TLS traffic and forge Vault responses.
What is the impact if exploitation succeeds?
The attacker can read the Vault token and secrets transmitted between the application and Vault. They can also forge responses returned to the application.
How can teams tell whether their configuration is affected?
Check whether the application uses a vulnerable driver version and passes an SslConfig to VaultConfig before calling build(), restores SslConfig through Java deserialization, or sets VAULT_SSL_VERIFY to values such as 1, yes, or on rather than exactly "true". In these cases, SslConfig.isVerify() returns false despite verification being requested.
What version fixes the issue?
Upgrade to vault-java-driver 7.0.0, which fixes the issue.