sec: upgrade netty, commons-fileupload and pin grpc to patched versions

[mbiuki]

Proposed Changes

Remediates the dependency vulnerabilities from a customer security scan (helpdesk ticket 38243) that were verified as part of the dotCMS application stack. Full package-by-package classification is in the linked issue.

• Bump the six pinned io.netty:* artifacts in bom/application/pom.xml from 4.1.118.Final to 4.1.136.Final (CVE-2025-55163, CVE-2025-58057)
• Bump commons-fileupload from 1.5 to 1.6.0 (CVE-2025-48976)
• Import io.grpc:grpc-bom 1.82.2 ahead of langchain4j-bom so the transitive grpc-netty-shaded (previously 1.71.0, bundles a vulnerable netty) resolves to a patched release
• Update the two legacy Liferay createItem overrides to match the commons-fileupload 1.6.0 signature (Map<String, String> param, no throws FileUploadException) — behavior unchanged, they only capture the uploaded filename into the session

Not addressed here (documented in #36546): jdom 1.1.3 (needs jdom2 migration; required at runtime by WebDAV), Elasticsearch 7.10.2 client (deliberate Apache-2.0 pin, OpenSearch migration is the fix), cryptacular (not in core), and the ImageMagick/OpenEXR OS libraries (libvips dependencies in the Docker image, patched via image rebuilds).

Checklist

• Code compiles: ./mvnw install -pl :dotcms-core --am -DskipTests -Ddocker.skip → BUILD SUCCESS
• Resolved versions verified via dependency:tree: netty-codec 4.1.136.Final, commons-fileupload 1.6.0, grpc-netty-shaded 1.82.2

Closes #36546

🤖 Generated with Claude Code

[claude]

Claude finished @mbiuki's task in 3m 44s —— View job

---

PR Review: security dependency upgrades

• Read the diff (bom/application/pom.xml, two Liferay fileupload overrides)
• Verified BOM import ordering and @Override correctness
• Checked for regressions vs. the removed netty pins

New Issues

No blocking issues.

• 🟡 Medium: bom/application/pom.xml:83 — grpc-bom is bumped from the transitively-resolved 1.71.0 to 1.82.2 (11 minor versions). gRPC keeps backward compatibility within 1.x and it's shaded (grpc-netty-shaded), so risk is low, but this is a large jump for a dependency only exercised via langchain4j-vertex-ai-gemini. Assumption: the Vertex AI Gemini integration is not covered by the integration/Postman suites. What to verify: exercise the Gemini/langchain4j code path once (or confirm CI covers it) so a shaded-netty or gRPC API break doesn't surface only at runtime in production.

Notes (non-blocking, looks correct)

• BOM ordering is right. netty-bom (line 98) is imported before langchain4j-bom (line 106), so it wins for overlapping managed netty artifacts — matching the "first BOM wins" rule documented in the file header. grpc-bom sits before netty-bom, but grpc-bom only manages io.grpc:* (not io.netty:*), so there's no precedence conflict between the two. The author's dependency:tree verification (all io.netty 4.x → 4.1.136.Final) confirms this.
• Replacing the six explicit <dependency> pins with a single netty-bom import is a net improvement — direct dependencyManagement entries and a BOM import both override langchain4j's transitive versions here (given the ordering), and the BOM also covers the native/classifier artifacts (transport-native-epoll/kqueue, resolver-dns-native-macos, netty-tcnative) that plain pins handled poorly. The removed 4.1.118-era note ("Required for DefaultHeaders$ValueValidator") is still satisfied since 4.1.136 > 4.1.118.
• createItem overrides are correct. Both now carry @Override with Map<String, String> and no throws FileUploadException, matching the commons-fileupload 1.6.0 signature — the reported BUILD SUCCESS confirms it, since a mismatched @Override would fail compilation. FileUploadException remains imported/used by parseRequest in LiferayFileUpload.java (line 64), so no unused-import warning is introduced. Behavior (capturing the uploaded filename into the session) is unchanged.

Summary

Clean, well-scoped security bump. The only thing worth doing before merge is a sanity check on the langchain4j/Vertex-AI Gemini path given the grpc 1.71→1.82 jump; everything else (netty family alignment, fileupload signature update, BOM ordering) is correct. Versions are added to bom/application/pom.xml per repo convention. ✅

· issue-36546-upgrade-vulnerable-dependencies

[mbiuki]

Extended the netty fix based on a Trivy scan of the published image (dotcms/dotcms:26.06.30-01, validating the scanner from #36554): four netty siblings arrive transitively at older vulnerable versions that the original six pins didn't cover.

Artifact	Was (transitive)	CVEs	Now
netty-codec-http	4.1.132.Final	CVE-2026-42584, CVE-2026-42587	4.1.136.Final
netty-codec-http2	4.1.132.Final	CVE-2026-42587	4.1.136.Final
netty-resolver-dns	4.1.112.Final	CVE-2026-45674, CVE-2026-47691	4.1.136.Final
netty-codec-dns	4.1.112.Final	CVE-2026-42579	4.1.136.Final

Resolution verified via dependency:tree (all four now 4.1.136.Final) and ./mvnw install -pl :dotcms-core --am -DskipTests -Ddocker.skip → BUILD SUCCESS.

🤖 Generated with Claude Code

[mbiuki]

Follow-up on the review's netty-coverage item (pushed 92b74a16bf): the concern was real. dependency:tree -Dincludes=io.netty on the branch showed seven more netty artifacts arriving transitively at skewed versions that the ten pins didn't cover:

Artifact	Was (transitive)	Now
netty-transport-native-epoll	4.1.63.Final	4.1.136.Final
netty-transport-native-kqueue	4.1.63.Final	4.1.136.Final
netty-transport-native-unix-common	4.1.63.Final	4.1.136.Final
netty-codec-socks	4.1.118.Final	4.1.136.Final
netty-handler-proxy	4.1.118.Final	4.1.136.Final
netty-transport-classes-epoll	4.1.130.Final	4.1.136.Final
netty-resolver-dns-classes-macos	4.1.112.Final	4.1.136.Final

Rather than growing the pin list, the commit replaces all individual netty pins with a single io.netty:netty-bom:4.1.136.Final import (placed before langchain4j-bom, same first-BOM-wins pattern already used for grpc-bom). This aligns the whole family — including native/classifier artifacts pins handle poorly — and moves netty-tcnative to its paired 2.0.78.Final. Net diff: −58/+15 lines.

Verification: dependency:tree now resolves every io.netty 4.x artifact to 4.1.136.Final, and ./mvnw install -pl :dotcms-core --am -DskipTests → BUILD SUCCESS.

On the previous CI run's failures: only Postman Tests - Default actually failed (the other five red jobs were fail-fast cancellations). Its three assertion failures — bundle-delete message text, 'a second language must be present', and a block-editor body-format mismatch — don't touch netty/commons-fileupload/grpc code paths, and PR #36618 (which includes the same main merge) passed the identical suite this morning, so they look flaky/order-dependent. The fresh run on this push will confirm.

🤖 Generated with Claude Code

[mbiuki]

✅ CI results on 92b74a16bf (netty-bom follow-up): all 49 checks pass, 0 failures.

Full suite green: JVM unit tests, all Integration MainSuites (1a/1b/2a/2b/3a, Junit5), all Postman collections, Karate, and E2E Playwright.

Worth noting: the Postman Tests - Default assertion failures from the previous run (bundle-delete message text, second-language presence, block-editor body format) did not reproduce on this run with the same test code — confirming they were flaky/order-dependent rather than related to the dependency upgrades.

PR is now blocked only on review

🤖 Generated with Claude Code