CVE-2024-34341

What it actually does

Trix versions prior to 2.1.1 improperly sanitize HTML and markup introduced through copy-and-paste operations into the rich text editor. An attacker can craft web content or a document containing executable markup, event handlers, script URLs, or other unsafe HTML that survives the paste sanitization path and is rendered by the application. When a user pastes that content into a vulnerable Trix editor, the payload can execute JavaScript in the security context of the hosting web application, enabling cross-site scripting impacts such as reading accessible page data, modifying editor content, issuing same-origin requests, or abusing the user’s active session privileges within the application.

Why it matters to the business

Applications embedding vulnerable Trix versions may allow malicious content copied from websites, emails, documents, or shared notes to execute in a user’s browser after paste. The likely operational impact is targeted compromise of application users, unauthorized actions performed through a victim’s session, exposure or tampering of user-visible data, and loss of trust in collaboration or content-editing workflows. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the flaw has been public since May 2024 and should be treated as a hygiene issue for any internet-facing or collaboration-heavy application using Trix.

How an attack unfolds

An attacker prepares content containing malicious HTML or JavaScript-bearing markup and places it somewhere a victim is likely to copy from, such as a webpage, document, ticket, chat message, email, or knowledge-base article. The victim copies that content and pastes it into an application field powered by a vulnerable Trix editor. Because the affected Trix paste handling does not adequately sanitize the markup before insertion, dangerous attributes or elements can remain in the editor’s DOM. The browser then interprets the inserted markup and executes the attacker-controlled script in the context of the application using Trix. From there, the attacker’s script can interact with the page as the victim, read non-HttpOnly data available to JavaScript, alter submitted content, make same-origin requests, or stage further social-engineering actions. Exploitation requires user interaction but does not require attacker authentication if the attacker can induce a user to paste crafted content into a vulnerable editor.

How to fix it

Upgrade Trix to version 2.1.1 or later. For source-based deployments using basecamp/trix, ensure the dependency includes the fixing commit 0c79bcb854b8e8ee23e7bec571fe9d8dbfab9e5e or a later release/tag that contains it. Rebuild and redeploy all frontend bundles that vendor or package Trix, since merely updating a lockfile is insufficient if older compiled assets remain served. As defense in depth, enforce strict server-side sanitization of rich-text HTML before storage or rendering, apply a restrictive Content Security Policy that avoids unsafe-inline script execution, encode untrusted content on output, and review any custom Trix attachments, paste handlers, serializers, or sanitization overrides that could reintroduce unsafe markup.

How to confirm the fix worked

Confirm exposure by inventorying frontend dependencies and deployed static assets for Trix versions older than 2.1.1. Check package manifests, lockfiles, vendored JavaScript, source maps, and built bundles for the Trix version or the vulnerable paste-handling code path. Validate remediation by verifying that deployed assets reference Trix 2.1.1 or later, or include commit 0c79bcb854b8e8ee23e7bec571fe9d8dbfab9e5e or later. Perform a safe regression test by pasting benign proof-of-concept markup containing non-executing event-handler probes into every Trix-powered editor and confirming that unsafe tags, event attributes, javascript: URLs, and script-capable SVG/HTML constructs are removed or neutralized before rendering and before persistence. Also verify that server-side sanitization rejects or strips equivalent unsafe markup even if submitted directly to the application API.

Typical attack path

1. Identify an application that embeds Trix prior to version 2.1.1.
2. Craft HTML or rich-text content containing script-capable markup that can survive the vulnerable paste sanitization path.
3. Host or deliver the crafted content through a website, document, email, chat, ticket, or other source likely to be copied by a target user.
4. Convince the target user to copy the crafted content and paste it into the vulnerable Trix editor.
5. The malicious markup is inserted into the editor and executed by the browser in the application’s origin.
6. Use the victim’s browser context to read accessible data, modify content, perform same-origin requests, or trigger unauthorized user actions.

How to detect it

Investigate whether the issue was already exploited by reviewing application data stores, request logs, WAF alerts, browser security reports, and content-audit logs for rich-text submissions containing script-capable HTML around the period vulnerable Trix versions were deployed. Focus on fields and endpoints that accept Trix-generated rich text, especially create/update actions followed by victims viewing or editing the affected content. Look for pasted or stored HTML containing script tags, inline event handlers, javascript: URLs, SVG-based payloads, encoded script fragments, iframes, object/embed tags, data:text/html URLs, and unexpected external domains referenced from user-generated content. Correlate suspicious content submissions with subsequent unusual same-origin requests, account setting changes, content edits, privilege-sensitive actions, or CSP violation reports from other users’ browsers. If Content Security Policy reporting is enabled, search reports for blocked inline scripts, blocked event handlers, blocked javascript: navigation, or script loads triggered from pages containing Trix editors. Because exploitation is user-interaction driven and may execute only in the browser, absence of server-side errors does not rule out exploitation; stored content review and CSP/browser telemetry are the highest-value sources.

• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• <svg
• </svg>
• xlink:href=
• <iframe
• </iframe>
• <object
• </object>
• <embed
• </embed>
• data:text/html
• data:image/svg+xml
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• new Function(
• atob(
• String.fromCharCode
• <trix-editor
• trix-before-paste
• trix-paste
• trix-change

What your security team should do

• Prioritize upgrading all applications using Trix prior to 2.1.1, especially externally accessible applications, collaboration tools, admin interfaces, and workflows where users paste content from untrusted sources.
• Search software composition analysis, package lockfiles, SBOMs, and built frontend artifacts for basecamp/trix or trix versions older than 2.1.1.
• After upgrading, purge CDN, reverse-proxy, browser-cache, and static-asset caches so vulnerable JavaScript bundles are no longer served.
• Review stored rich-text content created while vulnerable versions were deployed for suspicious HTML, event handlers, script URLs, SVG payloads, encoded script fragments, and unexpected external references.
• Add or tighten Content Security Policy controls to reduce XSS exploitability, preferably using nonces or hashes and avoiding unsafe-inline and broad script-src allowlists.
• Ensure rich-text content is sanitized server-side on input or output, not only in the browser editor.
• Monitor application logs, WAF events, and content repositories for attempts to store or submit script-like markup through rich-text fields.
• Educate support and operations users not to paste rich content from untrusted webpages or documents into administrative editors until remediation is complete.