CVE-2026-47762 - TinyMCE mce:protected comment XSS

TinyMCE disclosed a stored XSS issue in the protect option handling path. Forged mce:protected comments can bypass sanitization and become scriptable when TinyMCE restores protected content. TinyMCE’s fixed releases validate the decoded protected content against the configured protect regular expressions before restoration.

This recipe matters for applications that use protect to preserve server tokens, template syntax, merge tags, CMS placeholders, shortcode syntax, Liquid/Handlebars-style fragments, or other non-editable content inside user- authored rich text.

When to use it

Use this recipe when a web application embeds TinyMCE and enables the protect option for merge tags, templates, shortcodes, or server-controlled fragments. It is built for source-code remediation, stored-XSS review, rich-text editor hardening, and audit evidence that forged mce:protected comments cannot restore scriptable content.

Inputs

  • TinyMCE version, package lockfiles, editor configuration, protect regexes, sanitizer pipeline, storage model, and render sinks.
  • Source paths that initialize TinyMCE, persist editor output, restore protected content, sanitize HTML, or render stored rich text.
  • Regression fixtures for forged mce:protected comments, valid protected fragments, benign rich text, stored replay, and expected inert output.
  • Boundary evidence: who can edit content, who can view it, privileged pages, CSP/session posture, and stored-content cleanup owner.

Affected versions

  • Vulnerable packages: tinymce (npm), tinymce/tinymce (Composer), and TinyMCE (NuGet)
  • Vulnerable ranges: <5.11.1, >=6.0.0, <7.9.3, and >=8.0.0, <8.5.1
  • Fixed versions: 5.11.1 LTS, 7.9.3, 8.5.1, or later on the selected release line
  • Affected configuration: TinyMCE protect option and render paths that restore mce:protected comments
  • Affected content: stored rich text containing template placeholders, merge tags, shortcodes, or protected fragments that are later rendered to another user or processed by server-side template logic

Indicator-of-exposure

  • The repository depends on, vendors, bundles, CDN-pins, or deploys TinyMCE in an affected range.
  • TinyMCE is configured with protect rules or preserves template/comment fragments using mce:protected.
  • Less-trusted authors can submit CMS content, email templates, marketing pages, comments, tickets, snippets, merge-tag content, shortcode content, help-center articles, product descriptions, or model-generated content.
  • Stored TinyMCE content is rendered to other users through normal pages, previews, admin review screens, exports, emails, PDFs, mobile/webviews, or customer support tools.
  • Server-side sanitization, template rendering, CSP, iframe sandboxing, or render tests do not explicitly cover protected comments and restored template fragments.

Quick checks:

rg -n "tinymce|TinyMCE|protect\\s*:|mce:protected|<!--|shortcode|merge tag|merge_tag|handlebars|liquid|mustache|template|valid_elements|extended_valid_elements|sanitize|DOMPurify|HtmlSanitizer|bleach|sanitize-html|wysiwyg|rich text" .
npm ls tinymce
pnpm why tinymce
yarn why tinymce
composer show tinymce/tinymce
dotnet list package | rg -i "tinymce"
rg -n "tinymce|TinyMCE|protect\\s*:|mce:protected|shortcode|merge[_ -]?tag|handlebars|liquid|mustache" package.json package-lock.json pnpm-lock.yaml yarn.lock composer.json composer.lock *.csproj static public assets src app resources templates . 2>/dev/null

Windows:

rg -n "tinymce|TinyMCE|protect\\s*:|mce:protected|<!--|shortcode|merge tag|merge_tag|handlebars|liquid|mustache|template|valid_elements|extended_valid_elements|sanitize|DOMPurify|HtmlSanitizer|bleach|sanitize-html|wysiwyg|rich text" .
npm ls tinymce
pnpm why tinymce
yarn why tinymce
composer show tinymce/tinymce
dotnet list package | rg -i "tinymce"
rg -n "tinymce|TinyMCE|protect\\s*:|mce:protected|shortcode|merge[_ -]?tag|handlebars|liquid|mustache" package.json package-lock.json pnpm-lock.yaml yarn.lock composer.json composer.lock *.csproj static public assets src app resources templates .

Do not publish forged protected-comment HTML, execute JavaScript payloads, open unsafe stored content in a privileged browser, paste payloads into production editors, or dump user-authored template content into logs or commits.

Remediation strategy

  • Upgrade every controlled TinyMCE package, vendored asset, CDN URL, lockfile, SBOM, generated dependency report, and rendered deployment artifact to 5.11.1 LTS, 7.9.3+, or 8.5.1+ on the selected release line.
  • Prefer 8.5.1+ for active 8.x deployments and 7.9.3+ for active 7.x deployments. Treat TinyMCE 6.x as needing a supported-line migration because the fixed ranges published for this advisory are 5 LTS, 7.x, and 8.x.
  • Review every protect regular expression. Keep each rule narrow, anchored where possible, and limited to the exact template syntax the product must preserve.
  • Keep or add server-side HTML sanitization for stored content. Do not let protected comment restoration skip the server-side sanitizer or template trust boundary.
  • Re-sanitize existing stored rich-text records, or enforce on-read/on-render sanitization until a migration can safely clean older records.
  • Add regression tests that preserve legitimate protected fragments but reject, strip, or render inert forged mce:protected comments, scriptable URLs, event handlers, unsafe CSS, and template fragments outside the configured protect allow-list.
  • If CVE-2026-47759 or CVE-2026-47761 is also in scope, combine upgrade and stored-content cleanup while keeping protected-comment fixtures distinct.

The prompt

You are remediating CVE-2026-47762 / GHSA-v98h-vmpc-fpqv, a TinyMCE stored
XSS issue where forged `mce:protected` comments can bypass sanitization when
the `protect` option restores protected content. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades TinyMCE, audits `protect`
  rules, preserves or adds server-side sanitization, refreshes generated
  artifacts, adds safe protected-comment regression coverage, and documents
  stored-content cleanup, or
- TRIAGE.md if this repository does not control an affected TinyMCE runtime,
  package, vendored asset, CDN pin, `protect` configuration, or protected
  content rendering surface.

## Rules

- Scope only CVE-2026-47762 / GHSA-v98h-vmpc-fpqv and directly related
  TinyMCE `protect`, protected-comment restoration, stored-content, template,
  and render-path controls. If adjacent TinyMCE CVEs are present, note the
  shared upgrade path without expanding into unrelated editor changes.
- Treat stored rich text, template placeholders, merge tags, shortcodes,
  customer content, admin notes, email bodies, CMS pages, session cookies, auth
  tokens, screenshots, exports, and rendered previews as sensitive.
- Do not create exploit pages, execute JavaScript payloads, paste test XSS into
  production editors, use privileged browsers for unsafe previews, or commit
  customer-authored HTML.
- Do not remove server-side sanitizers, CSP, iframe isolation, content approval,
  audit logs, template validation, or rich-text tests to make the upgrade pass.
- Do not auto-merge.

## Steps

1. Inventory every TinyMCE reference controlled by this repository: npm,
   Composer, NuGet, lockfiles, vendored static assets, CDN URLs, package
   managers, Docker images, CMS plugins, admin bundles, mobile/webview assets,
   SBOMs, generated dependency reports, docs that pin versions, and rendered
   deployment artifacts.
2. Determine every resolved TinyMCE version. A target is vulnerable if it
   resolves to `<5.11.1`, `>=6.0.0, <7.9.3`, or `>=8.0.0, <8.5.1`.
3. Search for protected-content usage and render paths: `protect` rules,
   `mce:protected`, template placeholders, merge tags, shortcodes, Liquid,
   Handlebars, Mustache, comment preservation, CMS pages, email templates,
   previews, exports, PDFs, mobile/webviews, sanitizer configuration, CSP, and
   iframe sandboxing.
4. If the repository only contains documentation or an external vendor owns
   TinyMCE, stop with `TRIAGE.md` listing checked files, runtime owner, and the
   required fixed version.
5. Upgrade all controlled TinyMCE references:
   - 5.x LTS deployments to `5.11.1+` when a commercial LTS path is available;
   - 7.x deployments to `7.9.3+`;
   - 8.x deployments to `8.5.1+`;
   - 6.x deployments to a supported fixed line, normally `7.9.3+` or `8.5.1+`.
6. Refresh lockfiles, package-manager metadata, vendored assets, CDN hashes,
   image digests, rendered deployment artifacts, SBOMs, dependency reports, and
   release documentation.
7. Verify or patch protected-content handling:
   - sanitize on the server before storage or before rendering;
   - review every `protect` regex for breadth, anchoring, escaping, and exact
     syntax ownership;
   - ensure restored protected comments are revalidated by patched TinyMCE and
     still pass through the server-side sanitizer/template boundary;
   - reject or neutralize forged `mce:protected` comments, JavaScript URLs,
     event handlers, unsafe CSS, unauthorized template syntax, and broad
     comment preservation;
   - ensure preview, export, email, PDF, and mobile/webview renderers use the
     same sanitized content boundary as normal page views.
8. Add safe regression coverage without executing payloads:
   - dependency policy rejects affected TinyMCE versions;
   - legitimate protected fragments still round-trip when allowed;
   - forged `mce:protected` comments are stripped, rejected, or rendered inert;
   - sanitizer output contains no scriptable URLs, event handlers, unauthorized
     protected comments, or untrusted template fragments;
   - logs and test snapshots do not contain customer content or session data.
9. Add a PR body section named `CVE-2026-47762 operator actions` that states:
   - TinyMCE versions before and after;
   - where `protect` is configured and what syntax it preserves;
   - every protected-content authoring and rendering surface checked;
   - whether server-side sanitization was already present or added;
   - whether existing stored rich text must be re-sanitized, migrated, or
     cleaned on read;
   - whether CSP, iframe sandboxing, email/PDF renderers, or mobile/webview
     clients need follow-up;
   - which validation commands passed.
10. Run available validation: package install, lockfile integrity, frontend
    tests, sanitizer unit tests, protected-comment render tests,
    lint/typecheck, browser smoke tests, container build, SBOM refresh, and
    dependency/security scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-47762 in TinyMCE protect handling`.

## Stop conditions

- No affected TinyMCE package, vendored asset, CDN pin, `protect`
  configuration, or protected-content rendering surface is controlled by this
  repository.
- The TinyMCE runtime or CMS plugin is owned by another team or vendor; name
  the owner and required fixed versions in `TRIAGE.md`.
- Moving from TinyMCE 6.x or unsupported 5.x requires a broader product
  migration that cannot fit in this PR.
- Validating exposure would require publishing exploit HTML, using production
  content, opening unsafe previews in a privileged browser, or exposing stored
  customer data.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades TinyMCE, verifies protected-content restoration, adds stored-XSS regression tests, and documents stored-content review or re-sanitization.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, editor/render boundary, affected content types, required fix, and residual risk.
  • The output must include exact validation commands and must not run live XSS payloads against production, expose session tokens, or include customer HTML.

Verification - what the reviewer looks for

  • No controlled npm, Composer, NuGet, vendored asset, CDN URL, image, SBOM, or generated report resolves TinyMCE to <5.11.1, >=6.0.0, <7.9.3, or >=8.0.0, <8.5.1.
  • TinyMCE protect rules are narrow, intentional, and covered by regression tests.
  • Stored rich-text render paths use patched TinyMCE assets and server-side sanitization or an equivalent trusted render boundary.
  • Regression tests show forged mce:protected comments cannot become scriptable through the product’s actual restore-and-render path.
  • Existing content cleanup is either completed, safely handled on render, or explicitly tracked as an operator action.

Watch for

  • Updating npm while a CMS plugin, Composer package, NuGet package, vendored asset, CDN URL, or static bundle still serves an affected TinyMCE build.
  • Leaving broad protect regular expressions that preserve arbitrary comments or template text from untrusted authors.
  • Treating protected comment restoration as trusted and skipping server-side sanitization afterward.
  • Sanitizing only edit screens while previews, public pages, email, PDF export, or mobile/webview clients render older stored HTML.
  • Snapshot tests that commit real customer content or privileged rendered HTML.

References