A high-severity stored Cross-Site Scripting (XSS) flaw in TinyMCE, tracked as CVE-2026-47762, enables attackers with low-privilege editor access to forge protected comments, bypass the sanitizer, and silently execute malicious scripts in administrator browsers, putting millions of websites at immediate risk.
TinyMCE, one of the most widely deployed open-source rich-text editors on the internet, disclosed a dangerous stored XSS vulnerability on May 28, 2026, assigned CVE-2026-47762 with a CVSS v3.1 score of 8.7 (High).
The vulnerability, published via GitHub Security Advisory GHSA-v98h-vmpc-fpqv, was identified by security researcher Ivan Babenko (he1d3n) and publicly reported by MitchC1999. It is one of four simultaneous stored XSS flaws (CVE-2026-47759 through CVE-2026-47762) that TinyMCE patched together in a single coordinated disclosure.
The CVE carries the following CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, reflecting network-accessible exploitation with low privilege requirements, high impact on both confidentiality and integrity, and a changed scope.
TinyMCE uses a special internal mechanism to temporarily shelter sensitive HTML constructs such as raw script tags or server-side template directives inside HTML comments formatted as <!--mce:protected ...-->.
This “protected comment” system was designed to preserve developer-defined patterns during the editor’s save-and-restore cycle without corrupting them.
The vulnerability lies in what happens when that content is restored. Before the patch, TinyMCE did not validate whether a decoded mce:protected comment actually matched any of the configured protect regex rules before reinserting it into the DOM.
An attacker with a low-privilege CMS account, a WordPress Contributor, a junior content editor, or a freelance reporter could craft a forged <!–mce:protected–> comment that masquerades as a legitimate protected block.
Then, when an administrator opens the saved draft to preview or approve it, the main JavaScript executes silently in the administrator’s browser session.
This is a stored XSS attack, not a reflected one, meaning the payload persists in the database and automatically triggers the moment any privileged user views the content, requiring no additional action from the attacker.
Affected Versions
The vulnerability spans multiple TinyMCE generations across npm, NuGet, and Composer package ecosystems:
| Branch | Affected Versions | Patched Version |
|---|---|---|
| TinyMCE 5.x | < 5.11.1 | 5.11.1 (LTS only) |
| TinyMCE 6.x | 6.0.0 – 6.8.6 (entire branch) | No patch (EOL) |
| TinyMCE 7.x | 7.0.0 – 7.9.2 | 7.9.3 |
| TinyMCE 8.x | 8.0.0 – 8.5.0 | 8.5.1 |
Critically, the entire TinyMCE 6.x branch is affected with no available patch, as version 6 has reached end-of-life. Organizations running TinyMCE 6.x must migrate to the 7.x or 8.x branch immediately.
The practical exploitation path is alarming in its simplicity:
- Initial Access — Attacker registers or compromises a low-privilege CMS account (Contributor, Editor, or Support role)
- Payload Injection — Attacker crafts and saves a post or draft containing a forged
<!--mce:protected-->comment embedding malicious JavaScript - Trigger — A site administrator opens the draft for review, approval, or preview
- Session Hijack — The script executes in the admin’s browser, stealing session cookies, JWT tokens, or CSRF tokens
- Full CMS Compromise — Using the stolen credentials, the attacker gains admin-level access, enabling content manipulation, user database exfiltration, and, on CMS platforms like WordPress, arbitrary PHP execution via plugin or theme upload.
This attack vector has direct monetization for initial access brokers, ransomware precursors, and industrial espionage actors who specifically target CMS administrator sessions rather than seeking host-level root access.
TinyMCE’s ubiquity significantly amplifies the severity of this disclosure. The editor is embedded across WordPress (powering ~42% of all websites globally), Joomla, Drupal, Umbraco, Shopify, HubSpot, Statamic, and thousands of custom CMS and SaaS admin dashboards.
Any platform that uses TinyMCE with the protect option, which enables low-privilege users to save rich-text content directly in scope for CVE-2026-47762.
Mitigation
Tiny (the company behind TinyMCE) addressed the vulnerability by adding validation of decoded mce:protected content against the configured protect regex rules before the content is restored into the DOM. There is no official workaround available, making patching the only viable mitigation.
Priority remediation actions:
- Upgrade to TinyMCE 8.5.1 for all 8.x deployments (released May 20, 2026)
- Upgrade to TinyMCE 7.9.3 for all 7.x deployments
- Upgrade to TinyMCE 5.11.1 LTS for 5.x deployments under an active commercial LTS contract
- Migrate off TinyMCE 6.x entirely; no security patch exists for this branch
- Audit editor-role accounts and revoke access for former contractors or inactive contributors
- Implement a strict Content Security Policy (CSP) with
script-src 'self'to absorb potential XSS landings even post-exploitation - Scan existing content databases for posts containing
<!--mce:protectedstrings that may already carry stored payloads
For organizations running TinyMCE via CMS plugins or commercial themes, verify that bundled TinyMCE versions inside those plugins have also been updated. Plugin vendors may ship their own embedded copies of TinyMCE independently of the core package.
FAQ
Q1: What is CVE-2026-47762 in TinyMCE?
It is a high-severity stored XSS vulnerability (CVSS 8.7) that allows attackers to forge mce:protected HTML comments to bypass sanitization and execute malicious scripts in the browser of any privileged user who views the content.
Q2: Which TinyMCE versions are affected by this XSS vulnerability?
All versions before 5.11.1, the entire 6.x branch (6.0.0–6.8.6), versions 7.0.0–7.9.2, and versions 8.0.0–8.5.0 across npm, NuGet, and Composer packages are affected.
Q3: Is there a workaround available if patching is not immediately possible?
No official workaround exists; patching to TinyMCE 8.5.1, 7.9.3, or 5.11.1 LTS is the only fix, though hardening your CSP and restricting editor-role access can reduce exposure in the interim.
Q4: Does this vulnerability affect WordPress sites?
Yes, WordPress bundles TinyMCE in its classic editor, meaning WordPress sites that use vulnerable TinyMCE versions and low-privilege contributor accounts are directly susceptible to admin session hijacking.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
