Spring Boot Elasticsearch SSL Bundle TLS Hostname Verification Bypass
CVE-2026-40970 is an improper TLS certificate hostname validation vulnerability in Spring Boot Elasticsearch auto-configuration. In Spring Boot versions 4.0.0 through 4.0.5, configuring the Elasticsearch client with an SSL bundle causes the auto-configured connection not to perform TLS hostname verification of the Elasticsearch server certificate. Consequently, a certificate that chains to a trusted authority but is issued for a different hostname may be accepted.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An on-path attacker, or an attacker able to redirect traffic to a malicious Elasticsearch endpoint, may impersonate the intended Elasticsearch server using a trusted certificate whose identity does not match the configured server hostname. This can enable interception or modification of application-to-Elasticsearch traffic and may expose credentials, queries, indexed data, and responses handled over the affected connection.
If you can’t patch tonight, do this now.
Until an upgrade can be applied, avoid using the affected Elasticsearch auto-configuration SSL-bundle path where feasible. Restrict network paths between the application and Elasticsearch, prevent unauthorized routing or DNS changes, and use private, tightly controlled network connectivity to reduce opportunities for TLS interception.
Patch, then assume compromise.
Upgrade Spring Boot to version 4.0.6 or later, which restores hostname verification for Elasticsearch auto-configuration when an SSL bundle is used.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
5 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.