The vulnerability in DOMPurify 3.4.11 stems from an inconsistency in the sanitization hook policy related to CUSTOM_ELEMENT_HANDLING. When a custom element is allowed via the tagNameCheck configuration, the sanitization function _sanitizeDisallowedNode returns early, skipping the afterSanitizeElements hook and other sanitization checks such as namespace validation and fallback-tag mXSS checks. This results in sensitive attributes not being removed from allowed custom elements, unlike normal elements. While the sanitized attribute values remain inert initially, they can become exploitable if the custom element later injects these values into an HTML sink like innerHTML, enabling a second-order XSS vector. The flaw is due to control flow that bypasses critical sanitization steps for allowed custom elements. The affected versions are all prior to 3.4.12.

Sensitive attributes that would normally be stripped from elements during sanitization are preserved on allowed custom elements due to the bypass of the afterSanitizeElements hook. This preservation does not directly enable immediate XSS at sanitize time, but it creates a second-order XSS risk if the custom element later injects these attributes into an HTML sink such as innerHTML. The vulnerability thus weakens the security guarantees of DOMPurify in applications relying on afterSanitizeElements to enforce attribute removal on all elements, potentially leading to client-side code injection.

A fix is available in DOMPurify version 3.4.12 and later. Users should upgrade to version 3.4.12 or newer to ensure that the afterSanitizeElements hook and other sanitization checks are properly applied to allowed custom elements. Until upgraded, applications should be cautious about relying solely on afterSanitizeElements for security policy enforcement on custom elements. No vendor advisory indicates that no action is required or that the issue is otherwise mitigated.