security(deps): upgrade bundled DOMPurify in TinyMCE / Monaco / Swagger UI assets

[mbiuki]

Proposed Changes

Fixes #35996 (CVE-2025-26791 follow-up). Upgrades the three vendored third-party UI bundles that still ship pre-3.2.4 DOMPurify copies inside the WAR:

Bundle	Path	Version	Bundled DOMPurify
TinyMCE	ext/tinymcev7	7.2.1 → 7.9.3	3.0.5 → 3.2.6
Monaco	html/assets/monaco-editor	0.33.0 → 0.55.1	2.3.1 → 3.2.7
Swagger UI	html/portlet/ext/apiplayground	~5.17 → 5.32.9	3.1.4 → 3.4.11

Compatibility notes

• Monaco / Dojo AMD: the legacy admin loads Monaco through Dojo's AMD loader (top_inc.jsp modulePaths: {vs: …}, edit_contentlet.jsp require(["vs/editor/editor.main"])). Monaco 0.53+ deprecated the AMD build but 0.55.1 still ships it — min/vs/editor/editor.main.js remains define("vs/editor/editor.main", …). The alternative (0.52.2, last non-deprecated AMD release) still bundles DOMPurify 3.1.7 < 3.2.4, so it wouldn't remediate the CVE.
• TinyMCE: consumed by URL from the UVE inline-editing SDK (/ext/tinymcev7/tinymce.min.js); 7.x minor-line bump, same plugin set (verified 29/29 plugins present). dotCMS-added langs/ directory preserved; everything else is verbatim tinymce@7.9.3 npm content.
• Swagger UI: SwaggerUIBundle init API in index.jsp unchanged in 5.32.9; the three dist files are verbatim swagger-ui-dist@5.32.9. Cache-buster query strings bumped (?v=20240819 → ?v=20260717).
• Out of scope: the Angular apps (dotAdmin, binary-field-builder) load a separate Monaco copied at build time from core-web's monaco-editor@0.33.0 npm dependency — that upgrade is a code-level change (typings) and should be a follow-up issue.

Verification

• grep sweep confirms no DOMPurify < 3.2.4 version strings remain under the three vendored asset paths.
• Monaco AMD entry point verified: define("vs/editor/editor.main" present in the new editor.main.js; editor.main.css path referenced by top_inc.jsp:44 unchanged.
• CI test results (Postman apiplayground/E2E editor coverage) will be posted as a comment when the run completes.

🤖 Generated with Claude Code

[claude]

Claude finished @mbiuki's task in 9m 1s —— View job

---

PR Review: Upgrade bundled DOMPurify (TinyMCE / Monaco / Swagger UI)

• Verify no DOMPurify < 3.2.4 remains under the three vendored paths
• Check Monaco AMD entry point + CSS path used by top_inc.jsp
• Check TinyMCE integration (URL loading, plugins, langs preserved)
• Check Swagger UI init API + cache-buster query strings in index.jsp
• Verify no stray/unreferenced files or path mismatches introduced
• Post review

This is a vendored-asset bundle upgrade — no dotCMS Java/Angular source changes, so the review focuses on remediation completeness and integration-path integrity rather than logic.

Verification results (all pass)

DOMPurify remediation — confirmed ✅

• TinyMCE: tinymce.min.js / tinymce.js / themes/silver/theme.js → DOMPurify.version = '3.2.6' (≥ 3.2.4 ✅)
• Monaco: min/vs/editor.api-CalNCsUg.js:319 → version="3.2.7" ✅
• Swagger UI: swagger-ui-bundle.js:2 → DOMPurify.version="3.4.11" ✅ (the version=3.1.0 hits in that file are Swagger-UI's own metadata, not DOMPurify — verified in context)
• No 3.0.x / 3.1.x / 2.3.x / 3.2.0–3.2.3 DOMPurify strings remain under the three paths.

Monaco integration — confirmed ✅

• top_inc.jsp:44 references editor/editor.main.css and :71-73 maps AMD path vs → /html/assets/monaco-editor/min/vs; edit_contentlet.jsp:149 does require(["vs/editor/editor.main"], …).
• Both stable entry points still exist after the 0.33→0.55.1 layout change: editor/editor.main.css present, and editor/editor.main.js still define("vs/editor/editor.main", …).
• New 0.55 hashed-chunk layout resolves relatively from the AMD vs baseUrl (../monaco.contribution-*, ../editor.api-*, ../workers-*, ../assets/*.worker-*.js via toUrl(...)), and the referenced min/vs/assets/*.worker-*.js files are all present on disk. Workers are instantiated via a Blob+trustedTypes factory, so no MonacoEnvironment.getWorkerUrl wiring is required in dotCMS. The old flat layout (base/worker/workerMain.js, basic-languages/<lang>/<lang>.js) is fully removed with no dangling references from the JSPs.

TinyMCE integration — confirmed ✅

• 29/29 plugin directories present; dotCMS-added langs/ (README.md) preserved.

Swagger UI integration — confirmed ✅

• index.jsp SwaggerUIBundle({...}) init API unchanged; cache-busters bumped to ?v=20260717 on all three assets, matching the three replaced dist files.

Notes (non-blocking)

• 🟡 Medium: html/assets/monaco-editor/min/vs/nls.messages.*.js.js — the localized NLS message files ship with a double .js.js extension (e.g. nls.messages.fr.js.js). This is the verbatim monaco-editor 0.55.1 vite-build output — the internal module id is vs/nls.messages.fr.js and the AMD loader appends .js, so nls.messages.fr.js → file nls.messages.fr.js.js resolves correctly. It only loads for non-en UI languages (the loader returns {} for English), so the default admin path is unaffected. No action needed; flagging only because the naming looks like a copy artifact at a glance.
• Cannot execute the editor UIs in this environment. The CVE remediation and all static integration paths are verified, but a manual smoke test of (a) a contentlet WYSIWYG/TinyMCE field, (b) the Monaco code-field editor in edit_contentlet, and (c) the /c/portal/../apiplayground Swagger page is worth doing before merge, since Monaco jumped four minor lines (0.33→0.55). The PR's plan to attach Postman/E2E results covers this.
• Out of scope (correctly, per PR): the Angular-bundled Monaco (binary-field.js, dotAdmin) loads a separate monaco-editor@0.33.0 copied at build time from core-web — not touched here and should be a follow-up.

Verdict: Remediation is complete and all vendored integration points check out statically. No blocking issues found.