CVE-2026-40970: 
Java vulnerability analysis and mitigation

CVE-2026-40970 is a missing TLS hostname verification vulnerability in Spring Boot's Elasticsearch auto-configuration. When a Spring Boot application is configured to use an SSL bundle, the Elasticsearch auto-configuration omits hostname verification when establishing connections to the Elasticsearch server, enabling man-in-the-middle (MITM) attacks. The vulnerability affects Spring Boot versions 4.0.0 through 4.0.5 (Maven artifact org.springframework.boot:spring-boot-elasticsearch), and was publicly disclosed on April 27, 2026, with the initial vendor report published April 23, 2026. It carries a CVSS v3.1 base score of 6.8 (High) per Feedly/NVD, or 5.0 (Moderate) per the GitHub Advisory Database and ENISA EUVD (Spring Advisory, GitHub Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation): when an SSL bundle is configured, Spring Boot's Elasticsearch auto-configuration fails to validate that the server's certificate hostname matches the intended Elasticsearch server hostname. This allows an attacker positioned on the adjacent network to present a valid SSL certificate issued for a different hostname and successfully complete the TLS handshake without detection. Exploitation requires the attacker to be on the same network segment as the Spring Boot application (adjacent network attack vector) and involves high attack complexity, as the attacker must intercept and redirect traffic between the application and the Elasticsearch server. The vulnerability was responsibly disclosed by Yu Bao (@August829) of PayPal (Spring Advisory, GitHub Advisory).

A successful exploit allows an adjacent-network attacker to conduct a MITM attack against the TLS-protected channel between a Spring Boot application and its Elasticsearch backend, compromising both the confidentiality and integrity of data in transit. Sensitive data indexed in or queried from Elasticsearch — which may include application data, logs, or user records — could be intercepted or tampered with. Availability is not directly impacted, but data integrity compromise could have downstream effects on application correctness (Spring Advisory, GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.014% (0.029% per GitHub Advisory), placing it in a low exploitation probability tier. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement for adjacent network positioning and high attack complexity, limiting the realistic attacker pool (GitHub Advisory, Spring Advisory).

1. Reconnaissance: Identify Spring Boot applications (versions 4.0.0–4.0.5) on the target network that are configured with an SSL bundle for Elasticsearch connectivity.
2. Network Positioning: Gain a foothold on the same network segment as the target Spring Boot application (e.g., via ARP spoofing, rogue access point, or compromised network device) to enable traffic interception.
3. Traffic Interception: Use a MITM tool (e.g., mitmproxy, ettercap, or bettercap) to intercept TLS traffic between the Spring Boot application and the Elasticsearch server.
4. Certificate Substitution: Present a valid SSL certificate issued for a different hostname during the TLS handshake. Because hostname verification is disabled, the Spring Boot client accepts the certificate without validating the hostname.
5. Data Interception/Manipulation: Relay and inspect or modify Elasticsearch queries and responses in transit, exfiltrating sensitive data or injecting malicious responses back to the application (Spring Advisory, GitHub Advisory).

• Network: Unexpected ARP table changes or duplicate MAC addresses on the network segment hosting the Spring Boot application; TLS connections to Elasticsearch where the server certificate's CN/SAN does not match the configured Elasticsearch hostname.
• Logs: Spring Boot application logs showing TLS handshake completions with certificates from unexpected issuers or subjects; Elasticsearch access logs showing connections from unexpected intermediate IP addresses rather than the application server's IP.
• Process/Configuration: Spring Boot applications configured with spring.elasticsearch.restclient.ssl.bundle or equivalent SSL bundle properties on versions 4.0.0–4.0.5 should be treated as potentially exposed.

The vendor-recommended remediation is to upgrade Spring Boot to version 4.0.6 or later, which restores proper TLS hostname verification in the Elasticsearch auto-configuration. No additional workarounds are required after upgrading. As an interim measure prior to patching, organizations should implement network-level controls to restrict adjacent network access to the application-Elasticsearch communication path, and monitor for anomalous SSL certificate usage. The fix is available as OSS (Spring Advisory, GitHub Advisory).

The vulnerability was responsibly reported by Yu Bao (@August829) of PayPal and acknowledged by the Spring/Broadcom security team. Red Hat opened a tracking bug (BZ#2463297) and assigned it medium severity, with a broad CC list indicating active triage across multiple product teams. Coverage has been picked up by security aggregators including Tenable (Nessus plugin 310806), VulDB, and HeroDevs, the latter covering it as part of a broader Spring Boot April 2026 CVE roundup (Red Hat Bugzilla, GitHub Advisory).