security: upgrade Apache Tomcat 9.0.118 → 9.0.120

[mbiuki]

Proposed Changes

Bumps Apache Tomcat on main from 9.0.118 to the current release 9.0.120 (2026-07-03). PR #35798 backported a Tomcat bump to the 24.12.27 LTS branch but main was left behind.

Single-line change in parent/pom.xml — tomcat.version is the one source of truth; it drives the Maven dependency, the assembled dotserver/tomcat-${tomcat.version} distribution, and the tomcat:${tomcat.version}-jdk11 Docker base image. No other hardcoded references exist.

Security-relevant changes (9.0.119 → 9.0.120)

• CVE-2024-56337 — startup check blocks web apps potentially vulnerable to it unless the JVM protection is confirmed; reflection only used when required
• CVE-2025-49125 — regression fix restoring PreResources/PostResources access below the web-app root
• WebDAV serveSubpathOnly — operation destinations now also restricted to the sub-path
• WebSocket permessage-deflate — no longer drops bytes when a compressed message inflates past the buffer
• Fix for a 9.0.119 regression breaking some request-body reads via Reader

Checklist

• org.apache.tomcat:tomcat:9.0.120:tar.gz + tomcat-embed-core:9.0.120 resolve from the dotCMS Artifactory mirror
• ./mvnw install -pl :dotcms-core --am -DskipTests -Ddocker.skip → BUILD SUCCESS; assembly unpacks dotserver/tomcat-9.0.120/ with dotCMS overrides applied

Closes #36592

🤖 Generated with Claude Code

[claude]

Claude finished @mbiuki's task in 34s —— View job

---

Claude finished @mbiuki's task in 38s —— View job

---

Rollback-Safety Analysis

• Read docs/core/ROLLBACK_UNSAFE_CATEGORIES.md
• Get full PR diff (de0fe190...deea6caf)
• Analyze diff against each unsafe category
• Post verdict / apply label

Diff: single-line version bump in parent/pom.xml:

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

This only changes the tomcat.version Maven property, which drives the Tomcat dependency version, the assembled dotserver/tomcat-${tomcat.version} distribution, and the Docker base image tag. No runonce DB migration task, no Elasticsearch mapping code, no ImmutableContentlet/contentlet_as_json model version, no DROP/RENAME SQL, no REST/GraphQL contract change, no OSGi interface change, and no VTL viewtool contract change are present in this diff. It doesn't match any category in C-1..C-4, H-1..H-8, or M-1..M-4.

Verdict: ✅ Safe to Rollback — this is a pure build-time dependency bump (application server container version), with no persisted state, schema, or API contract implications for N-1.

[erickgonzalez]

Looks good

[mergify]

Queued — the merge queue status continues in this comment ↓.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-07-15 15:38 UTC · Rule: default · triggered by @mbiuki with the merge queue checkbox
• ✅ Checks skipped · PR is already up-to-date
• 🚫 Left the queue — 2026-07-15 15:40 UTC · at deea6cafc5643275ae3ef6e30e78cbbee3f8e025

This pull request spent 2 minutes 6 seconds in the queue, including 5 seconds running CI.

Required conditions to merge

• #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • security: upgrade Apache Tomcat 9.0.118 → 9.0.120 #36593
• github-review-approved [🛡 GitHub branch protection]
  • security: upgrade Apache Tomcat 9.0.118 → 9.0.120 #36593
• github-review-decision = APPROVED [🛡 GitHub branch protection]
  • security: upgrade Apache Tomcat 9.0.118 → 9.0.120 #36593
• any of [🛡 GitHub branch protection]:
  • check-success = Finalize / Final Status
  • check-neutral = Finalize / Final Status
  • check-skipped = Finalize / Final Status
• any of [🛡 GitHub branch protection]:
  • check-success = Initialize / Initialize
  • check-neutral = Initialize / Initialize
  • check-skipped = Initialize / Initialize

Reason

Pull request #36593 has been dequeued

GitHub refused to merge the pull request. Pull Request is in the merge queue. This is usually enforced by a branch protection or ruleset rule.

Hint

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

• Requeue this pull request