deps: bump Apache Tomcat 9.0.113 → 9.0.118 (resolves 6 published CVEs)

[mbiuki]

Summary

The bundled Apache Tomcat version pinned at parent/pom.xml:70 (<tomcat.version>9.0.113</tomcat.version>) is affected by 6 published Apache Tomcat CVEs. Apache has shipped fixes in versions through 9.0.117; 9.0.118 is the latest 9.0.x patch (released 2026-05-10). A single-line property bump resolves all 6.

Reported through Freshdesk ticket #37395 (security audit by an enterprise customer).

Affected CVEs (apply to 9.0.113)

CVE	Severity (Apache)	Affected range	Fixed in
CVE-2026-29146	Important	9.0.13 – 9.0.115	9.0.116
CVE-2026-34500	Moderate	9.0.92 – 9.0.116	9.0.117
CVE-2026-34487	Low	9.0.13 – 9.0.116	9.0.117
CVE-2026-34483	Low	9.0.40 – 9.0.116	9.0.117
CVE-2026-25854	Low	9.0.0.M23 – 9.0.115	9.0.116
CVE-2026-24880	Low	9.0.0.M1 – 9.0.115	9.0.116

Source: https://tomcat.apache.org/security-9.html

Not affected (false positive in original report)

CVE-2025-66614 (Moderate, virtual-host client-certificate verification bypass) — Apache lists this as fixed in 9.0.113, so our bundled version already contains the fix. The original audit report flagged it but it does not apply here.

Required change

- <tomcat.version>9.0.113</tomcat.version>
+ <tomcat.version>9.0.118</tomcat.version>

Single-property bump in parent/pom.xml:70. The property propagates to:

• bom/application/pom.xml — BOM declarations
• dotCMS/pom.xml — direct dependency, docker base image (tomcat:${tomcat.version}-jdk11), distribution folder (dotserver/tomcat-${tomcat.version}), and remote tomcat zip URL
• dotcms-integration/pom.xml
• dotCMS/src/main/docker/original/docker-descriptor.xml

Bumping to 9.0.117 is sufficient to clear all 6 listed CVEs; 9.0.118 is recommended for currency. Tomcat 9.0.x is API-stable across patch versions, so no source-code changes are required.

Verification already done

• Each reported CVE was cross-referenced against the Apache Tomcat 9 security advisory page — 6 valid, 1 already fixed in our current pin (CVE-2025-66614).
• mvn dependency:tree confirms tomcat-catalina:9.0.113 is the resolved artifact in dotCMS/maven_dep_tree.txt (15 tomcat refs total in that module, 9 in dotcms-integration).

Action items

• Bump tomcat.version to 9.0.118 in parent/pom.xml
• Run full integration test suite — Tomcat patch versions are API-stable but worth verifying nothing in our embedded servlet/jasper/jdbc usage trips on the new build
• Confirm dotcms/dotcms docker base pulls tomcat:9.0.118-jdk11 cleanly
• Run Semgrep Supply Chain in CI and confirm CVE finding count for org.apache.tomcat:* drops to zero
• Backport to LTS branches:
  • 24.12.27_lts (target: next LTS revision, currently at _v20)
  • 25.07.10_lts (target: next LTS revision, currently at _v9)
• Cut a patch release on the evergreen line containing the bump
• Coordinate with support to notify the affected customer once the patched release is available

Severity / SLA

• CVE-2026-29146 is the only "Important"-rated item. Real-world exploitability is conditional: it affects clusters using Tomcat's EncryptInterceptor, which is not enabled by default in dotCMS. Still worth fixing promptly.
• The remaining 5 are Low/Moderate per Apache's rating.
• By our internal vulnerability-management SLA, this is High priority (one Important CVE + active enterprise customer pressure). Patch landed in main within 7 days, release cut within 14 days, LTS backports same window.

Notes

This is a routine SCA-driven dependency bump. The change is mechanical; the verification work is what takes time. Once the bump is in, the BOM and docker manifests rebuild automatically via the existing build pipeline.

[mbiuki]

Second customer reporting same finding — urgency signal

A second enterprise customer has reported the same set of Tomcat CVEs via Freshdesk ticket #37386 (independently of ticket #37395 that prompted this issue). Their specifics:

• On the 25.07.10 LTS line specifically (not evergreen).
• Their security/deployment process blocks on these vulnerabilities — explicit business impact.
• They confirmed the proposed fix is a Tomcat patch-version bump and pointed to PR security: upgrade Apache Tomcat from 9.0.108 to 9.0.113 (CVE-2025-66614) #34955 (the previous 9.0.108 → 9.0.113 bump) as a template.

This raises the urgency from "one customer asking" to "multiple enterprise customers blocked." Recommend treating the 25.07.10 LTS backport as the first target (rather than 24.12.27 LTS) given the explicit customer request, and prioritizing the LTS backport release alongside the main bump.

No change to the technical fix or scope from the original action items above — just a calibration that two production customers are now waiting on this rather than one.

[github-actions]

PRs linked to this issue

• security: upgrade Apache Tomcat from 9.0.113 to 9.0.118 by @mbiuki

[mbiuki]

All three Tomcat-bump PRs are open

Target	PR	Branch	Base
main (evergreen)	#35796	security/upgrade-tomcat-9.0.118	main
25.07.10 LTS	#35797	security/upgrade-tomcat-9.0.118-25.07.10_lts	release-25.07.10_lts
24.12.27 LTS	#35798	security/upgrade-tomcat-9.0.118-24.12.27_lts	release-24.12.27_lts

All three carry the same one-line change (tomcat.version 9.0.113 → 9.0.118 in parent/pom.xml) and reference this issue. The 25.07.10 LTS PR is the prioritized backport — that's the line Freshdesk ticket #37386 is on.

Side observation worth tracking separately

The LTS branches' core-web/.husky/pre-commit hook has a bug that surfaces specifically in git worktree checkouts: it cds into core-web/ mid-execution and then runs git restore on a non-core-web absolute path, which fails because git infers GIT_WORK_TREE=core-web from cwd combined with the worktree's absolute GIT_DIR env var. The failure is:

fatal: .../parent/pom.xml: '.../parent/pom.xml' is outside repository at '.../core-web'
husky - pre-commit hook exited with code 128 (error)

Workaround used to land #35797 and #35798: fresh shallow clones (not worktrees), where git uses a relative .git reference and the hook's cd is benign. Main's hook is different and isn't affected.

Filing a separate issue + PR to fix the LTS hook so future LTS PRs don't trip over this in worktree-based dev workflows.

[sfreudenthaler]

in the merge queue after passing manual targeted QA in cloud sandbox. (see attached PR)