Spring Boot Managed Dependencies Still Get CVEs After EOL: May 2026 Patch Round-Up

When Spring Boot reaches end-of-life, the framework stops getting dependency updates. The dependencies themselves do not stop getting CVEs. The May 2026 evidence: 24 unique upstream CVEs across Tomcat, Netty, Thymeleaf, Jetty, and pgjdbc, every one of them reachable through the Spring Boot managed-dependency BOM, none of them visible from upstream Spring advisories alone.
‍

The Dependency-Management Problem

Spring Boot does more than ship the Spring framework. It ships a curated dependency graph. The spring-boot-dependencies BOM pins specific versions of Apache Tomcat, Netty, Thymeleaf, Jetty, the PostgreSQL JDBC driver, Jackson, Hibernate, Liquibase, and dozens of other libraries. When a Spring Boot patch release ships on a maintained line, those pinned versions can advance with it.

That advancement stops when the Boot line reaches end-of-life. The BOM is frozen at whatever versions Boot pinned at its final OSS release. The upstream Apache, Netty, Thymeleaf, Jetty, and pgjdbc projects keep shipping, and their CVEs keep getting disclosed and patched in those releases. None of that flows into a frozen dependency tree unless the team explicitly overrides the Boot BOM with newer versions and validates that the overrides do not break the application.

Scott Frederick, Staff engineer on the Java-Spring team at HeroDevs, after years on the Spring team, put it plainly this month: “When Spring Boot versions go EOL, they stop getting dependency updates. But the dependencies don’t stop getting CVEs. If you’re on an EOL Spring Boot version you’d better be watching your dependencies and overriding Boot’s managed dependency versions with newer versions.”

That is the operational burden this article quantifies. Twenty-four upstream CVEs in a single month, distributed across five managed dependencies, every one of them reachable through the Boot BOM on at least one EOL Spring Boot line.
‍

What Was Patched in May 2026

The May 2026 NES Spring Boot release picks up 24 unique upstream CVEs across five managed dependencies in the Boot BOM:

‍

Two CVEs deserve separate attention because they change urgency. CVE-2026-40478 and CVE-2026-41901 form a patch-on-patch Thymeleaf chain. The first sandbox bypass was fixed in Thymeleaf 3.1.4. A second bypass was then found that required 3.1.5. Both are CVSS 9.0+ Server-Side Template Injection vulnerabilities that permit remote code execution when user-controlled input reaches a Thymeleaf expression context.

‍

What This Looks Like by Spring Boot Line

Same set of CVEs regrouped by which NES Spring Boot release each one lands in. Counts overlap because the same upstream Tomcat or Netty CVE affects every Boot line that pins that dependency.

‍

The column on the right is the point. Every one of these EOL Boot lines is consuming managed-dependency versions that froze sometime between 2022 and 2025. The May 2026 row shows what one month of upstream movement looks like across that frozen surface. The June 2026 row will look similar in shape, because Apache, Netty, Thymeleaf, Jetty, and pgjdbc keep shipping.

‍

The Self-Managed Override Burden

For a team running an EOL Boot line and choosing to maintain dependency hygiene in-house, every CVE above is a discrete unit of engineering work.

Each one requires:

• Monitoring the upstream project’s security advisories for the affected component.
• Determining whether the version Boot pins is in the affected range.
• Identifying every application in the portfolio that consumes the affected component through the Boot BOM.
• Add a managed dependency override to each affected build file.
• Validating that the override does not break Boot’s dependency resolution.
• Regression testing each application against the new dependency version.
• Resolving compatibility issues that surface in test. Binary-incompatible behavior between the version Boot expects and the patched version is the most common.
• Deploying through the existing release process.
• Producing release notes, advisory analysis, and evidence the security and audit teams can reference.

Multiply that workflow by 24 CVEs in one month, across the application count in the portfolio, and the pattern becomes clear. The Boot BOM is doing one job today, which is pinning the dependency graph at known-good versions. After EOL, the job changes. It pins the dependency graph at increasingly stale versions, and someone on the team becomes responsible for the upstream-monitoring layer that the Boot project previously absorbed.

‍

How NES Handles This Work

The HeroDevs Spring engineering team runs the same workflow on the NES side. The May 2026 release picks up the seven Tomcat CVEs at 9.0.118 and 10.1.55, the eleven Netty CVEs at 4.1.133.Final, the three Thymeleaf CVEs at 3.1.5, the Jetty CVE at 12.0.34, and the pgjdbc CVE at 42.7.11, then publishes those bumps as patched Boot artifacts at the original Maven and Gradle coordinates the customer already references.

The work the customer team does not have to do:

• The upstream-advisory monitoring layer.
• Version-range matching against pinned BOM coordinates.
• Override authoring and BOM compatibility validation.
• Regression testing on the affected application surface.
• Evidence artifacts (release notes, advisory analysis, version manifests, support attestations) for audit workflows.

NES does not eliminate code changes in every environment. Custom application code that depends on internal APIs of a patched dependency may still need adjustment. What NES does is collapse the dependency-bump workflow into the same release cadence the customer already runs against Spring itself, with documentation suitable for security and compliance evidence.

‍

Taking Action

For teams currently running Spring Boot 2.5, 2.7, 3.2, 3.3, or 3.4, three practical steps:

1. Inventory the applications running each Boot line. Most enterprises do not have a clean mapping of which Boot version each application consumes. The output of this step is the basis for every decision that follows. The HeroDevs EOL Discovery Scanner produces this inventory automatically.
2. Identify the managed dependencies your applications actually use. The exposure surface is set by what is in use, not just what is pinned. Tomcat as the embedded container, Netty in reactive workloads, Thymeleaf for view rendering, Jetty as an alternative container, and pgjdbc for PostgreSQL access are the highest-volume cases this month.
3. Decide whether to self-manage overrides or use NES. If your team has the engineering capacity to monitor, override, test, and document upstream dependency releases at the cadence the upstream projects ship, the self-managed path is real. If that capacity is going to product work, NES for Spring is the supported alternative on the same Maven and Gradle workflow you already use.

‍

Related Reading

• Spring Boot 3.5 Reaches EOL on June 30, 2026: Why Most Spring Teams Are Running Out of Support, HeroDevs. The foundational EOL piece.
• The Hidden Risk in Spring Boot 2.7: Managed Dependencies Still Matter, HeroDevs. Prior coverage of the managed-dependency drift problem.
• Bob McNees, Spring CVEs Surge in 2026: 37 Vulnerabilities in Two Months, HeroDevs, April 27, 2026.
• Steve Poole, Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem, foojay, April 19, 2026.

‍

Appendix: Full CVE List with Advisory Links

Every CVE in the May 2026 release, organized by upstream dependency, with severity and one-sentence description. Useful for SCA tool reconciliation, evidence collection, and search-intent landings.

‍

Apache Tomcat (fixed in 9.0.118 and 10.1.55)

• CVE-2026-43512 (Moderate): When multiple security constraints defined an HTTP method constraint for the same URL pattern, only the first method constraint was applied, allowing authorization bypass.
• CVE-2026-42498 (Moderate): The DIGEST authenticator accepted any user unknown to the Realm as authenticated if they presented the literal password “null”.
• CVE-2026-43515 (Low): The AJP shared secret was compared in non-constant time, allowing a local-network attacker to use timing to recover the secret.
• CVE-2026-43514 (Low): LockOutRealm treated usernames as case-sensitive, weakening brute-force lockout when the underlying Realm was case-insensitive.
• CVE-2026-43513 (Low): A WebSocket client that followed a redirect after authentication forwarded the original Authorization header to the redirect target.
• CVE-2026-41293 (Low): HTTP/2 request headers were not validated against spec, so applications relying on Servlet API for compliant headers could be tricked.
• CVE-2026-41284 (Low): No size limit was enforced on the request body of unauthenticated WebDAV LOCK or PROPFIND requests, enabling memory-exhaustion DoS.

Netty (fixed in 4.1.133.Final)

• CVE-2026-42586 (Moderate, CVSS 6.8): RedisEncoder wrote user-controlled string content without sanitizing CRLF, enabling Redis protocol command injection.
• CVE-2026-42578 (Low): HttpProxyHandler opted out of CRLF validation, allowing header injection into proxy CONNECT requests.
• CVE-2026-42579 (High, CVSS 7.5): DNS codec did not enforce RFC 1035 domain-name constraints on encode or decode, enabling cache poisoning.
• CVE-2026-42582 (High): QpackDecoder allocated for an HTTP/3 literal before verifying the bytes were present, allowing ~1 GiB allocations from a small malicious header.
• CVE-2026-42583 (High): Lz4FrameDecoder allocated up to 32 MB based on attacker-controlled decompressedLength, enabling memory-exhaustion DoS.
• CVE-2026-42581 (Moderate, CVSS 5.8): HttpObjectDecoder stripped a conflicting Content-Length only on HTTP/1.1, so HTTP/1.0 messages with both Transfer-Encoding: chunked and Content-Length enabled request smuggling.
• CVE-2026-42587 (High): HttpContentDecompressor enforced maxAllocation for gzip and deflate but ignored it for br, zstd, and snappy, enabling decompression-bomb DoS.
• CVE-2026-42585 (Medium): Netty incorrectly treated Transfer-Encoding: chunked, identity as chunked, enabling request smuggling.
• CVE-2026-42584 (High, CVSS 7.3): HttpClientCodec mis-paired queued requests with responses when 1xx interim responses and HEAD were pipelined.
• CVE-2026-42580 (Medium): HttpObjectDecoder’s chunk-size parser silently overflowed int, enabling request smuggling.
• CVE-2026-41417 (Medium, CVSS 5.3): DefaultHttpRequest.setUri() did not re-apply CRLF and whitespace validation, allowing start-line injection.
• CVE-2026-44248 (Medium): MqttDecoder parsed MQTT 5 Properties before applying maxBytesInMessage, exhausting CPU and memory on oversized Properties.

Thymeleaf (fixed in 3.1.4 and 3.1.5)

• CVE-2026-40478 (Critical, CVSS 9.1): A tab character between “new” and a class name combined with a java.* blocklist allowed sandbox bypass, instantiating arbitrary Spring classes.
• CVE-2026-40477 (Critical, CVSS 9.1): The expression sandbox failed to restrict accessible object scope, enabling SSTI.
• CVE-2026-41901 (Critical, CVSS 9.0): Even after the 3.1.4 fix, certain expression structures using internal Thymeleaf utility classes bypassed the sandbox, allowing SSTI.

Eclipse Jetty (fixed in 12.0.34)

• CVE-2026-5795 (High, CVSS 7.4): JASPIAuthenticator early-return code paths left ThreadLocal authentication state uncleared; Jetty’s thread reuse model leaked authenticated context to subsequent unauthenticated requests.

PostgreSQL JDBC (fixed in 42.7.11)

• CVE-2026-42198 (High, CVSS 7.5): Malicious or compromised PostgreSQL server can request arbitrarily large PBKDF2 iteration count during SCRAM-SHA-256 authentication, pinning client CPU. Fixed by introducing scramMaxIterations property defaulting to 100,000.

‍