Spring Boot April 2026: 8 CVEs Including CVE-2026-40976 Critical

On April 23, 2026, the Spring Boot team shipped patch releases addressing eight CVEs in a single coordinated release.

The batch is dominated by a single pattern: misconfigured-by-default auto-configuration paths. Three of the eight CVEs are TLS hostname-verification gaps in SSL-bundle-driven auto-configuration, though their version histories differ significantly: one is a recent 4.0-only regression, one appeared in 3.5, and one has been present since Spring Boot 2.7. Two more are local filesystem issues exposed through Spring Boot's temp-directory and PID-file utilities. A weak-PRNG class, a timing attack on the Spring Boot DevTools remote secret, and one Critical default-security bypass triggered by Spring Boot 4.0's module split round out the cycle.

The Critical (CVE-2026-40976) has its own deep dive and is recapped only briefly here. The other seven CVEs are the focus of this roundup, with the TLS hostname-verification cluster and the local filesystem class treated together because they share remediation patterns.

‍

Summary

‍

The TLS hostname-verification cluster: CVE-2026-40970, CVE-2026-40971, CVE-2026-40974

Three of the eight CVEs are the same shape of bug applied to three different connectors. The shape is identical; the version histories are not.

• CVE-2026-40970 (Elasticsearch): Spring Boot 4.0.0 to 4.0.5 only. A regression introduced when Elasticsearch auto-configuration was wired through the SSL bundle abstraction in 4.0.
• CVE-2026-40971 (RabbitMQ): Spring Boot 3.5.x and 4.0.x. The bug appeared in 3.5 when RabbitMQ auto-configuration adopted the SSL bundle path.
• CVE-2026-40974 (Cassandra): Spring Boot 2.7 through 4.0. A long-standing bug in the Cassandra SSL auto-configuration code path, present on every supported branch and on EOL 2.7.

The mechanism in each case: Spring Boot's SSL bundles abstraction (introduced in 3.1 to centralize TLS configuration across connectors) is wired into the affected connector's auto-configuration in a way that does not propagate the bundle's hostname-verification setting to the underlying client. The application configures a bundle, the configuration loads cleanly, the connector starts, and TLS connections succeed. What does not happen is hostname verification on the certificate presented by the remote service.

The result: a man-in-the-middle attacker who can intercept traffic between the Spring Boot application and its Elasticsearch, RabbitMQ, or Cassandra cluster, and who holds a certificate trusted by the application's truststore but issued for a different hostname, can complete the TLS handshake and observe or modify traffic. In production deployments where the truststore is intentionally permissive (a corporate CA, a vendor-issued cluster CA), this collapses the principal protection that hostname verification is meant to provide.

This is the classic silent-failure pattern. Static configuration review finds nothing wrong: the bundle is declared, the connector references it, and TLS is nominally enabled. Runtime verification, captured TLS handshakes, or a deliberately mismatched certificate test would surface the gap. None of those checks are typical in standard CI pipelines.

The patch wires the hostname-verification setting through to the affected connectors. Compensating controls available before patching are limited: pin the connector configuration to a fully-qualified hostname matching exactly one certificate Subject Alternative Name, narrow the truststore to only the issuing CA for the target service, or disable the affected connector path until patched. None of these scale comfortably to a fleet.

The relationship to other CVEs in this disclosure window is worth noting. CVE-2026-22750, disclosed on April 9, was the same family of bug applied to Spring Cloud Gateway: the spring.ssl.bundle property was silently ignored for outbound proxy connections. Four CVEs across two projects in two weeks all share the same shape.

‍

Local filesystem class: CVE-2026-40973 and CVE-2026-40977

Two CVEs in the batch involve local filesystem behavior. They require local access to be exploited, but the impact when exploited is significant.

CVE-2026-40973: ApplicationTemp predictable directory accepted without ownership verification (CVSS High)

ApplicationTemp is the Spring Boot utility that provides a temporary directory scoped to the application. The vulnerability is that the directory uses a predictable path under the system temp directory, and the application accepts a pre-existing directory at that path without verifying its owner.

A local attacker on the same host who can predict the path can pre-create the directory before the Spring Boot application starts, taking control of its contents. In containerized deployments where each application runs in its own container as a unique user with its own filesystem, this is largely defanged by container isolation. In shared-host deployments (multi-tenant Linux VMs, jump hosts, traditional bare-metal application servers, or any environment where multiple Spring Boot instances run as different users on the same host), an attacker with a local account can take over another user's ApplicationTemp directory.

The Spring advisory describes two impact paths, both gated on server.servlet.session.persistent=true and an attack that persists across application restarts. First, session hijacking: applications that wrote serialized session state into the temp directory expose those sessions to the attacker. Second, deserialization RCE: if the attacker can plant a crafted serialized object that the application later deserializes, they can execute code as the application's user.

The patch verifies ownership of the directory before accepting it.

CVE-2026-40977: ApplicationPidFileWriter symlink-following at predictable default path (CVSS Medium)

ApplicationPidFileWriter writes the running application's PID to a configured file path on startup. The vulnerability is that the writer follows symlinks when opening the target file at the predictable default path.

A local attacker who can place a symlink at the configured PID file path before the Spring Boot application starts (or replace it during application restart) can redirect the PID write to an arbitrary file the application's user account can write to. The result is file truncation: any file the application user owns can be reduced to a few bytes containing the PID.

This is a local denial-of-service primitive. It does not yield code execution or read access. It does, however, allow an attacker to disrupt other applications running as the same user (corrupting their config files, log files, or state files) and to defeat integrity-check tooling that depends on the existence of unmodified files.

The patch refuses to follow symlinks during the PID file write.

‍

Cryptography and randomness: CVE-2026-40975 and CVE-2026-40972

CVE-2026-40975: weak PRNG in RandomValuePropertySource (CVSS Medium)

RandomValuePropertySource resolves ${random.*} placeholders in Spring Boot application properties. The vulnerability is that the values produced by ${random.value} are not suitable for use as secrets because the underlying random source is not cryptographically secure.

The Spring advisory makes three explicit points worth pulling out:

• ${random.value} is the affected placeholder when used as a secret.
• ${random.uuid} is not affected.
• ${random.int} and ${random.long} should never be used as secrets, but for a different reason: they are numeric values with a small, predictable range, not because of PRNG weakness.

The realistic exposure is applications that used ${random.value} to generate one-time tokens, password reset secrets, signing keys, or similar identity-bearing values during application startup or property resolution. Code that used ${random.uuid} for the same purpose is not affected.

The compensating control is to never use ${random.value} for security-sensitive purposes. The Spring Boot documentation now states this explicitly. Upgrading to the patched version is the durable fix.

CVE-2026-40972: timing attack on Spring Boot DevTools remote secret (CVSS High)

This CVE affects Spring Boot's DevTools remote support feature, not generic API authentication. DevTools remote support is a development-time feature that lets a developer push class changes from their IDE to a running remote Spring Boot application. The remote application authenticates incoming class-upload requests by comparing a supplied secret against the value configured via spring.devtools.remote.secret.

The comparison was vulnerable to timing analysis. An attacker on the same network who could send many requests and measure response time precisely could recover the secret over many requests. With the secret recovered, the attacker could then use the legitimate DevTools remote-update mechanism to upload arbitrary classes, achieving remote code execution within the application's process. This RCE path is the reason the CVE is rated High despite the narrow exposure surface.

The exposure surface is narrower than the High severity score suggests, but only if DevTools remote support is configured the way Spring's documentation has long recommended. DevTools remote support is intended for development environments only and should not be enabled in production. The vulnerability matters most for:

• Organizations that have inadvertently shipped DevTools remote support into production builds (typically because spring-boot-devtools was not excluded from the production artifact).
• Development environments accessible to attackers (shared dev clusters, internet-facing dev servers, dev environments on flat corporate networks).

If your team has standardized on excluding spring-boot-devtools from production builds (the recommended configuration), the production exposure is zero. If you are not sure, this is the inventory question to answer first: search built artifacts for the spring-boot-devtools dependency and check whether spring.devtools.remote.secret is set in any non-development profile.

The patch replaces the comparison with a constant-time equivalent. Rate limiting raises the cost of the timing measurement but does not eliminate the bug; the patch is the durable fix.

‍

The Critical: CVE-2026-40976

CVE-2026-40976 is the marquee Critical from this batch. In Spring Boot 4.0, the spring-boot-actuator and spring-boot-health modules were split into separate dependencies. Applications that depend on spring-boot-actuator-autoconfigure but do not depend on spring-boot-health triggered an unintended condition: Spring Boot's default web security filter chain became ineffective, and all endpoints in the application (not just Actuator endpoints) became reachable without authentication.

Per the official Spring advisory, the conditions for vulnerability are:

• The application is a servlet-based web application.
• The application has no Spring Security configuration of its own and relies on the default web security filter chain.
• The application depends on spring-boot-actuator-autoconfigure.
• The application does not depend on spring-boot-health.

If any of those does not apply, the application is not vulnerable.

The CVSS 9.1 score reflects the impact: any web endpoint, not just Actuator, becomes unauthenticated. The Actuator-with-no-Health combination is the trigger; the scope of the bypass is the entire default security filter chain. Applications that already define their own SecurityFilterChain are unaffected because they are not relying on the default.

The full mechanism, the affected configurations, and detailed remediation guidance are in the CVE-2026-40976 deep dive. The short version: the fix is in Spring Boot 4.0.6, the vulnerability is scoped to Spring Boot 4.0.0 through 4.0.5 (the module split is a 4.0 change, so older branches do not have the unsafe dependency configuration available), and the underlying lesson is that dependency-graph completeness now affects security-filter activation in a way it did not before the 4.0 module split.

‍

How regulated enterprises are responding

For organizations under SOC 2 or ISO 27001 scrutiny, the TLS hostname-verification cluster is the kind of finding that lands hard in audit reports. "Hostname verification is configured" is a common control statement; "hostname verification is configured but the framework silently disables it" is the kind of compensating-control conversation that takes weeks to close. A global financial services customer running a Spring Boot footprint across multiple business units worked with HeroDevs to remediate similar configuration-driven CVEs without requiring an emergency major-version upgrade across the entire fleet; that engagement is summarized in the Proactive Security for Mission-Critical Systems case study, and the pattern (continuous patching on EOL branches while migration runs on a longer timeline) applies cleanly to the April 23 batch.

The EU Cyber Resilience Act deadline of September 2026 makes this batch particularly relevant. The "auto-configuration silently disables hostname verification" pattern is precisely the kind of secure-default failure CRA Annex I will scrutinize. Three of these eight CVEs (the SSL hostname-verification cluster) and one of the others (CVE-2026-40976, where the default security filter chain became inactive in a common dependency configuration) all fit that pattern. Several of these CVEs affect Spring Boot 3.x and 2.7 branches that large enterprises will still be running well after the CRA enforcement window opens. Either those branches move forward, or the patches arrive through a commercial stream.

‍

Related CVEs

• CVE-2026-40976: Spring Boot 4.0 default security bypass deep dive for the Critical from this batch
• CVE-2026-22750: Spring Cloud Gateway SSL bundle bypass deep dive, the same family of "TLS configuration silently ignored" bug applied to Spring Cloud Gateway two weeks earlier
• March 2026 Spring CVE roundup covering the prior month's six-CVE batch
• Spring Boot authentication bypass deep dive (CVE-2026-22731 and CVE-2026-22733) covering the March Boot Actuator bypasses
• Spring CVEs Surge in 2026 for the cross-batch trend
• Spring EOL Hub for the version-by-version end-of-life timeline

‍

Taking action

The April 23 Spring Boot batch is a clear inflection point. Eight CVEs in one release, dominated by auto-configuration paths that quietly weakened security controls, with a CVSS 9.1 Critical at the top. The supported branches (3.3, 3.4, 3.5, 4.0) have a clear upgrade path through the patch versions shipped that day. The EOL branches (1.5, 2.5, 2.7, 3.0, 3.1, 3.2) do not.

If your organization runs Spring Boot on any branch from 1.5 through 3.2 and a multi-quarter major-version upgrade is not realistic, HeroDevs NES for Spring delivers a secure, drop-in replacement that resolves the applicable subset of these eight CVEs (plus the rest of the March and April 2026 Spring disclosure window) without an emergency migration. The remediation arrives through your existing Maven or Gradle dependency configuration and ships through HeroDevs' private artifact registry.

For teams with EU CRA obligations starting in September 2026, the TLS hostname-verification cluster is the cleanest possible illustration of why secure-defaults failures fall under Annex I. The patch path is the question; the deadline is no longer flexible.