CVE-2026-40974

Overview

Spring Boot is a convention-over-configuration framework for building stand-alone, production-grade applications on the Spring platform. Its auto-configuration for Apache Cassandra wires up a CqlSession (DataStax Java driver 4, or Cluster on the driver 3 line used by pre-2.3 Boot) from spring.cassandra.* (or legacy spring.data.cassandra.*) properties, including an opt-in SSL mode that Spring Boot configures on behalf of the DataStax driver.

A medium-severity vulnerability (CVE-2026-40974) has been identified in that auto-configuration. When an application enables SSL to Cassandra, Spring Boot hands the driver an SSLContext or SslEngineFactory that does not request TLS hostname verification. The DataStax driver honors exactly what it is given, so the resulting SSLEngine never sets SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") and the client accepts any certificate that chains to a trusted CA, regardless of the hostname in the certificate. An attacker on an adjacent network who can intercept the TCP stream to the Cassandra cluster and present a valid-but-wrong certificate, can impersonate the cluster, read queries and result rows, and alter CQL traffic in flight.

Per OWASP: a manipulator-in-the-middle attack "allows a malicious actor to intercept, send and receive data to and from two parties communicating with each other but never letting them know that the 'middle man' exists." TLS is meant to block that attack class by binding each session to a specific server identity; skipping hostname verification leaves only the CA-chain check in place, which is not enough to stop an attacker who can obtain any certificate the client trusts.

The CVSS v3.1 base score for this vulnerability is 3.9 (advisory classifies it as Medium) with vector AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L. Attack vector is adjacent network, attack complexity is high (the attacker needs both network position and a certificate the client trusts issued to a different host), no privileges or user interaction are required, and impact to confidentiality, integrity, and availability are each low.

Spring Boot's Cassandra auto-configuration has skipped hostname verification since Cassandra support was first added in Spring Boot 1.3 (December 2014). The DataStax driver 3 path (Cluster.Builder.withSSL()) and the DataStax driver 4 path (CqlSessionBuilder.withSslContext(SSLContext.getDefault()), and later the 2-argument ProgrammaticSslEngineFactory(SSLContext, String[]) constructor used when an SSL bundle is configured) all default to hostname verification disabled. This issue affects versions 1.3.0 through 2.7.32, 3.0.0 through 3.3.18, 3.4.0 through 3.4.15, 3.5.0 through 3.5.13, and 4.0.0 through 4.0.5 of Spring Boot.

‍

Details

Module Info

• Product: Spring Boot
• Affected packages: spring-boot-autoconfigure
• Affected versions: >=1.3.0 <=2.7.32, >=3.0.0 <=3.3.18, >=3.4.0 <=3.4.15, >=3.5.0 <=3.5.13, >=4.0.0 <=4.0.5
• GitHub repository: https://github.com/spring-projects/spring-boot
• Published packages: https://central.sonatype.com/artifact/org.springframework.boot/spring-boot-autoconfigure
• Package manager: Maven
• Fixed in:
• NES for Spring Boot 1.5.x, 2.5.x, 2.7.x, 3.2.x, 3.3.x, 3.4.x
• OSS Spring Boot 3.5.14, 4.0.6

‍

Vulnerability Info

The vulnerability is in CassandraAutoConfiguration in the spring-boot-autoconfigure module. The class configures a CqlSession (or a Cluster on pre-2.3 Spring Boot) on behalf of the application and applies the application's SSL properties when SSL is enabled.

An application is vulnerable when all of the following are true:

• The application uses Spring Boot's Cassandra auto-configuration (it does not define its own CqlSession/Cluster bean).
• The application enables Cassandra SSL via spring.cassandra.ssl.enabled=true, spring.cassandra.ssl.bundle=<name>, the legacy spring.data.cassandra.ssl=true, or a connection-details bean that returns a non-null SslBundle.
• The application does not supply a CqlSessionBuilderCustomizer, DriverConfigLoaderBuilderCustomizer, or ClusterBuilderCustomizer that installs a custom SslEngineFactory/SSLOptions with HTTPS endpoint identification enabled.

Prior to the fix, CassandraAutoConfiguration.configureSsl on Spring Boot 3.1 and later looked like this:

private void configureSsl(CqlSessionBuilder builder, CassandraConnectionDetails connectionDetails) {
    SslBundle sslBundle = connectionDetails.getSslBundle();
    if (sslBundle == null) {
        return;
    }
    SslOptions options = sslBundle.getOptions();
    Assert.state(options.getEnabledProtocols() == null, "SSL protocol options cannot be specified with Cassandra");
    builder
        .withSslEngineFactory(new ProgrammaticSslEngineFactory(sslBundle.createSslContext(), options.getCiphers()));
}

‍

The 2-argument constructor ProgrammaticSslEngineFactory(SSLContext sslContext, String[] cipherSuites) is documented by DataStax as building a factory with "no host name validation." The factory creates an SSLEngine whose SSLParameters never have setEndpointIdentificationAlgorithm("HTTPS") called on them, so hostname verification never runs.

On Spring Boot 2.3 through 3.0 (and also on 3.1+ when no SSL bundle is configured), auto-configuration takes a different code path that calls:

builder.withSslContext(SSLContext.getDefault());

‍

CqlSessionBuilder.withSslContext(SSLContext) is a convenience method in the DataStax driver 4 that, per the driver's own documentation, does not support customising cipher suites or enabling hostname validation; hostname validation is off.

On Spring Boot 1.3 through 2.2 (DataStax driver 3), the same code path reduces to:

if (properties.isSsl()) {
    builder.withSSL();
}

‍

Cluster.Builder.withSSL() is a shortcut for withSSL(JdkSSLOptions.builder().build()). The resulting SSLOptions do not call setEndpointIdentificationAlgorithm("HTTPS"), so the driver 3 client also accepts certificates issued for any host.

In all three code paths, the certificate-chain check still runs (the client will reject a certificate chained to an untrusted CA), but the hostname check is skipped. An attacker who can obtain any certificate the client trusts (for example, a mis-issued certificate, a tenant-issued cert on a shared PKI, or a cert from a CA added to the application's trust store for unrelated reasons) can redirect Cassandra traffic through their own proxy via DNS, ARP, or routing manipulation and will not be detected by the TLS layer.

The caller passes this.properties.getSsl().isVerifyHostname(), and DataStax's 3-argument ProgrammaticSslEngineFactory(SSLContext, String[], boolean) constructor sets the HTTPS endpoint-identification algorithm on the engine when the flag is true. Applications that need to preserve the old behavior (for example, connecting by IP in a lab) can set spring.cassandra.ssl.verify-hostname=false explicitly, which reintroduces the weakness this CVE fixes and is not recommended.

‍

Mitigation

Only recent versions of Spring Boot receive community support and updates. The 2.7.x, 3.3.x, and 3.4.x lines that this advisory lists as "Enterprise Support Only" do not have a publicly available fix for this vulnerability; neither do earlier end-of-life lines such as 1.3.x, 1.5.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x, 2.4.x, 2.5.x, 2.6.x, 3.0.x, 3.1.x, and 3.2.x.

Users of the affected components should apply one of the following mitigations:

1. Upgrade to a currently supported OSS version of Spring Boot (3.5.14 or 4.0.6 or later).
2. Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support NES for Spring Boot.

‍

Credits

No external finder is credited in the upstream advisory as of April 24, 2026.