CVE-2026-109408
Received Received - Intake

TLS Certificate Verification Bypass in vault-java-driver

Publication date: 2026-11-05

Last updated on: 2026-11-05

Assigner: Echo

Description
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 VAULT_SSL_VERIFY 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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-11-05
Last Modified
2026-11-05
Generated
2026-11-05
AI Q&A
2026-11-05
EPSS Evaluated
N/A
NVD
CVE-2026-109408
EUVD
EUVD-2026-117400

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
jopenlibs vault-java-driver 5.2.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-297 The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
CWE-636 When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
CWE-295 The product does not validate, or incorrectly validates, a certificate.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

The vault-java-driver Java client for HashiCorp Vault has a flaw where TLS certificate and hostname verification is silently disabled in three scenarios: when an SslConfig is passed without calling build(), during Java deserialization of SslConfig, or when VAULT_SSL_VERIFY is set to a truthy value other than 'true' (e.g., 1, yes, on). This causes the driver to install a trust-all SSLContext, allowing network attackers to intercept Vault tokens and secrets or forge responses.

Detection Guidance

Check if your application uses vault-java-driver versions 5.2.0 through 6.2.3. Inspect logs for SSLContext configurations that bypass certificate verification. Use network monitoring tools to detect unencrypted Vault token or secret transmissions.

Impact Analysis

An attacker on the network path to the Vault server could read transmitted Vault tokens and secrets, or inject malicious responses. This compromises confidentiality and integrity of sensitive data stored in or accessed via Vault.

Compliance Impact

This vulnerability likely violates compliance requirements for data protection (e.g., GDPR Article 32, HIPAA Security Rule) by failing to ensure secure transmission of sensitive data. Unauthorized interception of tokens and secrets could result in data breaches, leading to regulatory penalties and loss of trust.

Mitigation Strategies

Upgrade to vault-java-driver version 7.0.0 or later. Ensure SSL verification is explicitly enabled in configurations. Review environment variables like VAULT_SSL_VERIFY to avoid truthy values that disable verification.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-109408. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart

Security Radar

News mentioning this vulnerability
Loading related security news...