CVE-2026-47759

What it actually does

This is a stored cross-site scripting vulnerability in TinyMCE caused by improper sanitization of internal data-mce-* attributes, specifically data-mce-href, data-mce-src, and data-mce-style. An authenticated or content-authoring attacker can save crafted HTML containing malicious data-mce-* values that later override otherwise safe attributes during TinyMCE serialization. When another user views or edits the stored content, the browser may execute attacker-controlled script in the context of the affected application. Because execution occurs in the victim user’s browser session, impact can include session theft, unauthorized actions as the victim, content manipulation, credential or token exposure, and abuse of application trust boundaries.

Why it matters to the business

Applications embedding vulnerable TinyMCE versions may allow malicious content to persist and execute against other users, including administrators or privileged content reviewers. This can lead to account takeover, unauthorized changes, data exposure, reputational harm, and loss of trust in user-generated or editor-managed content. The issue has a high CVSS score of 8.7 because exploitation is network-accessible, low complexity, and can significantly affect confidentiality and integrity, although it requires attacker privileges to create or edit content and user interaction by a victim. EPSS is currently low and it is not listed in CISA KEV, so broad active exploitation is not indicated, but remediation should still be prioritized for public-facing or multi-user systems using TinyMCE.

How an attack unfolds

An attacker first obtains access to a feature that allows them to create or edit rich-text content using TinyMCE, such as a CMS page, comment, profile field, knowledge-base article, email template, or administrative content block. They insert HTML containing crafted data-mce-href, data-mce-src, or data-mce-style attributes with malicious values designed to survive validation. During TinyMCE processing or serialization, the malicious data-mce-* value can override a sanitized attribute such as href, src, or style. The payload is then stored by the application. When a victim later opens, previews, reviews, edits, or renders the affected content, the browser interprets the attacker-controlled value and executes script or navigates to attacker-controlled content in the trusted application origin. If the victim is privileged, the attacker may use the execution context to perform unauthorized actions, steal session tokens or CSRF-protected data available to JavaScript, alter content, or pivot further within the application.

How to fix it

Upgrade TinyMCE to a fixed version: 5.11.1 or later for the 5.x branch, 7.9.3 or later for the 7.x branch, or 8.5.1 or later for the 8.x branch. If TinyMCE is bundled through a CMS, web framework, plugin, theme, vendor appliance, or package manager dependency, update the parent package or bundle that supplies TinyMCE and verify the embedded TinyMCE asset version actually changed. Where immediate upgrade is not possible, apply compensating controls: restrict who can create or edit rich-text content, disable or tightly sanitize HTML input, strip data-mce-href, data-mce-src, and data-mce-style attributes from stored and incoming content, enforce a strong Content Security Policy that blocks inline script and untrusted script sources, and review stored content for suspicious data-mce-* attributes. Because stored payloads can remain after patching, sanitize or re-save existing rich-text content after upgrading where feasible.

How to confirm the fix worked

Confirm all deployed TinyMCE assets report a fixed version: 5.11.1 or later, 7.9.3 or later, or 8.5.1 or later. Check package lockfiles, bundled static assets, CMS/plugin versions, and browser-served JavaScript files rather than relying only on top-level application dependencies. Search deployed assets for TinyMCE version banners or package metadata such as tinymce.min.js, package.json, yarn.lock, package-lock.json, pnpm-lock.yaml, composer.lock, or vendor bundle manifests. Validate that stored content containing data-mce-href, data-mce-src, or data-mce-style cannot override safe href, src, or style attributes after serialization. Confirm that existing content repositories have been scanned and cleaned of suspicious data-mce-* attributes. If a web application firewall or input sanitizer is used as mitigation, test that it strips or neutralizes the affected attributes without breaking legitimate editor behavior.

Typical attack path

1. Identify an application feature that embeds a vulnerable TinyMCE version and allows stored rich-text input.
2. Authenticate or otherwise gain permission to create or modify content rendered through the editor.
3. Submit crafted HTML using data-mce-href, data-mce-src, or data-mce-style attributes containing a JavaScript-capable or otherwise unsafe payload.
4. Rely on TinyMCE serialization to allow the data-mce-* value to override a sanitized attribute and persist the malicious content.
5. Wait for a victim, reviewer, administrator, or other user to open, preview, edit, or view the stored content.
6. Execute attacker-controlled JavaScript or unsafe browser behavior in the victim’s session.
7. Use the victim’s application privileges to steal sensitive data, perform unauthorized actions, modify content, or establish further persistence.

How to detect it

To determine whether exploitation already occurred, review application audit logs and content revision history for recently created or modified rich-text records containing data-mce-href, data-mce-src, or data-mce-style attributes. Pay particular attention to content edited by low-privileged users and later viewed, previewed, moderated, or edited by administrators or support staff. Search web access logs for requests to suspicious external domains immediately after users viewed affected content, and correlate with application events such as content creation, update, preview, publish, or admin review. Inspect stored HTML in databases, CMS exports, object storage, and content caches for unsafe data-mce-* attributes containing javascript:, data:, vbscript:, encoded equivalents, style-based execution attempts, unusual URL schemes, or references to unknown external hosts. Browser-side evidence may appear as unexpected outbound requests, CSP violation reports, JavaScript errors, or anomalous same-origin API calls made shortly after a victim accessed attacker-controlled content. Because no public exploit indicators or named threat actors are provided, detection should focus on payload patterns and suspicious content lifecycle activity rather than fixed malware signatures.

• data-mce-href="javascript:
• data-mce-href='javascript:
• data-mce-href="data:
• data-mce-href='data:
• data-mce-href="vbscript:
• data-mce-href='vbscript:
• data-mce-src="javascript:
• data-mce-src='javascript:
• data-mce-src="data:
• data-mce-src='data:
• data-mce-style="
• data-mce-style='
• data-mce-href="javascript
• data-mce-href="javascript:
• data-mce-href="javascript:
• data-mce-href="jav%61script:
• data-mce-href="%6a%61%76%61%73%63%72%69%70%74:
• data-mce-src="javascript
• data-mce-src="%6a%61%76%61%73%63%72%69%70%74:
• data-mce-style="background-image:url(javascript:
• data-mce-style='background-image:url(javascript:
• data-mce-style="expression(
• data-mce-style='expression(
• data-mce-style="-moz-binding
• data-mce-style='-moz-binding
• onerror=
• onload=
• <script
• </script>
• tinymce.min.js

What your security team should do

• Inventory applications, CMS platforms, plugins, themes, and vendor packages that embed TinyMCE, including transitive or bundled JavaScript assets.
• Prioritize upgrades for internet-facing, multi-user, administrator-facing, CMS, support portal, documentation, and collaboration systems where untrusted users can submit rich text.
• Upgrade to TinyMCE 5.11.1+, 7.9.3+, or 8.5.1+ according to the deployed major version branch.
• Scan stored rich-text content for data-mce-href, data-mce-src, and data-mce-style attributes, especially values containing script-like schemes, event handlers, encoded payloads, or references to unfamiliar domains.
• Temporarily restrict rich-text authoring privileges or require moderation until affected systems are upgraded and existing content is reviewed.
• Enforce or strengthen Content Security Policy to reduce impact from stored XSS, especially by blocking inline script and limiting script-src to trusted origins.
• Review access logs, application audit logs, and content history for suspicious edits followed by administrator or reviewer access to the same content.
• Add regression tests to ensure data-mce-* attributes cannot override sanitized href, src, or style values during editor serialization.
• Monitor TinyMCE and downstream application advisories because many products bundle the editor and may require separate vendor updates.