From dfc8c45b1d27751e8768aafbcd370a9335832cbf Mon Sep 17 00:00:00 2001 From: Jeremy Daer Date: Tue, 8 Sep 2026 23:12:02 +0200 Subject: [PATCH] Apply mXSS-safe SAFE_FOR_XML on untrusted re-inflation paths Stored Trix HTML is re-inflated back into the editor on load (editor.loadHTML) and on reparse (composition.replaceHTML). Both parse under DOMPurify's default config, which leaves SAFE_FOR_XML off and so does not defend the storage round-trip against mutation XSS. insertHTML already opts into SAFE_FOR_XML per call; extend the same idiom to the two remaining re-inflation entry points. Scope it per call rather than flipping config.dompurify globally, which would reintroduce #1213: attachment content serialized into data-trix-attachment can carry Rails view-annotation comments, and SAFE_FOR_XML drops any attribute whose value contains a comment terminator, silently deleting the attachment. The uponSanitizeAttribute hook runs that guard against a neutralized copy of the value so forceKeepAttr keeps the original. The tests assert the security invariant rather than element shape: no event-handler attribute, no