Trix Editor CVE-2026-73428

Three sequential conditions must be met: (1) the attacker must hold an authenticated low-privilege session with write access to a Trix-powered editor input field (PR:L per CVSS vector - a standard user account is sufficient, no admin role required); (2) the attacker must paste crafted HTML containing a <span data-trix-attachment="{}"> element with a data-trix-attributes payload embedding a javascript: URI as the href value; and (3) a separate victim user must view the rendered output and actively click the injected link (UI:R). Applications applying server-side HTML sanitization on save are protected at the persistence layer regardless of whether they have patched. Single-user deployments have no viable stored XSS attack surface. Exploitation is therefore limited to multi-user applications where untrusted Trix content from one user is rendered in another user's browser session.

The vendor-assigned CVSS 4.6 (Medium) accurately reflects the threat profile: network-reachable (AV:N), low complexity (AC:L), authenticated low-privilege attacker (PR:L), mandatory victim interaction (UI:R), unchanged scope (S:U), and limited confidentiality and integrity impact (C:L/I:L/A:N). The two sequential user-interaction dependencies - attacker must paste crafted content, victim must click the rendered link - meaningfully suppress real-world exploitation likelihood compared to fully automated or click-free XSS variants. No EPSS data was provided in the intelligence sources, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. The primary attack surface is multi-user collaborative applications built on Trix (Rails Action Text being the most prevalent deployment), where attacker-generated rich text is displayed to other users; single-user deployments have no meaningful stored XSS exposure. Applications with server-side HTML sanitization are additionally protected even without patching. Given the medium CVSS, absence from KEV, and the UI:R dependency, this should be triaged as a routine patch-cycle item rather than an emergency response trigger - though any multi-user Rails application accepting untrusted Trix content should prioritize the 2.1.18 upgrade to close the window.

An authenticated attacker with a low-privilege account pastes crafted HTML - a <span> carrying data-trix-attachment="{}" and data-trix-attributes containing {"href":"javascript:alert(document.cookie)"} - into a Trix-powered input field such as a comment box or article body. The malicious href bypasses HTMLParser's attachment sanitization and is stored in the application database as part of the serialized Trix document. When a second user opens the page and clicks the visually innocuous hyperlink, the javascript: URI executes in their browser, enabling session cookie theft or arbitrary DOM manipulation.