chore(security): pin tomcat.version=10.1.55 to close 7 new CVEs (v0.1.25.19)#161
Merged
Conversation
Trivy's container scan picked up a new wave of CVEs against org.apache.tomcat.embed:tomcat-embed-core 10.1.54 between the last green main run (2026-05-11) and today: CRITICAL: CVE-2026-43512, CVE-2026-43515, CVE-2026-41293 HIGH: CVE-2026-43513, CVE-2026-42498, CVE-2026-41284 LOW: CVE-2026-43514 All seven scoped to tomcat-embed-core; all seven fixed in 10.1.55 (and 11.0.22 on the 11.x line). The artifact ships transitively via spring-boot-starter-web; Spring Boot 3.5.14's BOM currently manages 10.1.54. Mirrors the v0.1.25.16 pattern: explicit <tomcat.version>10.1.55</tomcat.version> property override on cycles-protocol-service/pom.xml. The v0.1.25.16 override (10.1.54) was dropped in v0.1.25.18 once SB 3.5.14's BOM caught up; this re-adds the same shape one patch higher. Removable again once Spring Boot ships a release with 10.1.55+ as its managed version. commons-lang3.version=3.18.0 override retained (CVE-2025-48924 still unfixed in SB 3.5.14's managed 3.17.0). No production code, no test code, no API or Lua-script changes — pom property change plus CHANGELOG.md and AUDIT.md entries. All 537 protocol-service tests pass (374 data + 163 api). Wire format unchanged from v0.1.25.18. Unblocks PR #160 (and any other branched work) — Trivy was failing the container-scan check on every PR build against main.
amavashev
added a commit
that referenced
this pull request
May 21, 2026
Two real bugs found during the post-push code-review pass against PR #160: 1. FilterHasher.hash unconditionally appended `|fr=...|to=...` to the canonical string, even when both bounds were null. This changed the SHA-256 hash for every pre-window cursor, including any v0.1.25.18 sorted-path cursor mid-pagination across the deployment boundary — the server would reject those cursors with 400 INVALID_REQUEST despite the client never sending the new params. That falsified the PR's stated "byte-for-byte" back-compat claim for the sorted path. Fix: gate the fr=/to= emission behind `fromMs != null || toMs != null`. When both bounds are null the canonical form reverts byte-exactly to the v0.1.25.12 8-field shape, so any pre-window cursor continues to resolve. When either bound is supplied, the new fields render in the canonical string as before, so cursors still invalidate on window change. Adds an explicit regression test `preservesPreWindowHashWhenBothBoundsNull` that locks the truncated 8-byte SHA-256 to its v0.1.25.18 golden value (2f397ea0e8fb53b7). 2. Three new ReservationControllerTest cases (shouldPropagateFromOnly / shouldPropagateToOnly / shouldAcceptEqualBounds) hard-coded 1779710400000L as the epoch-ms for "2026-05-21T12:00:00Z", but the correct value is 1779364800000L (the literal was off by 4 days — it's actually 2026-05-25T12:00:00Z). Mockito's eq(...) never matched the controller's computed value, the stub silently returned null, ResponseEntity.ok(null) still produced HTTP 200, and the tests passed vacuously without asserting anything about epoch-ms propagation. Fix: drop the literal entirely. Derive the expected ms from the same parser the controller uses (java.time.Instant.parse(...).toEpochMilli()). Each test also gains a verify(repository).listReservations(... eq(...) ...) assertion so a future Mockito miss raises a wanted-but-not-invoked failure instead of slipping through as a vacuous 200. No production behavior change beyond restoring the back-compat invariant for v0.1.25.18 sorted-path cursors. All 538 protocol-service tests pass (375 data + 163 api). JaCoCo 95% bundle gate met. Also folds in the .19 → .20 revision bump from the rebase onto main post-#161 (Tomcat CVE hygiene), so the PR's cumulative version is now v0.1.25.20.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Trivy's container scan started failing CI on every PR build against
mainbetween 2026-05-11 (last green main run) and 2026-05-21. Root cause: the upstream Trivy DB picked up a new wave of CVEs againstorg.apache.tomcat.embed:tomcat-embed-core 10.1.54— the version Spring Boot 3.5.14's BOM currently manages.All seven are scoped to
tomcat-embed-coreand ship transitively viaspring-boot-starter-web.Fix
Re-add the
<tomcat.version>10.1.55</tomcat.version>property override oncycles-protocol-service/pom.xml. Spring Boot 3.5.14's BOM picks the property up and resolves Tomcat at 10.1.55 across all transitive dependencies.This mirrors the v0.1.25.16 pattern, which pinned
tomcat.version=10.1.54for the previous CVE wave. The override was dropped in v0.1.25.18 once Spring Boot 3.5.14's BOM caught up to 10.1.54. This re-adds the same shape, one patch higher. Removable again once Spring Boot ships a release whose BOM manages 10.1.55+.commons-lang3.version=3.18.0override is retained (CVE-2025-48924 still unfixed in SB 3.5.14's BOM-managed 3.17.0).Why a standalone PR
PR #160 (the
listReservationsfrom/tofeature) is currently blocked by the same Trivy failure, but mixing CVE-hygiene with feature work would split scope and complicate the v0.1.25.x patch history. Prior CVE waves (v0.1.25.16, v0.1.25.17, v0.1.25.18) each landed as their own PR; following that precedent here.After this merges, I'll rebase #160 onto main and bump its
revisionto0.1.25.20.Verification
tomcat-embed-core 10.1.55and skip the seven CVEs.Test plan