Similar to T110128 (And the more older T37315).
Lots of parser tag extensions, take user input. Do something with it, then return escaped html (Which is considered half-serialized html by the parser [usually. You're allowed to return an array to specify otherwise, but I've never seen anyone do that]). If using normal functions to escape the html (Html/XML class, htmlspecialchars, etc), they will think the \x7fUNIQ... string is fine and pass it on. The parser will then replace that string. If the contents of the strip marker aren't safe for an attribute (Rather common. That's kind of the point of strip markers - to protect things from sanitization) than this can lead to XSS.
Example:
<inputbox>
default={{#tag:poem|" autofocus onfocus="alert(1)" f=|compact=true|class=foo=}}
type=create
</inputbox>There are many extensions that follow the pattern that inputbox does in terms of how it escapes things.
There are probably extensions (And possibly things in core) that can be used in place of poem for generating unsafe in attributes strip markers. (Poem is really not doing anything wrong here)
Note that normal html tags aren't affected since line 1240 of the parser instructs the sanitizer to do unstrip before escaping attributes.
Suggested fix: Unclear, but good first step would probably to start treating U+7F as a bad character to be removed whenever attributes are escaped (e.g. at the bottom of Html::expandAttributes and similar functions).