CVE-2026-40974: Spring Boot SSL Hostname Vulnerability

CVE-2026-40974 Overview

CVE-2026-40974 is a certificate validation bypass vulnerability in Spring Boot's Cassandra auto-configuration. When establishing SSL connections to Cassandra databases, the affected versions fail to perform hostname verification, potentially allowing man-in-the-middle attacks against applications that rely on SSL/TLS for secure database connections.

This vulnerability affects the SSL auto-configuration component used when connecting Spring Boot applications to Apache Cassandra instances. Without proper hostname verification, an attacker positioned on an adjacent network could intercept and potentially modify traffic between the application and the database server, even when SSL is enabled.

Critical Impact

Applications using Spring Boot's Cassandra auto-configuration with SSL may be vulnerable to man-in-the-middle attacks, potentially exposing sensitive data transmitted to and from the database.

Affected Products

• Spring Boot 4.0.0 – 4.0.5 (fix in 4.0.6)
• Spring Boot 3.5.0 – 3.5.13 (fix in 3.5.14)
• Spring Boot 3.4.0 – 3.4.15 (fix in 3.4.16)
• Spring Boot 3.3.0 – 3.3.18 (fix in 3.3.19)
• Spring Boot 2.7.0 – 2.7.32 (fix in 2.7.33)

Discovery Timeline

• April 28, 2026 - CVE-2026-40974 published to NVD
• April 28, 2026 - Last updated in NVD database

Technical Details for CVE-2026-40974

Vulnerability Analysis

This vulnerability is classified as CWE-295 (Improper Certificate Validation). The core issue lies in Spring Boot's Cassandra auto-configuration module, which establishes SSL/TLS connections without verifying that the hostname in the server's certificate matches the hostname being connected to.

SSL/TLS certificate validation consists of two critical checks: verifying the certificate chain against trusted certificate authorities, and verifying that the certificate's Common Name (CN) or Subject Alternative Name (SAN) matches the intended server hostname. When hostname verification is skipped, an attacker with a valid certificate from any trusted CA—or who has compromised any certificate in the trust chain—can impersonate the legitimate Cassandra server.

The vulnerability requires an adjacent network position (such as the same local network segment, VLAN, or cloud VPC) to exploit, which somewhat limits the attack surface compared to remotely exploitable vulnerabilities.

Root Cause

The root cause is the missing hostname verification step in Spring Boot's SSL socket factory configuration for Cassandra connections. When auto-configuring SSL connections to Cassandra, the framework properly initiates SSL/TLS handshakes but does not enforce that the server certificate's hostname fields match the target server's hostname. This allows any valid certificate to be accepted, regardless of which host it was issued for.

Attack Vector

Exploitation requires the attacker to be positioned on an adjacent network where they can intercept traffic between the Spring Boot application and the Cassandra database. The attacker would need to:

1. Position themselves on the network path between the application and database (via ARP spoofing, DNS hijacking, or similar techniques on the local network)
2. Present a valid SSL certificate from a trusted Certificate Authority
3. Intercept and proxy (or modify) the traffic between the application and the legitimate Cassandra server

Since hostname verification is not performed, the application accepts the attacker's certificate as valid, establishing an encrypted connection with the attacker rather than the intended database server. The attacker can then decrypt, inspect, and potentially modify all database queries and responses.

The attack complexity is considered high because it requires network-level access and the ability to perform traffic interception on the same network segment, which is not trivial in properly segmented enterprise environments.

Detection Methods for CVE-2026-40974

Indicators of Compromise

• Unexpected certificate warnings or errors in application logs when connecting to Cassandra
• Network traffic anomalies showing connections to Cassandra endpoints being routed through unexpected intermediate hosts
• ARP spoofing or DNS poisoning attempts detected on the network segment hosting the application
• Unusual latency patterns in Cassandra connections that may indicate traffic interception and proxying

Detection Strategies

• Audit Spring Boot application dependencies to identify vulnerable versions (2.7.0-2.7.32, 3.3.0-3.3.18, 3.4.0-3.4.15, 3.5.0-3.5.13, 4.0.0-4.0.5)
• Review application configurations for Cassandra SSL settings and verify hostname verification is explicitly enabled
• Monitor for abnormal network patterns such as ARP table changes or DNS response modifications on application server segments
• Implement network intrusion detection to identify potential man-in-the-middle positioning attempts

Monitoring Recommendations

• Enable verbose SSL/TLS logging in Spring Boot applications to capture certificate details during Cassandra connection establishment
• Deploy network monitoring to detect ARP spoofing, DNS hijacking, or other traffic redirection attempts
• Monitor application logs for certificate validation errors or connection anomalies to Cassandra endpoints
• Implement certificate pinning monitoring where feasible to detect unauthorized certificate usage

How to Mitigate CVE-2026-40974

Immediate Actions Required

• Upgrade Spring Boot to a patched version: 4.0.6, 3.5.14, 3.4.16, 3.3.19, or 2.7.33
• Review all applications using Spring Boot's Cassandra auto-configuration with SSL enabled
• Ensure network segmentation is in place to limit adjacent network attack vectors
• Consider implementing additional network-level protections such as IPsec or mutual TLS for database connections

Patch Information

VMware/Broadcom has released patched versions across all affected Spring Boot release branches. Organizations should upgrade to one of the following fixed versions based on their current branch:

For detailed patch information, refer to the Spring Security Advisory for CVE-2026-40974.

Workarounds

• Implement network segmentation to ensure Cassandra connections traverse only trusted network paths
• Use VPNs, IPsec tunnels, or other network-layer encryption for the connection path between applications and Cassandra
• Consider implementing certificate pinning at the application level to explicitly trust only the expected Cassandra server certificate
• Manually configure the Cassandra driver SSL context with explicit hostname verification enabled, bypassing the auto-configuration

# Example: Update Spring Boot dependency in Maven pom.xml
# Locate and update the spring-boot-starter-parent or spring-boot-dependencies version

# For Maven projects, update pom.xml:
# <parent>
#     <groupId>org.springframework.boot</groupId>
#     <artifactId>spring-boot-starter-parent</artifactId>
#     <version>3.3.19</version>  <!-- Updated from vulnerable version -->
# </parent>

# For Gradle projects, update build.gradle:
# plugins {
#     id 'org.springframework.boot' version '3.3.19'  // Updated from vulnerable version
# }