GPU VulnDB

Database/Control plane, storage & DevOps

vault-java-driver: TLS verification silently disabled in three configuration states

CVSS 7.4CVE-2026-109408Control plane, storage & DevOpscurated

Impact

A Java client that asked for TLS verification against HashiCorp Vault can end up with a trust-all SSLContext in three cases: an SslConfig handed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than the literal "true" (1, yes, on). Anyone on the network path between the application and Vault can then read the Vault token and every secret the application fetches, and forge Vault responses back to it. For an operator this is a secrets-management exposure: a leaked Vault token from a job running on the fleet can be replayed against Vault directly, so the blast radius is whatever that token's policy allows, not just the one application. Affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3.

Who can reach it

An attacker in a position to intercept or redirect traffic between the application and the Vault server - a compromised node on the path, a hostile pod on the same network, or anyone who can influence routing or DNS. No authentication required; the CVSS vector rates attack complexity high because the misconfiguration state must be present.

What to do

Upgrade the dependency to io.github.jopenlibs:vault-java-driver 7.0.0, rebuild and redeploy the affected applications. Until then, set VAULT_SSL_VERIFY to exactly "true" and make sure every SslConfig is constructed through build(). Rotate any Vault tokens or secrets that may have crossed an unverified connection.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.