Spring Boot Elasticsearch auto-configuration TLS hostname verification disablement

The primary impact is loss of server identity verification for TLS-protected Elasticsearch connections. An attacker positioned to intercept or redirect traffic could impersonate the Elasticsearch server using a certificate chaining to a trusted CA or otherwise accepted by the client, enabling man-in-the-middle interception or modification of application-to-Elasticsearch traffic. Depending on what the application sends to and receives from Elasticsearch, this could expose indexed data, credentials or tokens present in requests, search results, and operational metadata, and could undermine the integrity and confidentiality guarantees expected from TLS.

If immediate upgrade is not possible, avoid the vulnerable auto-configuration path by using a configuration approach that explicitly enforces TLS hostname verification for Elasticsearch connections. Reduce exposure by preventing attacker-controlled network paths between the application and Elasticsearch, restricting Elasticsearch connectivity to trusted internal networks, and using certificates tightly scoped to the correct hostnames. These are compensating controls only; the authoritative fix is upgrading to Spring Boot 4.0.6 or later.

Upgrade Spring Boot to 4.0.6 or later, as indicated by the vendor advisory. The fixed release restores proper hostname verification behavior for Elasticsearch auto-configuration when SSL bundles are used. Validate that deployed applications are rebuilt and redeployed against the patched Spring Boot version and confirm Elasticsearch TLS settings enforce normal certificate and hostname checks.