CVE-2024-29203: Client-Side Cross-Site Scripting via Unsandboxed Iframes and Legacy Embed Elements in TinyMCE

TinyMCE is an open-source, web-based rich text editor widely integrated into content management systems, email clients, and collaboration platforms. To allow users to draft formatted text, media, and other embedded visual objects, the editor processes complex HTML documents through an internal parsing subsystem. This ingestion layer relies on a DOM parser to filter input markup, ensuring it conforms to configured schema specifications and security constraints.\n\nThe primary attack surface resides within elements that permit content embedding, specifically <iframe>, <object>, and <embed> nodes. Historically, these tags were accepted as long as they met the standard dimension and structure constraints defined in the schema. This design did not restrict nested capabilities or isolate the embedded frames from the execution scope of the primary application.\n\nUnder default configurations in versions prior to 6.8.1, the editor did not apply restrictive isolation attributes such as sandbox to <iframe> elements. This programmatic gap allowed attackers to introduce scripting elements that could execute within the DOM tree of the parent web application, compromising client-side security controls.

The core of the vulnerability lies in the parser's passive processing of embedded document nodes. When TinyMCE parses imported markup (via paste actions or programmatically through APIs like setContent()), the DomParser validates elements against an allowed-list schema. If the schema permitted iframes, the parser constructed the DOM node without inspecting or rewriting its security-sensitive attributes.\n\nUnsandboxed iframes represent a severe risk in browser environments. If an iframe points to an external source or defines inline script using schemes like javascript: or data:text/html, the browser executes the script in the origin context of the parent frame unless restricted. This allows direct programmatic read-and-write access to cookie jars, session tokens, and document structures of the host application.\n\nFurthermore, the parser accepted legacy <object> and <embed> tags. These legacy elements were designed to launch binary browser extensions (including Java, Adobe Flash, and various PDF viewers). In modern browsers, these elements can execute complex interactions or force the browser to process parameter arrays that trigger unauthorized behaviors, bypassing standard script restrictions.\n\nThe failure to automatically sanitize these elements or transform them into safe alternatives meant that malicious actors could manipulate the active editor environment. Because these settings defaulted to unmitigated states in all versions of TinyMCE 6.x, users hosting default instances were left exposed.

The patch with commit ID bcdea2ad14e3c2cea40743fb48c63bba067ae6d1 mitigates these risks by adding configuration-controlled filters. These filters are defined within the ParserFilters.ts and Options.ts modules. Two core configurations were introduced: sandbox_iframes and convert_unsafe_embeds.\n\nThe options registration assigns a boolean validation processor to both configurations, ensuring that administrators can explicitly manage parsing policies. In version 6.8.1, these default to false for backwards compatibility. In version 7.0.0, the default for sandbox_iframes was updated to true to ensure out-of-the-box protection.\n\nThe core processing logic added to ParserFilters.ts utilizes the addNodeFilter API. When parsing runs, nodes matching object or embed are captured and routed through a transformation filter. This filter converts the legacy tags into safe semantic counterparts (<img>, <video>, <audio>), or sandboxed <iframe> tags if the MIME type cannot be matched safely:\n\ntypescript\n// Pre-patch: Object and embed tags parsed directly without validation or type conversion\n// Post-patch: Nodes are dynamically transformed into safe HTML counterparts\nif (settings.convert_unsafe_embeds) {\n parser.addNodeFilter('object,embed', (nodes) => Arr.each(nodes, (node) => {\n node.replace(\n createSafeEmbed(\n node.attr('type'),\n node.name === 'object' ? node.attr('data') : node.attr('src'),\n node.attr('width'),\n node.attr('height'),\n settings.sandbox_iframes\n ));\n }));\n}\n\n\nSimilarly, if sandbox_iframes is enabled, any iframe node is parsed, and the parser forcibly appends the sandbox="" attribute. This is done via:\n\ntypescript\nif (settings.sandbox_iframes) {\n parser.addNodeFilter('iframe', (nodes) => Arr.each(nodes, (node) => node.attr('sandbox', '')));\n}\n\n\nThe integration of the sandbox="" attribute restricts the frame's execution contexts. Even if the source points to a script or a data URI, the browser blocks form submissions, script execution, popups, and forces a unique origin constraint. This successfully stops execution of client-side payloads.

To execute this attack, a malicious actor must deliver a payload into the editor interface. This is typically achieved via clipboard paste operations or through data sources processed by the host application. A targeted user needs to interact with the editor, such as viewing a document that renders the input content.\n\nConsider a scenario where the application accepts markdown or pasted HTML. An attacker can construct a payload containing a script within an iframe:\n\nhtml\n<iframe src="javascript:alert(parent.document.cookie)"></iframe>\n\n\nOr they can utilize a data URI scheme inside an iframe, which runs active script content:\n\nhtml\n<iframe src="data:text/html,<script>alert(1)</script>"></iframe>\n\n\nAdditionally, legacy <object> and <embed> tags can be targeted to bypass basic string-filtering web application firewalls (WAFs):\n\nhtml\n<object data="javascript:alert(document.domain)"></object>\n\n\nWhen pasted, the browser or the editor's copy-paste handler processes the clipboard content. TinyMCE's parser parses the tags and appends them to the active editor workspace. Because the sandbox and conversion controls are absent, the browser processes the new elements and evaluates the JavaScript, executing the payload in the context of the user's active session.

The most effective resolution is upgrading the TinyMCE library to at least version 6.8.1. However, because version 6.x defaults the defensive options to false, the patch will remain inactive unless administrators explicitly declare the settings in their application code.\n\nTo configure the defenses in a 6.x deployment, developers must set sandbox_iframes and convert_unsafe_embeds to true during the initialization phase:\n\njavascript\ntinymce.init({\n selector: 'textarea#editor',\n sandbox_iframes: true,\n convert_unsafe_embeds: true\n});\n\n\nUpgrading to version 7.x is recommended for long-term security. TinyMCE 7.0.0 secures the editor out of the box by setting sandbox_iframes to true by default, eliminating the risk of misconfiguration.\n\nFor verification, security teams can test the active instance by executing tinymce.activeEditor.getContent() after inserting a standard <iframe> or <object>. If the mitigation is functioning, the retrieved content must contain the sandbox="" attribute on all iframe tags, and legacy tags should be converted to safe semantic elements.