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

The Dependency-Management Problem for EOL Spring Boot

We covered the mechanics in May. Short version: Spring Boot pins specific versions of Tomcat, Netty, Logback, Jackson, the PostgreSQL JDBC driver, and dozens more through its spring-boot-dependencies BOM. On a maintained Boot line those pins advance. On an EOL Boot line they freeze. Upstream projects keep shipping CVEs, and none of that reaches the frozen BOM.

July is quieter than May (24 CVEs). Thirteen unique upstream CVEs, three of them High. But the pattern in where they land is the story worth calling out. Boot 3.3, 3.4, and 3.5 pin Logback 1.5 and pgjdbc 42.7, both still actively releasing and both covered by this month's fixes; 3.4 and 3.5 additionally pin a Jackson line (2.18 and 2.21) that receives the July Jackson fix. Boot 2.5 and 2.7 pin Logback 1.2, older Jackson, and older pgjdbc, none of which receive these fixes upstream at all. The universal ones (Netty, Tomcat) reach every EOL Boot version. The rest reach only the newer EOL lines, because those are the only ones whose pinned libraries are still receiving security work at all.

The frozen BOM on Boot 2.7 is not just frozen relative to its own dependencies. It is frozen against a dependency graph that is itself EOL in multiple places. Every month, the gap widens.

‍

What Was Patched in July 2026

The July 2026 NES Spring Boot release picks up 13 unique upstream CVEs across five managed dependencies. Three are rated High, one is Moderate, and the rest are Medium or Low. Zero Critical.

Three CVEs are worth calling out specifically because they change actual security posture rather than availability.

CVE-2026-54291 is a silent channel-binding authentication downgrade in pgjdbc. Applications setting channelBinding=require on their JDBC URL expect SCRAM-SHA-256-PLUS to be enforced end-to-end, giving them MITM protection on the database connection. The bug: when the PostgreSQL server presents a TLS certificate signed with Ed25519, Ed448, or a post-quantum algorithm, pgjdbc's bundled scram-client returns an empty binding hash instead of failing. The driver's ScramAuthenticator only checks that the server advertised a -PLUS mechanism, not that the negotiated exchange actually used channel binding. The connection completes on plain SCRAM-SHA-256, and the application has no way to know channel binding was silently dropped. Any attacker positioned to intercept the TLS session can trigger the downgrade with a crafted certificate. CVSS 8.2 High. Fixed in pgjdbc 42.7.12. The July NES release ships 42.7.13.

CVE-2026-13006 is an expression injection in Logback that permits arbitrary code execution through <if> elements evaluated by Janino. The existing denylist blocked the literal new operator. It did not block Unicode escape sequences that reconstruct new, and it did not cover class references like Runtime or org.springframework.*. Exploitation requires write access to the Logback configuration file or the ability to inject an environment variable pointing to a malicious config, plus Janino present on the classpath. That is a narrow attack surface, but the payoff is full ACE inside the JVM. CVSS 7.0 High. Earlier 1.5.x releases tried to close this off (the CVE is tracked as incomplete protection against CVE-2025-11226), but the denylist stayed bypassable through 1.5.36. Logback 1.5.37 is the definitive fix; the NES bump goes to 1.5.38, which also removes support for Janino-based conditional configuration entirely as long-term hardening.

CVE-2026-55956 is an authorization bypass in Apache Tomcat's default servlet. When a <security-constraint> was mapped to the default servlet path with a method or method-omission restriction, Tomcat matched the constraint against every request regardless of HTTP method. A rule intended to protect only writes was applied to reads (and vice versa), so per-method access policy was effectively ignored. Moderate. Affects Tomcat 9.0.0 through 9.0.118 and 10.1.0 through 10.1.55. Fixed in 9.0.119 and 10.1.56. This one lands on every EOL Boot version that embeds Tomcat, which is all of them.

The Netty STOMP DoS (CVE-2026-44891) is High-severity but availability-only. Worth patching, less urgent than the three above.

‍

What This Looks Like by Spring Boot Line

Same set of CVEs regrouped by which EOL Spring Boot version each one lands on. Fixes overlap because Netty and Tomcat sit under every Boot line.

Two things to notice.

First, the Netty and Tomcat rows apply everywhere. A team running any of these EOL Boot versions is exposed to the same authorization bypass in the default servlet and the same STOMP DoS. That is the recurring pattern this series has been documenting since May: every month, a batch of upstream fixes hits every embedded container and every reactive networking stack in the Boot family, regardless of which Boot version pinned them.

Second, the newer EOL Boot versions accumulate more fixes because they track newer library lines. That is not an artifact of the July release. It is the structural situation: Boot 2.5 and 2.7 pin dependency versions that upstream projects consider retired. When Logback 1.5.37 shipped its ACE fix, there was no equivalent 1.2 backport, because Logback 1.2 stopped receiving security fixes years ago. Same for older Jackson and older pgjdbc. Boot 3.5 sits at the other end: it reached EOL on June 30, 2026, but because it still pins current library lines (Logback 1.5, pgjdbc 42.7, Jackson 2.21), it inherits the full set of July fixes, the same 13 as Boot 3.4.

‍

The Self-Managed Override Burden

For a team on an EOL Boot version maintaining dependency hygiene in-house, each of the July CVEs is a discrete unit of engineering work: monitor the upstream advisory, determine whether the pinned version is in the affected range, identify every application in the portfolio that consumes the component through the Boot BOM, add a managed-dependency override to each build file, validate that the override does not break Boot's dependency resolution, regression-test each application, resolve compatibility issues (binary-incompatible behavior between the version Boot expects and the patched version is the most common), deploy through the release process, and produce release notes and evidence artifacts the security and audit teams can reference.

Multiply that workflow by 13 CVEs in one month across the application count in the portfolio, and the pattern becomes clear. This month's work is lighter than May's. Next month's may be heavier. The upstream-monitoring layer is what the team now owns, and it does not go away.

The other trap is the two hardening bumps that ship no CVE ID. MariaDB Connector/J 3.4.3 and R2DBC MariaDB 1.2.3 both contain security-relevant hardening that no CVE was assigned to. A team relying purely on scanner output to drive dependency bumps will not see either of these. They will show up as "no known CVEs" in the SCA report and get deprioritized. The upstream release notes are the source of truth. Scanner output is downstream of that, and lossy.

‍

How NES Handles This Work

The HeroDevs Spring engineering team ran the same workflow on the NES side. The July 2026 release picks up:

• Netty 4.1.136.Final on every supported EOL Boot version
• Tomcat 9.0.120 on Boot 2.5 and 2.7
• Tomcat 10.1.57 on Boot 3.2, 3.3, 3.4, and 3.5
• Logback 1.5.38 on Boot 3.3, 3.4, and 3.5
• pgjdbc 42.7.13 on Boot 3.3, 3.4, and 3.5
• Jackson 2.18.9 on Boot 3.4 and Jackson 2.21.5 on Boot 3.5
• MariaDB Connector/J 3.4.3 hardening on Boot 3.4
• R2DBC MariaDB 1.2.3 hardening on Boot 3.3 and 3.4

Those bumps ship as patched Boot artifacts at the same Maven and Gradle coordinates the customer already references. The upstream-advisory monitoring layer, the version-range matching against pinned BOM coordinates, the override authoring and BOM compatibility validation, the regression testing on the affected application surface, and the evidence artifacts for audit workflows are the parts the customer team does not have to do.

NES does not eliminate every code change in every environment. Custom application code that depends on internal APIs of a patched dependency may still need adjustment. The Logback 1.5.38 removal of Janino-based conditional configuration is an example: any application whose logback config used <if> elements will need to move to the <condition> element or the online migration service Logback provides. 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, 3.4, or 3.5, three practical steps:

1. Inventory the applications running each Boot line. The HeroDevs EOL Discovery Scanner produces this inventory automatically.
2. Prioritize by Boot version, not by CVE list. If your applications run on Boot 3.3, 3.4, or 3.5, the Logback and pgjdbc Highs are the ones to move on first. If they run on Boot 2.5 or 2.7, the Tomcat authorization bypass is universally exposed and needs attention regardless. Do not let the smaller July CVE count relax anyone on the older Boot versions; the deeper problem is that those versions are missing fixes because the underlying libraries themselves are EOL.
3. Decide whether to self-manage overrides or use NES. If your team has engineering capacity to monitor, override, test, and document upstream dependency releases at the cadence 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 Managed Dependencies Still Get CVEs After EOL: May 2026 Patch Round-Up
• Spring Boot 3.5 Reaches EOL on June 30, 2026: Why Most Spring Teams Are Running Out of Support
• The Hidden Risk in Spring Boot 2.7: Managed Dependencies Still Matter
• Bob McNees, Spring CVEs Surge in 2026: 37 Vulnerabilities in Two Months
• Steve Poole, Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem

‍

Appendix: Full CVE List with Advisory Links

Every CVE in the July 2026 release, organized by upstream dependency. Useful for SCA reconciliation, evidence collection, and search-intent landings.

Netty (fixed in 4.1.136.Final)

• CVE-2026-44891 (High): The StompSubframeDecoder did not bound the number or cumulative size of headers per frame, so a malformed client could force unbounded frame accumulation and drive the server to an OutOfMemoryError, a memory-exhaustion denial of service on Netty servers exposing STOMP endpoints.

Apache Tomcat (fixed in 9.0.119, 9.0.120, 10.1.56, and 10.1.57)

• CVE-2026-55956 (Moderate): Security constraints mapped to the default servlet ignored any HTTP method or method-omission restriction, applying the constraint uniformly to all methods and bypassing per-method authorization policy. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-55955 (Low): The clustering EncryptInterceptor was not protected against replay attacks despite documentation stating otherwise. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-55276 (Low): The effective web.xml logged at startup was incomplete. Special roles and empty authorization constraints were omitted, so the logged configuration did not match the constraints Tomcat actually enforced. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-53434 (Low): The FFM/OpenSSL connector did not treat CRL validation failures as fatal, allowing revoked client certificates to be accepted. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-53404 (Low): RewriteValve mishandled OR ("ornext") condition chains. If the first condition in an OR chain matched, subsequent non-OR conditions were skipped, so a rewrite rule could apply more broadly than the configuration intended. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-50229 (Low): A reflected XSS vulnerability in the bundled "number guess" example application allowed crafted input to reflect script content. Not on the default deployment path but a hardening target for teams that ship the example webapps. Fixed in 9.0.119 and 10.1.56.
• CVE-2026-59083 (Low): RewriteValve mishandled URL (hex) decoding on some rule configurations, allowing a security-constraint bypass. Fixed in 9.0.120 and 10.1.57.
• CVE-2026-59084 (Low): The requirements to securely configure the clustering EncryptInterceptor were not clearly documented, so operators could deploy it in an insecure configuration while believing it was protected. Fixed in 9.0.120 and 10.1.57.

Logback (fixed in 1.5.37, hardened further in 1.5.38)

• CVE-2026-13006 (High, CVSS 7.0): Expression injection in Janino-evaluated <if> conditions permitted arbitrary code execution circumventing the existing denylist, either through references the denylist did not cover (Runtime, org.springframework.* classes) or through Unicode escape sequences reconstructing the blocked new operator. Requires write access to the Logback configuration file or environment-variable control, plus Janino on the classpath. Tracked as incomplete protection against CVE-2025-11226; still bypassable through 1.5.36, definitively fixed in 1.5.37. 1.5.38 removes support for Janino-based conditional expressions entirely.

PostgreSQL JDBC (fixed in 42.7.12)

• CVE-2026-54291 (High, CVSS 8.2): Silent channel-binding authentication downgrade. Under channelBinding=require, pgjdbc failed to enforce that the negotiated SCRAM mechanism actually used channel binding, allowing a TLS man-in-the-middle attacker to downgrade SCRAM-SHA-256-PLUS to plain SCRAM-SHA-256 when the server certificate was signed with Ed25519, Ed448, or a post-quantum algorithm. Only affects connections that explicitly set channelBinding=require. Fixed in 42.7.12.

Jackson (fixed in 2.18.9 and 2.21.5)

• CVE-2026-54515 (Medium): Case-insensitive deserialization can bypass per-property @JsonIgnoreProperties exclusions. In BeanDeserializerBase.createContextual(), the per-property ignore set is applied such that a case-insensitive property match can defeat it, so fields the configuration intended to drop can still be bound from input. Affected from 2.8.0; fixed in 2.18.9 (and 2.21.5, 3.1.4).
• CVE-2026-59889 (Medium, CVSS 6.5): @JsonView filtering is bypassed for @JsonUnwrapped container properties during deserialization. UnwrappedPropertyHandler.processUnwrapped() replays the buffered JSON for the unwrapped property without reapplying the active view, so fields a view was meant to exclude can still be written. Affected from 2.18.0; fixed in 2.18.9 (and 2.21.5, 2.22.1, 3.1.5, 3.2.1).

MariaDB Connector/J 3.4.3 and R2DBC MariaDB 1.2.3

Genuine security hardening with no CVE assigned. Will not appear in SCA scanner output. Included in the NES bumps for completeness because the upstream release notes flag them as security-relevant.