This CVE exploits a design limitation in HTML sanitization that's fundamentally different from typical injection flaws. The sanitizer correctly blocks <form> and <button> elements, which are the obvious vectors. But an <input> element bearing a form attribute (pointing to a form's id) and a formaction attribute is syntactically safe in isolation — the sanitizer has no way to know that the target page already contains a form with a matching id. When the page renders, the injected input becomes associated with that existing form, and submitting it sends data to the attacker's URL instead of the legitimate endpoint.
The critical precondition is a page with a form bearing a known id, rendered alongside user-submitted HTML. This pattern is common in applications with comment systems, rich-text editors, or any feature that sanitizes and displays user HTML alongside application-controlled page structure. If the target form collects credentials and the victim's browser autofills those fields, the attacker captures them without any script execution — CSP, SRI, and most XSS defenses are completely irrelevant.
The CVSS 6.1 understates the risk because it's calibrated for script execution as the proxy for severe impact. A credential harvester that achieves the same end without touching JavaScript scores lower by default, but the blast radius is identical: the victim sends credentials to an attacker-controlled endpoint. This is particularly dangerous in high-autofill contexts — banking portals, healthcare portals, enterprise SSO pages — where the form-with-id precondition is standard architecture.
The deeper issue is that attribute-level sanitization cannot reason about the host page's structure. The sanitizer would need either domain knowledge (what forms exist on the page) or broad restrictions (reject any external formaction) — both constrain legitimate use cases. The realistic mitigation path may not be smarter sanitization at all, but structural isolation: rendering sanitized HTML inside sandboxed iframes where cross-form association is impossible. That recommendation has existed in web security literature for over a decade but rarely reaches the developers adopting sanitization libraries.
Before patching, verify whether your application renders user-submitted HTML on pages containing forms with ids. If so, treat this as higher priority than the CVSS score suggests. The fix may require rethinking sanitization as a security boundary entirely, rather than trying to make the sanitizer context-aware.