CVE-2024-38356

What it actually does

This is a cross-site scripting vulnerability in TinyMCE’s content extraction logic when the `noneditable_regexp` option is enabled. Specially crafted HTML attributes can bypass the intended validation path and be added back into extracted editor content, allowing attacker-controlled script or event-handler code to execute in a victim’s browser when the affected content is processed or viewed. The issue is remotely reachable through application features that accept, store, render, import, preview, or otherwise process TinyMCE-authored HTML. Exploitation requires user interaction, such as a user viewing or extracting malicious editor content, and primarily affects browser-side confidentiality and integrity rather than server availability.

Why it matters to the business

Applications that embed vulnerable TinyMCE versions may allow malicious content to run in users’ browsers, which can lead to session theft, unauthorized actions performed as the victim, content tampering, phishing inside trusted application pages, or exposure of sensitive page data. The risk is highest for products that allow untrusted or semi-trusted users to submit rich text content that is later viewed by administrators, support staff, customers, or other users. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it has been public since June 2024, so internet-facing or multi-user content workflows should be upgraded as part of normal patch governance.

How an attack unfolds

An attacker first identifies an application that uses TinyMCE with the `noneditable_regexp` configuration option enabled and accepts attacker-controlled rich text or imported HTML. The attacker submits content containing specially crafted HTML attributes designed to satisfy or confuse the non-editable content handling logic while preserving executable JavaScript, such as event handlers or scriptable URL values. When the application later extracts content from the editor and renders, previews, stores, or redisplays it, the vulnerable TinyMCE code may include unsafe attribute content without properly verifying it against the configured regular expression. A victim then opens the affected page or interacts with the crafted content, causing the browser to execute the attacker’s code in the security context of the trusted application. The attacker can then read accessible page data, steal anti-CSRF tokens or session-adjacent data if exposed to JavaScript, perform actions as the victim, alter displayed content, or pivot to phishing workflows within the application.

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, ensure the code includes the upstream fix commit `8a7b799033af4058818ea17e27ad36c58e2402f9`. There are no vendor-provided workarounds for the vulnerable behavior, so patching is the primary remediation. After upgrading, rebuild and redeploy frontend bundles, clear CDN and browser caches where applicable, and verify that applications are not still serving older bundled TinyMCE assets. As defense in depth, enforce strict output encoding and HTML sanitization on server-side rendering paths, restrict allowed HTML attributes and URL schemes, avoid allowing untrusted users to submit raw HTML, and deploy a Content Security Policy that limits inline script execution where feasible.

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 branch in use. For source builds, confirm the application dependency or vendored source includes commit `8a7b799033af4058818ea17e27ad36c58e2402f9` or an equivalent later patch. Inspect package lockfiles, bundled JavaScript assets, SBOMs, and browser-loaded static files to ensure no vulnerable TinyMCE copy remains in production. Search application code and configuration for `noneditable_regexp`; systems not using this option are less exposed to this specific flaw but should still update. Perform regression testing with benign XSS test payloads in HTML attributes to confirm extracted content does not preserve executable attributes or scriptable URL values. Validate that CDN caches, static asset fingerprints, and application containers have been refreshed so users receive the patched editor code.

Typical attack path

1. Find an application or product that embeds TinyMCE and uses the `noneditable_regexp` option.
2. Locate a rich text input, import, preview, template, comment, message, CMS, knowledge base, or administrative content workflow that accepts HTML from an attacker-controlled account or unauthenticated user.
3. Create malicious HTML containing crafted attributes that survive TinyMCE content extraction and include executable browser-side code.
4. Submit or store the crafted content in the application.
5. Wait for a victim, moderator, administrator, or another user to view, preview, edit, or otherwise process the malicious content.
6. Trigger JavaScript execution in the victim’s browser under the trusted application origin.
7. Use the executed script to access page data, perform unauthorized actions as the victim, alter content, or deliver further phishing/social-engineering payloads.

How to detect it

To determine whether this was already exploited, focus on content-ingestion and rendering workflows rather than server process crashes. Review application logs, WAF logs, API request bodies, content moderation queues, CMS audit trails, rich text database exports, object storage uploads, and web access logs for submitted HTML containing suspicious attributes or encoded JavaScript around rich text fields. Pay particular attention to content created by low-privilege or newly created accounts that was later viewed by administrators or moderators. Search for use of TinyMCE workflows configured with `noneditable_regexp`, then inspect stored content passing through those workflows for event-handler attributes, `javascript:` URLs, SVG/MathML payloads, encoded script fragments, or unexpected non-editable markup. Correlate suspicious content views with downstream account activity such as profile changes, new API tokens, password or email changes, privilege changes, administrative actions, or unusual requests made from the victim’s browser shortly after viewing the content. Browser-side XSS often leaves limited endpoint evidence, so network telemetry and application audit logs are usually more useful than host process artifacts. If a CSP is deployed, review CSP violation reports for blocked inline scripts, script-src violations, or unexpected outbound destinations associated with pages that render TinyMCE content.

• noneditable_regexp
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• javascript:
• data:text/html
• <script
• </script>
• <svg
• <math
• srcdoc=
• xlink:href=
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• String.fromCharCode
• &#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;
• %6a%61%76%61%73%63%72%69%70%74
• 8a7b799033af4058818ea17e27ad36c58e2402f9

What your security team should do

• Inventory all applications, plugins, CMS components, internal tools, and third-party products that bundle or load TinyMCE, including vendored JavaScript and CDN-hosted copies.
• Prioritize patching deployments that allow untrusted users to create or modify rich text content viewed by privileged users, moderators, administrators, support teams, or customers.
• Upgrade to TinyMCE 7.2.0+, 6.8.4+, or 5.11.0 LTS+ and verify source deployments include commit `8a7b799033af4058818ea17e27ad36c58e2402f9`.
• Search codebases and configuration for `noneditable_regexp` to identify applications specifically exercising the vulnerable functionality.
• Review stored rich text content created before patching for suspicious HTML attributes, event handlers, scriptable URLs, encoded JavaScript, or unexpected non-editable markup.
• Add or tighten server-side HTML sanitization for rich text fields rather than relying solely on client-side editor behavior.
• Deploy or review Content Security Policy controls to reduce the impact of successful XSS, especially restrictions on inline scripts, external script sources, and form submission destinations.
• Monitor web, WAF, application, and audit logs for suspicious rich text submissions and for users accessing content shortly before unusual account actions.
• Treat confirmed exploitation as a browser-session compromise event: invalidate affected sessions, rotate exposed tokens, and review actions performed by impacted users.