What is the CVSS score of CVE-2026-40992?

CVE-2026-40992 has a CVSS 3.1 base score of 5.0 (Medium). CVSS vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-40992?

Yes, a patch is available for CVE-2026-40992. Update the affected software to the latest version immediately.

Spring Boot CVE-2026-40992

EUVD-2026-36203 MEDIUM

Improper Certificate Validation (CWE-295)

2026-06-11 vmware

GHSA-9wxp-w4px-32vh

Java Information Disclosure Spring Boot

5.0

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

5.0 MEDIUM

AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

vuln.today AI

4.2 MEDIUM

Adjacent network MitM required (AV:A/AC:H); no privileges needed; confidentiality and integrity at risk but availability impact unsupported by the interception-only threat model.

3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

4.0 AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Patch available

Jun 11, 2026 - 08:01 EUVD

Analysis Generated

Jun 11, 2026 - 07:07 vuln.today

DescriptionCVE.org

Spring Boot's Mail auto-configuration does not enable hostname verification. Applications that set the relevant JavaMail property, such as spring.mail.properties.mail.smtp.ssl.checkserveridentity=true, are not affected.

Affected versions: Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16.

AnalysisAI

Spring Boot's Mail auto-configuration omits hostname verification for SMTP over TLS/SSL, leaving applications exposed to man-in-the-middle interception of outbound email traffic on adjacent network segments. Three active release lines are affected - 3.4.x through 3.4.16, 3.5.x through 3.5.14, and 4.0.x through 4.0.6 - unless the deploying application has explicitly set the JavaMail property spring.mail.properties.mail.smtp.ssl.checkserveridentity=true to override the insecure default. No public exploit has been identified at time of analysis, but the flaw is present by default in any Spring Boot application that uses the built-in Mail auto-configuration with TLS/SSL and has not applied the corrective property.

Technical ContextAI

Spring Boot's auto-configuration layer (org.springframework.boot.autoconfigure.mail) provisions JavaMail Session beans without enabling the smtp.ssl.checkserveridentity property, which is the JavaMail mechanism that instructs the JSSE layer to validate that the server certificate's subject name matches the target hostname. CWE-295 (Improper Certificate Validation) is the root cause class: the TLS handshake succeeds and the certificate chain may be valid, but without hostname binding an attacker can present any certificate from a trusted CA for an unrelated domain. The affected CPE is cpe:2.3:a:spring:spring_boot:*:*:*:*:*:*:*:*, covering the Spring Boot artifact as distributed by VMware (Broadcom). The vulnerability surfaces only on SMTP connections that traverse a TLS session; plaintext SMTP (port 25 without STARTTLS or SSL) is unaffected by this control but carries its own risks.

RemediationAI

The immediate workaround - which is also fully protective - is to add spring.mail.properties.mail.smtp.ssl.checkserveridentity=true to application.properties or application.yml in all affected deployments; this explicitly re-enables hostname verification and is noted by the vendor as sufficient to prevent exploitation with no functional side effects on compliant mail servers. For a permanent fix, upgrade to a patched Spring Boot release; exact fixed versions are not confirmed in the provided input data and must be obtained from the vendor advisory at https://spring.io/security/cve-2026-40992 before applying. Organizations that cannot upgrade or add the property immediately should restrict outbound SMTP to trusted relay hosts via network egress controls, reducing the opportunity for network-level MitM, though this does not eliminate the underlying misconfiguration.