Skip to content

Commit 6de545c

Browse files
Linesmerrillclaude
Linesmerrill
and
claude
authored
Dependency vulnerability sweep + Spring Boot 3.5.16: tomcat, netty, log4j BOM fix, jackson, postgresql, lz4, commons-compress (#485)
* Pin tomcat-embed 10.1.57 and netty 4.1.136.Final for active CVEs Spring Boot 3.5.15 (and 3.5.16) still manage tomcat 10.1.55 and netty 4.1.135.Final, both of which have unfixed CVEs, so re-add temporary dependencyManagement overrides. Tomcat 10.1.55 -> 10.1.57 covers CVE-2026-55956 (Moderate, default servlet security constraints ignored the configured method) plus CVE-2026-59084, CVE-2026-59083, CVE-2026-55955, CVE-2026-55276, CVE-2026-53434, CVE-2026-53404 and CVE-2026-50229 (Low). All three embed artifacts (core, el, websocket) are pinned together so the Tomcat version stays internally consistent rather than mixing 10.1.57 core with 10.1.55 el. Netty 4.1.135.Final -> 4.1.136.Final covers the 20 CVEs in that release across netty-codec-http/http2/stomp/haproxy/xml/redis/dns/compression and netty-handler-ssl-ocsp (memory exhaustion, CR/LF injection, zip bomb, OCSP certificate validation). Kept on the 4.1.x line that Boot and reactor-netty are tested against rather than moving to 4.2.x. The existing commons-lang3 / commons-configuration2 / commons-fileupload overrides were re-audited against the Boot BOM and all three are still required (the BOM manages commons-lang3 at 3.17.0 and does not manage the other two). Verified with mvn dependency:tree that all tomcat-embed artifacts resolve to 10.1.57 and all io.netty artifacts to 4.1.136.Final; full reactor clean install passes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Fix ineffective log4j BOM import and patch 6 more CVE-affected deps Full-tree OSV scan of all 374 resolved artifact/version pairs turned up 9 vulnerable pairs beyond the tomcat/netty ones. This fixes 6 of them. log4j was the significant find. The log4j-bom import sat BELOW the spring-boot-dependencies import, and Maven resolves dependencyManagement first-declaration-wins, so Boot's log4j2.version (2.24.3) silently won and ${log4j.version} had no effect whatsoever - the repo has been building against 2.24.3 while the property claimed 2.25.4. Moving the import above spring-boot-dependencies makes the property live again; the version is also bumped 2.25.4 -> 2.25.5. This clears CVE-2026-34480, CVE-2026-34478, CVE-2026-34477, CVE-2025-68161 (log4j-core) and CVE-2026-34479 (log4j-1.2-api). A comment now records the ordering constraint. New temporary vulnerability overrides: - jackson-bom 2.21.4 -> 2.21.5 for CVE-2026-59889, CVE-2026-54515 and GHSA-mhm7-754m-9p8w (@JSONVIEW / @JsonIgnoreProperties deserialization bypasses). Imported above spring-boot-dependencies for the same first-wins reason. - postgresql 42.7.11 -> 42.7.13 for CVE-2026-54291 (High), a silent channel-binding authentication downgrade. - lz4-java 1.10.1 -> 1.11.1 for CVE-2026-59949; pulled in by kafka-clients 3.9.2 via spring-kafka, which Boot manages but lz4 is not. - commons-compress -> 1.28.0 for CVE-2024-26308 and CVE-2024-25710. Only the test-scoped testcontainers path was on the vulnerable 1.24.0 while spring-boot-loader-tools already pulled 1.27.1, so this also removes a version split. Spring Boot 3.5.16 was evaluated and deliberately not taken: it manages identical versions of log4j2, jackson, postgresql, kafka and hibernate to 3.5.15, so it would not have fixed any of the above. Two findings are deliberately NOT fixed here because they need migrations rather than version pins, and are called out in the PR for separate work: hibernate-core 5.6.15.Final (CVE-2026-0603, High) dragged in by the Hibernate 5-only hibernate-ehcache / hibernate-entitymanager artifacts, and querydsl 5.1.0 (CVE-2024-49203, High) whose upstream is abandoned in favour of the io.github.openfeign.querydsl fork. Re-scan after the change: 9 vulnerable pairs down to 3 (the 2 above plus querydsl-apt). Full reactor clean install passes, 1700 tests green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Bump Spring Boot to 3.5.16 to stay current on the patch line Policy bump rather than a targeted CVE fix: staying on the newest Boot patch means we are not waiting on an upgrade when the next advisory lands. 3.5.15 -> 3.5.16 moves spring-amqp 3.2.11 -> 3.2.12, spring-data-bom 2025.0.12 -> 2025.0.13 and spring-integration 6.5.9 -> 6.5.10. Those are the only three managed versions that changed; a full property diff of the two BOMs confirms everything else is identical, including spring-framework (6.2.19 in both). Spring Cloud stays at 2025.0.3 - it is already the newest patch in the 2025.0.x train that pairs with Boot 3.5.x, and crossing to 2025.1.x would mean a different Boot line. Spring Framework / spring-core is not a separate knob in this repo: the four modules that declare spring-core do so without a version, so it moves with the Boot BOM automatically. None of the temporary vulnerability overrides become redundant - 3.5.16 still manages log4j2 2.24.3, jackson 2.21.4, postgresql 42.7.11, tomcat 10.1.55, netty 4.1.135.Final and commons-lang3 3.17.0, so every pin in the block is still doing work. OSV re-scan of the resolved tree is unchanged at 3 vulnerable pairs, full reactor clean install passes with 1700 tests green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
1 parent 610046e commit 6de545c

1 file changed

Lines changed: 95 additions & 9 deletions

File tree

‎pom.xml‎

Lines changed: 95 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@
6666
<kotlin.version>2.3.20</kotlin.version>
6767

6868
<!--Spring Versions-->
69-
<spring-boot-framework.version>3.5.15</spring-boot-framework.version>
69+
<spring-boot-framework.version>3.5.16</spring-boot-framework.version>
7070
<spring-cloud-framework.version>2025.0.3</spring-cloud-framework.version>
7171

7272
<!--Springdoc-->
@@ -86,7 +86,7 @@
8686
<junit.version>5.14.4</junit.version>
8787

8888
<!--Logging-->
89-
<log4j.version>2.25.4</log4j.version>
89+
<log4j.version>2.25.5</log4j.version>
9090
<slf4j.version>2.0.17</slf4j.version>
9191

9292
<!--Db2-->
@@ -625,6 +625,42 @@
625625

626626
<!--External Dependencies-->
627627
<!--Temporary For Vulnerability Fix-->
628+
<!-- 20 CVEs across netty-codec-http/http2/stomp/haproxy/xml/redis/dns/compression and
629+
netty-handler-ssl-ocsp (memory exhaustion, CR/LF injection, zip bomb, OCSP cert
630+
validation) - Fixed in 4.1.136.Final, added 2026-07-27.
631+
Spring Boot 3.5.15/3.5.16 still manage netty 4.1.135.Final. Stay on the 4.1.x line
632+
that Boot/reactor-netty are tested against - do NOT move to 4.2.x here.
633+
TODO: Remove this override when spring-boot-dependencies includes netty >= 4.1.136.Final
634+
Check: mvn dependency:tree | grep io.netty -->
635+
<dependency>
636+
<groupId>io.netty</groupId>
637+
<artifactId>netty-bom</artifactId>
638+
<version>4.1.136.Final</version>
639+
<type>pom</type>
640+
<scope>import</scope>
641+
</dependency>
642+
<!-- CVE-2026-55956 (Moderate) default servlet security constraints ignored method, plus
643+
CVE-2026-59084, CVE-2026-59083, CVE-2026-55955, CVE-2026-55276, CVE-2026-53434,
644+
CVE-2026-53404, CVE-2026-50229 (Low) - Fixed in 10.1.57, added 2026-07-27.
645+
Spring Boot 3.5.15/3.5.16 still manage tomcat 10.1.55. All three embed artifacts are
646+
pinned together so the Tomcat version stays internally consistent.
647+
TODO: Remove this override when spring-boot-dependencies includes tomcat >= 10.1.57
648+
Check: mvn dependency:tree | grep tomcat-embed -->
649+
<dependency>
650+
<groupId>org.apache.tomcat.embed</groupId>
651+
<artifactId>tomcat-embed-core</artifactId>
652+
<version>10.1.57</version>
653+
</dependency>
654+
<dependency>
655+
<groupId>org.apache.tomcat.embed</groupId>
656+
<artifactId>tomcat-embed-el</artifactId>
657+
<version>10.1.57</version>
658+
</dependency>
659+
<dependency>
660+
<groupId>org.apache.tomcat.embed</groupId>
661+
<artifactId>tomcat-embed-websocket</artifactId>
662+
<version>10.1.57</version>
663+
</dependency>
628664
<!-- CVE-2025-48924 (High/7.5) - Fixed in 3.18.0; pinned to 3.20.0, added 2025-07-11
629665
TODO: Remove this override when spring-boot-dependencies includes commons-lang3 >= 3.18.0
630666
Check: mvn dependency:tree | grep commons-lang3 -->
@@ -649,6 +685,50 @@
649685
<artifactId>commons-fileupload</artifactId>
650686
<version>1.6.0</version>
651687
</dependency>
688+
<!-- CVE-2026-59889, CVE-2026-54515, GHSA-mhm7-754m-9p8w (Moderate) - @JsonView and
689+
@JsonIgnoreProperties bypasses on deserialization - Fixed in 2.21.5, added 2026-07-27.
690+
Spring Boot 3.5.15/3.5.16 manage jackson-bom 2.21.4. Stays on the 2.21.x line.
691+
NOTE: this import must remain ABOVE the spring-boot-dependencies import or it is a no-op.
692+
TODO: Remove this override when spring-boot-dependencies includes jackson-bom >= 2.21.5
693+
Check: mvn dependency:tree | grep jackson-databind -->
694+
<dependency>
695+
<groupId>com.fasterxml.jackson</groupId>
696+
<artifactId>jackson-bom</artifactId>
697+
<version>2.21.5</version>
698+
<type>pom</type>
699+
<scope>import</scope>
700+
</dependency>
701+
<!-- CVE-2026-54291 (High) - silent channel-binding authentication downgrade - Fixed in
702+
42.7.12; pinned to 42.7.13, added 2026-07-27.
703+
Spring Boot 3.5.15/3.5.16 manage postgresql 42.7.11.
704+
TODO: Remove this override when spring-boot-dependencies includes postgresql >= 42.7.12
705+
Check: mvn dependency:tree | grep org.postgresql -->
706+
<dependency>
707+
<groupId>org.postgresql</groupId>
708+
<artifactId>postgresql</artifactId>
709+
<version>42.7.13</version>
710+
</dependency>
711+
<!-- CVE-2026-59949 (Moderate) - native XXHash can crash the JVM on invalid byte array
712+
ranges - Fixed in 1.11.1, added 2026-07-27. Pulled in transitively by
713+
kafka-clients 3.9.2 via spring-kafka; Spring Boot manages kafka, not lz4.
714+
TODO: Remove this override when kafka-clients ships lz4-java >= 1.11.1
715+
Check: mvn dependency:tree | grep lz4 -->
716+
<dependency>
717+
<groupId>at.yawk.lz4</groupId>
718+
<artifactId>lz4-java</artifactId>
719+
<version>1.11.1</version>
720+
</dependency>
721+
<!-- CVE-2024-26308, CVE-2024-25710 (Moderate) - Fixed in 1.26.0; pinned to 1.28.0,
722+
added 2026-07-27. Only the test-scoped path was vulnerable: testcontainers 1.21.4
723+
pulls 1.24.0 while spring-boot-loader-tools already pulls 1.27.1, so this pin also
724+
removes that version split.
725+
TODO: Remove this override when testcontainers ships commons-compress >= 1.26.0
726+
Check: mvn dependency:tree | grep commons-compress -->
727+
<dependency>
728+
<groupId>org.apache.commons</groupId>
729+
<artifactId>commons-compress</artifactId>
730+
<version>1.28.0</version>
731+
</dependency>
652732
<!--./END Temporary For Vulnerability Fix-->
653733
<dependency>
654734
<groupId>com.github.stefanbirkner</groupId>
@@ -663,6 +743,19 @@
663743
<scope>provided</scope>
664744
</dependency>
665745

746+
<!--Logging BOM-->
747+
<!-- MUST stay ABOVE the spring-boot-dependencies import below. Maven resolves
748+
dependencyManagement first-declaration-wins, so if spring-boot-dependencies is
749+
imported first its log4j2.version (2.24.3) silently wins and ${log4j.version} has
750+
no effect at all. Verify with: mvn dependency:tree | grep log4j-core -->
751+
<dependency>
752+
<groupId>org.apache.logging.log4j</groupId>
753+
<artifactId>log4j-bom</artifactId>
754+
<version>${log4j.version}</version>
755+
<type>pom</type>
756+
<scope>import</scope>
757+
</dependency>
758+
666759
<!--Spring Dependencies-->
667760
<dependency>
668761
<groupId>org.springframework.boot</groupId>
@@ -703,13 +796,6 @@
703796
</dependency>
704797

705798
<!--Logging-->
706-
<dependency>
707-
<groupId>org.apache.logging.log4j</groupId>
708-
<artifactId>log4j-bom</artifactId>
709-
<version>${log4j.version}</version>
710-
<type>pom</type>
711-
<scope>import</scope>
712-
</dependency>
713799
<dependency>
714800
<groupId>com.lmax</groupId>
715801
<artifactId>disruptor</artifactId>

0 commit comments

Comments
 (0)