CVE-2026-47761

What it actually does

This is a stored cross-site scripting vulnerability in TinyMCE's media plugin before versions 5.11.1, 7.9.3, and 8.5.1. A user who can submit or edit rich-text content can craft media-related HTML using malicious data-mce-* attributes that bypass expected sanitization and are later executed when another user views or edits the saved content. Because the payload is stored, exploitation can recur whenever the affected content is rendered. The impact is primarily browser-side execution in the context of the application using TinyMCE, potentially allowing theft of session tokens or anti-CSRF tokens accessible to JavaScript, unauthorized actions as the victim, content tampering, phishing overlays, or pivoting into administrative workflows.

Why it matters to the business

Applications that allow users to create or edit TinyMCE content with the media plugin enabled may expose other users, moderators, administrators, or customers to malicious scripts embedded in saved content. This can lead to account takeover, unauthorized business actions, fraudulent content changes, data exposure from the affected web application, and loss of trust in user-generated content workflows. Although it is not currently listed in CISA KEV and EPSS is low, the CVSS score is high because exploitation is simple for authenticated content authors and can significantly affect confidentiality and integrity when privileged users view the malicious content.

How an attack unfolds

An attacker first obtains the ability to create or modify rich-text content in an application that uses a vulnerable TinyMCE version with the media plugin enabled. They then insert crafted media markup containing malicious data-mce-* attributes designed to survive storage and sanitization. The application saves the content. Later, a victim such as another user, reviewer, editor, or administrator opens a page or editor view that renders the stored content. TinyMCE or the surrounding application processes the crafted attributes and the attacker's JavaScript executes in the victim's browser under the origin of the vulnerable application. From there, the script may read accessible page data, perform actions using the victim's session, alter content, redirect the user, inject credential prompts, or exfiltrate sensitive values to an attacker-controlled endpoint.

How to fix it

Upgrade TinyMCE to a fixed release: 5.11.1 or later for the 5.x line, 7.9.3 or later for the 7.x line, and 8.5.1 or later for the 8.x line. If TinyMCE is bundled through another application, CMS, framework, or package, update that upstream component to a release that includes the fixed TinyMCE version. If immediate upgrade is not possible, disable the media plugin where it is not required, restrict rich-text editing to trusted users, enforce strict server-side HTML sanitization that removes dangerous data-mce-* attributes and script-capable URL schemes, and deploy a restrictive Content Security Policy to reduce script execution and exfiltration impact. Re-sanitize previously stored rich-text content after patching because stored payloads may remain in existing records or documents.

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 depending on the major version in use. Review package manifests, lockfiles, bundled static assets, browser-loaded JavaScript filenames, and application dependency reports to ensure no vulnerable TinyMCE copy remains. Verify whether the media plugin is enabled in TinyMCE configuration. Test with a safe proof-of-concept payload in a non-production environment to confirm crafted data-mce-* attributes are neutralized, stripped, or rendered inert and do not execute when content is saved and viewed. Search existing stored rich-text content for suspicious data-mce-* attributes, JavaScript URL schemes, event-handler attributes, encoded script tags, or references to unknown external domains. Validate that server-side sanitization and Content Security Policy controls remain effective after the upgrade.

Typical attack path

1. Identify an application using TinyMCE with the media plugin enabled and a vulnerable version before 5.11.1, 7.9.3, or 8.5.1.
2. Authenticate or otherwise gain permission to submit rich-text content, comments, articles, tickets, profiles, messages, or other editable HTML fields.
3. Create media content containing crafted data-mce-* attributes with embedded script behavior or dangerous JavaScript-bearing values.
4. Save or publish the malicious rich-text content so the payload is stored by the application.
5. Wait for another user, moderator, editor, or administrator to view or edit the stored content.
6. Execute JavaScript in the victim's browser in the context of the affected web application.
7. Use the victim's privileges to read sensitive data, perform unauthorized actions, modify content, or exfiltrate browser-accessible tokens or page content.

How to detect it

To determine whether this was already exploited, review both stored content and application access telemetry. Search rich-text content repositories, CMS records, article/comment/message bodies, exported HTML, and moderation queues for unusual data-mce-* attributes combined with script tags, event-handler attributes, javascript: URLs, encoded HTML entities, base64-like blobs, or references to unfamiliar external domains. Examine web access logs, WAF logs, API logs, and audit logs for create/update requests to rich-text fields followed by later administrator or moderator views of the same content. Look for outbound browser callbacks to unfamiliar domains shortly after content-rendering pages are loaded. Correlate suspicious content creation with user accounts that recently registered, have low reputation, changed unusual volumes of content, or edited media/embed fields. In endpoint or browser telemetry, investigate unexpected network connections initiated from pages that render TinyMCE content, credential prompts displayed inside application pages, or user actions performed immediately after viewing suspicious content. Because this is stored XSS, the strongest evidence is a malicious payload persisted in application content plus subsequent victim page views that rendered that content.

• data-mce-
• data-mce-html
• data-mce-object
• data-mce-p-src
• data-mce-src
• javascript:
• javascript
• <script
• </script>
• onerror=
• onload=
• onclick=
• onmouseover=
• fetch(
• XMLHttpRequest
• document.cookie
• localStorage
• sessionStorage
• navigator.sendBeacon
• eval(
• atob(
• new Image().src
• srcdoc=
• <iframe
• <embed
• <object

What your security team should do

• Inventory all applications, CMS platforms, portals, helpdesk systems, knowledge bases, and custom products that embed TinyMCE, including transitive or bundled copies.
• Prioritize upgrades for internet-facing applications, multi-user publishing workflows, administrative review queues, and environments where untrusted or semi-trusted users can submit rich-text content.
• Upgrade to TinyMCE 5.11.1+, 7.9.3+, or 8.5.1+ and verify the effective browser-loaded version, not only the declared package version.
• If upgrade is delayed, disable the media plugin or restrict access to media-enabled rich-text editing until the fix is deployed.
• Harden server-side HTML sanitization to remove unsafe data-mce-* attributes, event handlers, script tags, iframes from untrusted sources, and javascript: or data: URL schemes where not explicitly required.
• Re-scan and re-sanitize historical rich-text content because stored XSS payloads can remain active after the vulnerable component is patched.
• Deploy or tighten Content Security Policy to limit inline script execution and restrict outbound connections to approved domains.
• Review logs and stored content for evidence of suspicious data-mce-* attributes and external callback domains before closing the remediation effort.