CVE-2026-40992

Overview

Spring Boot is a framework that simplifies building production-ready, stand-alone Java applications on top of the Spring ecosystem, providing auto-configuration, embedded servers, and opinionated defaults. Its Mail auto-configuration builds a JavaMailSenderImpl from spring.mail.* properties so applications can send email over SMTP or SMTPS without wiring the client by hand.

A medium-severity vulnerability (CVE-2026-40992) has been identified in Spring Boot's Mail auto-configuration. When an application enables SSL for the mail client through spring.mail.ssl.enabled=true or configures an SSL bundle through spring.mail.ssl.bundle, the auto-configuration sets mail.<protocol>.ssl.enable and the SSL socket factory but never sets mail.<protocol>.ssl.checkserveridentity. With JavaMail, TLS hostname verification is off unless that property is explicitly enabled, so the auto-configured mail client establishes SSL connections without verifying that the server certificate matches the SMTP host. An attacker positioned on the network path can present any valid-but-mismatched certificate and intercept the connection, exposing credentials and message contents. Applications that already set spring.mail.properties.mail.smtp.ssl.checkserveridentity=true themselves are not affected.

Per OWASP, a manipulator-in-the-middle attack lets an adversary who can intercept traffic between two parties relay and alter the communication; failing to verify a server certificate's hostname removes the protection TLS is meant to provide against exactly this class of attack.

This issue affects versions >=3.4.0 <3.4.17, >=3.5.0 <3.5.15, and >=4.0.0 <4.0.7 of Spring Boot.

‍

Details

Module Info

• Product: Spring Boot
• Affected packages: spring-boot-autoconfigure
• Affected versions: >=3.4.0 <3.4.17, >=3.5.0 <3.5.15, >=4.0.0 <4.0.7
• 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
• Spring Boot 4.0.7, 3.5.15 (OSS)

Vulnerability Info

The mail client is assembled by MailSenderPropertiesConfiguration. When SSL is enabled or an SSL bundle is configured, its applyProperties method populates the JavaMail properties that turn SSL on but omits the property that enables hostname verification:

Ssl ssl = properties.getSsl();
if (ssl.isEnabled()) {
    javaMailProperties.setProperty("mail." + protocol + ".ssl.enable", "true");
}
if (ssl.getBundle() != null) {
    SslBundle sslBundle = sslBundles.getBundle(ssl.getBundle());
    javaMailProperties.put("mail." + protocol + ".ssl.socketFactory",
            sslBundle.createSslContext().getSocketFactory());
}

‍

Because mail.<protocol>.ssl.checkserveridentity is never set, JavaMail performs the TLS handshake and accepts the server certificate without checking that its subject matches the SMTP host. An attacker who can intercept the SMTP/SMTPS connection can therefore present a certificate issued for a different host and the mail client will proceed, allowing the credentials sent during SMTP authentication and the contents of outgoing mail to be observed or modified.

The remediation enables hostname verification by default: a new verify-hostname setting (defaulting to true) causes the auto-configuration to set mail.<protocol>.ssl.checkserveridentity=true whenever SSL or an SSL bundle is in use, so the auto-configured client verifies the server identity unless an operator deliberately opts out.

This vulnerability was introduced in 2024 with Spring Boot 3.4.

‍

Mitigation

The affected Spring Boot lines covered by HeroDevs Never-Ending Support are past their open-source end-of-life, and the affected 3.4.x line has no publicly available fix; the upstream advisory ships public (OSS) fixes only for the still-maintained 4.0.x and 3.5.x lines, while the 3.4.x line received no public OSS release.

Recommended actions:

1. Upgrade to a supported Spring Boot version that contains the fix (Spring Boot 4.0.7 or 3.5.15) where feasible.
2. For applications that must remain on an end-of-life Spring Boot line, use HeroDevs Never-Ending Support (NES) for Spring Boot, which provides a backported fix for this vulnerability on otherwise unsupported lines.

As an interim configuration-level hardening, set spring.mail.properties.mail.smtp.ssl.checkserveridentity=true (and mail.smtps.ssl.checkserveridentity=true for SMTPS) so the mail client verifies the server's hostname even on unpatched versions.