CVE-2026-47762

What it actually does

TinyMCE versions before 5.11.1, 7.9.3, and 8.5.1 contain a stored cross-site scripting flaw in handling of forged mce:protected comments when the protect option is used. An attacker with the ability to submit or edit rich-text content can craft protected-comment-like markup that bypasses TinyMCE sanitization and is later restored into executable script content. Because the script runs in the browser of a user who views or edits the affected content, it can act with that user’s application session privileges, potentially reading sensitive page data, performing unauthorized actions, modifying content, or stealing tokens accessible to JavaScript.

Why it matters to the business

Applications using vulnerable TinyMCE versions with the protect option enabled may allow malicious content to persist and later compromise users who open that content. This can lead to account takeover, unauthorized content changes, exposure of sensitive information displayed in the application, fraudulent actions performed as trusted users, and reputational impact if malicious scripts affect customers or employees. The CVSS score is high, but EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, so remediation should be prioritized based on where TinyMCE is exposed to untrusted authors or high-privilege reviewers.

How an attack unfolds

An attacker first needs a path to create or modify content processed by TinyMCE in an application that uses the protect option. They submit content containing forged mce:protected comments designed to survive sanitization. The malicious payload is stored by the application as ordinary rich-text content. Later, when another user opens, previews, edits, or otherwise restores that content through TinyMCE, the editor mishandles the forged protected comment and reintroduces executable script. The script then executes in the victim’s browser within the application origin. From there, the attacker can perform actions available to the victim’s session, such as reading visible data, changing content, submitting forms, initiating application workflows, or exfiltrating tokens or page contents if they are accessible to client-side JavaScript.

How to fix it

Upgrade TinyMCE to a fixed version: 5.11.1 or later for the 5.x line, 7.9.3 or later for the 7.x line, or 8.5.1 or later for the 8.x line. If TinyMCE is bundled by a framework, CMS, plugin, package, or commercial application, update the containing package to a release that includes one of those fixed TinyMCE versions. If immediate upgrade is not possible, reduce exposure by disabling the protect option where feasible, preventing untrusted users from submitting TinyMCE-rendered content, applying strict server-side HTML sanitization using an allowlist, and enforcing a strong Content Security Policy that blocks inline scripts and restricts script sources. Review and sanitize previously stored rich-text content that may have been submitted through affected versions, especially content authored by untrusted or low-privileged users.

How to confirm the fix worked

Confirm the deployed TinyMCE version is 5.11.1 or later, 7.9.3 or later, or 8.5.1 or later. Validate both direct dependencies and bundled copies in web assets, package lockfiles, vendor directories, CMS plugins, and minified static files. Check whether the protect option is enabled in TinyMCE initialization code; systems not using protect are not expected to be affected by this specific issue. Test by submitting benign proof-of-concept content containing forged mce:protected-style comments in a non-production environment and verifying that it is not restored into executable script after save, reload, preview, and edit workflows. Confirm server-side sanitization and CSP controls remain active after upgrade.

Typical attack path

1. Identify an application using TinyMCE before 5.11.1, 7.9.3, or 8.5.1 with the protect option enabled.
2. Obtain a low-privileged account or other capability to submit rich-text content.
3. Craft content containing forged mce:protected comments that encapsulate or restore attacker-controlled script.
4. Submit or save the malicious content so it becomes stored in the application.
5. Wait for a victim, such as an administrator, moderator, editor, or another user, to view or edit the content.
6. Trigger TinyMCE restoration of the protected content and execute JavaScript in the victim’s browser.
7. Use the victim’s session context to read sensitive data, modify content, perform unauthorized actions, or exfiltrate client-accessible information.

How to detect it

To assess possible prior exploitation, review application logs, WAF logs, reverse proxy logs, audit trails for content creation or editing, and stored rich-text records for suspicious HTML comments and script-like payloads. Focus on content submitted by low-privileged or newly created accounts and later accessed by administrators, moderators, editors, support staff, or other privileged users. Search for mce:protected comment markers combined with script tags, JavaScript URLs, event-handler attributes, encoded HTML, base64 payloads, or suspicious external domains. Correlate suspicious content submissions with subsequent unusual user activity such as unexpected administrative changes, content defacement, new users or API keys, permission changes, anomalous form submissions, or outbound requests to unfamiliar domains from browser sessions. If browser security telemetry, CSP violation reports, EDR browser events, or proxy logs are available, look for script execution or outbound connections immediately after viewing affected content. No specific threat actors or ransomware campaigns are currently reported for this vulnerability.

• mce:protected
• <!--mce:protected
• mce:protected-->
• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• eval(
• document.cookie
• localStorage
• sessionStorage
• atob(
• btoa(
• fetch(
• XMLHttpRequest
• navigator.sendBeacon
• <img
• <svg
• <iframe
• data:text/html
• data:application/javascript

What your security team should do

• Inventory applications and products that embed TinyMCE, including bundled JavaScript assets and downstream packages.
• Prioritize upgrades for internet-facing applications, multi-user authoring platforms, administrative portals, CMS workflows, support portals, and any environment where low-privileged users can create content viewed by higher-privileged users.
• Upgrade to TinyMCE 5.11.1, 7.9.3, 8.5.1, or later as appropriate for the deployed major version.
• Search code and configuration for TinyMCE protect option usage and disable it where not strictly required.
• Review recently created or modified rich-text content for suspicious mce:protected comments, script-like payloads, event handlers, encoded JavaScript, and unusual HTML comment patterns.
• Add or tighten Content Security Policy to reduce impact of stored XSS, especially by blocking unsafe-inline scripts where possible.
• Monitor application, WAF, and browser telemetry for attempts to submit protected-comment payloads or script-bearing rich-text content.
• Because the issue is not currently listed in CISA KEV and EPSS is low, track vendor advisories and threat intelligence for any change in exploitation status while still remediating high-risk deployments promptly.