Upgrade BouncyCastle to 1.85 and Tika to 3.3.2 across dotSAML plugin, core BOM, and Tika bundle (scanner hygiene — CVE-2025-14813 / CVE-2026-59638)

Description

Reported via Freshdesk #38700 (customer on dotCMS 25.07.10 LTS, self-hosted).

A customer's dependency scanner flags outdated BouncyCastle and Tika copies across the SAML plugin and core, against CVE-2025-14813 and the newer CVE-2026-59638. This is a scanner-hygiene follow-up to the earlier core BouncyCastle fix (#35896 / #35901) and the Tika transitive-BC fix (#36139), neither of which touched the SAML plugin's own bundled copy.

Exploitability — already assessed, NOT reachable

Firsthand source review across dotCMS/core (release-25.07.10_lts_v17) and dotCMS/com.dotcms.dotsaml found no reachable/exploitable code path for either CVE:

• dotSAML plugin bundles bcprov-jdk15on:1.54 only (no bctls, no bcpkix — all transitives excluded), has zero direct org.bouncycastle imports, and never registers BC as a JCE provider (SamlInitializer.init() only runs OpenSAML's JavaCryptoValidationInitializer, which validates algorithm availability but does not register a provider).
• core registers no BC provider anywhere (0 Security.addProvider/BouncyCastleProvider); the only direct BC use is XmlToolCache.java (SHA1Digest + Base64 for a Velocity cache key). No BC JSSE/TLS usage; TLS uses native OpenSSL / JDK SunJSSE.
• CVE-2026-59638 (JSSE hostname CN-fallback, CVSS 9.3) lives in BC's bctls module, which is not shipped — not reachable.

This issue therefore tracks a dependency-hygiene upgrade to clear customer scanners, not an active-vulnerability remediation.

Current versions (release-25.07.10_lts_v17 = customer build)

• com.dotcms.dotsaml (samlbundle 25.06.3) bundles bcprov-jdk15on:1.54
• core bouncy-castle.version = 1.84 (bcprov-jdk18on + bcpkix-jdk18on)
• core tika.version = 3.3.1

Proposed change — BouncyCastle → 1.85, Tika → 3.3.2

1. dotSAML plugin (dotCMS/com.dotcms.dotsaml, pom.xml): migrate bcprov-jdk15on:1.54 → bcprov-jdk18on:1.85, then release a new com.dotcms.samlbundle from current main (already Maven-based; the customer's supplied patch applies as-is). No separate legacy branch exists — 25.06.3 is commit e44f7c3 on main's own history.
2. core bom/application/pom.xml: bump bouncy-castle.version 1.84 → 1.85.
3. core osgi-base/system-bundles/pom.xml: bump tika.version 3.3.1 → 3.3.2, and update the com.dotcms.samlbundle reference to the newly released version.
4. core independent-projects/core-plugins/tika-plugin/pom.xml: bump tika.version 3.3.1 → 3.3.2.
5. Apply the samlbundle reference + version bumps on both main and the 25.07.10 LTS branch (customer is on LTS).

Tika 3.3.2 pulls BouncyCastle 1.85 transitively (confirmed via Maven Central), covering the Tika-bundled BC copy — same pattern as #36139.

Acceptance Criteria

• A com.dotcms.samlbundle released from main no longer bundles bcprov-jdk15on:1.54; it bundles bcprov-jdk18on:1.85 (verify with unzip -l on the built jar).
• core bom/application/pom.xml bouncy-castle.version = 1.85; build resolves bcprov-jdk18on + bcpkix-jdk18on at 1.85.
• core tika.version = 3.3.2 in both osgi-base/system-bundles/pom.xml and independent-projects/core-plugins/tika-plugin/pom.xml; the built Tika bundle contains BouncyCastle 1.85.
• core osgi-base/system-bundles/pom.xml references the new samlbundle release on both main and the 25.07.10 LTS branch.
• A dependency scan of the built LTS image no longer flags BouncyCastle 1.54/1.84 or Tika 3.3.1 against CVE-2025-14813 / CVE-2026-59638.
• SAML login (authn + encrypted-assertion decrypt) still works after the BouncyCastle upgrade in the plugin.

Related

• Freshdesk: #38700 (this); precedent #37703 (Tika transitive BC)
• GitHub: #35896 / #35897 / #35901 (core CVE-2025-14813 fix), #36139 (Tika 3.2.2 → 3.3.1 for BC)

Start by reading the dependency declarations in com.dotcms.dotsaml/pom.xml, bom/application/pom.xml, osgi-base/system-bundles/pom.xml, and independent-projects/core-plugins/tika-plugin/pom.xml on both required branches. Build the samlbundle and Tika bundle, then use unzip -l and dependency resolution to verify the expected versions. Done means the old copies are absent, the new samlbundle reference is applied, and SAML authentication plus encrypted-assertion decryption still work.