Vault-java-driver silently disables TLS certificate and hostname verification when users request verification through an SslConfig instance that is not fully built, through deserialized configuration objects, or via the VAULT_SSL_VERIFY environment variable set to an ambiguous truthy value. The driver therefore installs a trust‑all SSLContext, which allows any network‑level attacker to eavesdrop on the TLS session, read Vault tokens and secrets passing through, and forge Vault responses. This flaw represents a severe privacy compromise and can enable an attacker to impersonate legitimate Vault clients or inject malicious data.

The vulnerability affects the jopenlibs vault-java-driver Java client for HashiCorp Vault. Versions 5.2.0 through 6.2.3 are impacted, while 7.0.0 and later contain the fix. The flaw resides in the library’s SSL configuration handling; clients that rely on this driver to communicate with Vault servers are in scope.

With a CVSS score of 7.4 the flaw is considered high severity. The EPSS score is not available, but the lack of detection in KEV indicates the exploit has not yet been widely reported. The attack is feasible for anyone with network access to the Vault server, as it simply requires intercepting the TLS handshake. Because the driver silently lowers the verification level without indicating a failure, the vulnerability is hard to detect without a code audit. The combination of a clear path to data exposure and a relatively straightforward exploitation makes the risk significant for systems that use the affected driver version.