CVE-2024-38357

What it actually does

TinyMCE content parsing incorrectly handled specially crafted <noscript> elements, allowing HTML or script content that should remain inert or be sanitized to execute when malicious content is loaded into the editor. The vulnerability is a client-side cross-site scripting issue requiring user interaction: a victim must open or load attacker-controlled content in a page or application using an affected TinyMCE version. Successful exploitation can execute JavaScript in the security context of the hosting application, enabling theft of data accessible to the page, unauthorized actions as the victim, content tampering, and pivoting to other application functionality exposed to the browser session.

Why it matters to the business

Applications that allow users to create, import, preview, moderate, or edit rich-text content with affected TinyMCE versions may expose staff or end users to browser-based compromise. The most likely business consequences are account misuse, unauthorized content changes, leakage of data visible in the application, phishing from a trusted interface, and loss of confidence in collaborative or content-management workflows. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so urgency is moderate; however, any internet-facing application that processes untrusted rich text should still prioritize remediation because stored XSS can affect privileged reviewers or administrators.

How an attack unfolds

An attacker prepares rich-text or HTML content containing a malformed or specially crafted <noscript> element with embedded malicious code. The attacker then gets that content into a workflow that uses TinyMCE, such as posting it, importing it, sending it for review, loading it from saved content, or convincing a user to paste/open it. When a victim opens the affected editor or preview path, TinyMCE parses the content incorrectly and the malicious code executes in the victim’s browser under the origin of the vulnerable application. From there, the script can read page data available to the browser, capture anti-CSRF tokens or non-HttpOnly session-related values, perform actions as the victim, alter submitted content, or redirect the victim to a phishing or malware-delivery page.

How to fix it

Upgrade TinyMCE to a patched release: TinyMCE 7.2.0 or later, TinyMCE 6.8.4 or later, or TinyMCE 5.11.0 LTS or later. For source-based deployments of tinymce/tinymce, ensure the code includes commit 8a7b799033af4058818ea17e27ad36c58e2402f9 or a later trusted revision. There are no vendor-provided workarounds. After upgrading, rebuild and redeploy frontend bundles, clear CDN and browser caches where applicable, and verify that no older bundled TinyMCE assets remain reachable. As defense in depth, sanitize untrusted HTML server-side before storage and rendering, restrict allowed HTML elements and attributes, enforce a strong Content Security Policy that limits inline script execution, mark session cookies HttpOnly and Secure, and avoid granting rich-text editing privileges to untrusted users unless required.

How to confirm the fix worked

Confirm the deployed TinyMCE version is 7.2.0 or later, 6.8.4 or later, or 5.11.0 LTS or later, depending on the major release line in use. Check package manifests, lockfiles, built JavaScript assets, CDN URLs, software composition analysis output, and runtime application pages for references to older TinyMCE versions. If using source builds, confirm commit 8a7b799033af4058818ea17e27ad36c58e2402f9 or a later commit is present. Test representative editor workflows with benign proof-of-concept content containing <noscript> and script-like markup to ensure it is parsed or sanitized safely and does not execute. Validate that caches and static asset stores no longer serve vulnerable tinymce.min.js or related TinyMCE bundles.

Typical attack path

1. Identify an application or workflow that uses an affected TinyMCE version and accepts untrusted rich-text or HTML content.
2. Craft content containing a specially formed <noscript> element designed to survive parsing and trigger script execution when loaded into TinyMCE.
3. Submit, import, store, or deliver the malicious content through a comment, message, CMS entry, document, support ticket, moderation queue, or paste/open workflow.
4. Wait for a victim, ideally a privileged editor, moderator, or administrator, to load the content in the TinyMCE editor.
5. Execute JavaScript in the victim’s browser within the vulnerable application’s origin.
6. Use the victim’s session and page privileges to read accessible data, modify content, issue application requests, or stage additional browser-based attacks.

How to detect it

To assess prior exploitation, review all places where rich-text or HTML content is accepted, stored, imported, moderated, or rendered through TinyMCE. Search application logs, API gateway logs, WAF events, content submission records, moderation queues, audit logs, and database-backed content exports for <noscript> elements combined with executable patterns such as <script>, event-handler attributes, javascript: URLs, encoded script tags, iframe/object/embed tags, or suspicious redirects. Correlate suspicious submissions with subsequent access by privileged users and look for abnormal browser-originated requests immediately after they viewed or edited the content, such as unexpected profile changes, content publishing, administrative actions, token-bearing POST requests, or outbound redirects. Browser-side telemetry, CSP violation reports, EDR web history, and reverse proxy logs may show blocked or successful calls to attacker-controlled domains. Because this is client-side XSS, server compromise artifacts are not expected unless the executed script abused application functionality to upload files, alter settings, or create persistence within application content.

• <noscript
• </noscript>
• <noscript><script
• <noscript>&lt;script
• <noscript%3e
• %3Cnoscript
• noscript%3E%3Cscript
• <noscript><img
• <noscript>&lt;img
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• data:text/html
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• window.location
• location.href
• <iframe
• <object
• <embed
• tinymce.min.js
• tinymce.js
• 8a7b799033af4058818ea17e27ad36c58e2402f9

What your security team should do

• Inventory applications, CMS platforms, admin portals, and user-generated-content workflows that embed TinyMCE, including bundled and transitive copies.
• Upgrade affected deployments to TinyMCE 7.2.0+, 6.8.4+, or 5.11.0 LTS+ and redeploy rebuilt frontend assets.
• Prioritize systems where untrusted users can submit rich text that is later opened by privileged users such as administrators, moderators, support staff, or content editors.
• Search stored rich-text repositories and recent submissions for suspicious <noscript> content and script-like attributes before and after patching.
• Review web application logs, WAF logs, and content moderation queues for attempts to submit <noscript> payloads containing event handlers, script tags, encoded JavaScript, or redirects.
• Add or tighten server-side HTML sanitization and Content Security Policy controls to reduce the impact of future editor parsing flaws.
• Ensure session cookies are HttpOnly and SameSite where feasible to limit token theft and cross-site request abuse from browser-based attacks.
• Monitor privileged account activity for unusual content changes, administrative actions, or requests following interaction with suspicious rich-text content.