CVE-2026-65911

DOMPurify przed wersją 3.4.13 zawiera podatność na cross-site scripting w sanityzacji IN_PLACE, gdzie haki usuwania elementów nie neutralizują odłączonych poddrzew. Atakujący mogą dostarczyć HTML z handlerami zdarzeń na elementach potomnych, które wykonują się po zakończeniu sanityzacji, mimo że zwrócony korzeń wygląda na czysty.

DOMPurify przed wersją 3.4.12 nie wykonuje haka afterSanitizeElements dla elementów niestandardowych dozwolonych przez CUSTOM_ELEMENT_HANDLING.tagNameCheck, co pozwala atrybutom ominąć polityki bezpieczeństwa aplikacji. Atakujący mogą zachować wrażliwe atrybuty na elementach niestandardowych, które później ponownie wstrzykują je do zlewów innerHTML, tworząc drugorzędne gadżety XSS.

DOMPurify przed wersją 3.3.2 zawiera podatność na mutacyjne XSS, gdy oczyszczony HTML jest ponownie wstawiany do specjalnych kontekstów parsowania za pomocą innerHTML z wrapperami takimi jak script, xmp, iframe, noembed, noframes lub noscript. Atakujący mogą stworzyć ładunki z sekwencjami zamykającymi, które wychodzą poza kontekst wrappera podczas ponownego parsowania, reaktywując niebezpieczny kod z obsługą zdarzeń w celu wykonania JavaScript.

DOMPurify przed wersją 3.3.2 zawiera podatność na zatruwanie prototypu w trybie USE_PROFILES. Atakujący może ustawić właściwości prototypu Array.prototype, takie jak onclick, na true, co powoduje, że DOMPurify akceptuje procedury obsługi zdarzeń jako dozwolone atrybuty, prowadząc do XSS opartego na DOM.

DOMPurify przed wersją 3.3.2 zawiera podatność na obejście walidacji URI, gdy ADD_ATTR jest dostarczane jako funkcja predykatu przez EXTRA_ELEMENT_HANDLING.attributeCheck. Atakujący może dostarczyć predykat akceptujący określone kombinacje atrybutów i tagów, aby ominąć walidację bezpiecznych URI, umożliwiając niebezpieczne protokoły, takie jak javascript:, co prowadzi do XSS opartego na DOM.

DOMPurify do wersji 3.3.3 nie dezynfekuje elementów DOM przekazanych w trybie IN_PLACE, gdy element pochodzi z innego okna/realm (np. contentDocument iframe). Sprawdzanie instanceof między różnymi realmami w prywatnej funkcji _isNode() zwraca false dla węzłów z obcego realm, powodując, że DOMPurify stringifikuje element (zwracając '[object HTMLDivElement]'), cicho resetuje IN_PLACE na false i zwraca niesprawdzony element z nienaruszonymi ładunkami XSS.

DOMPurify przed wersją 3.4.0 zawiera błąd logiczny w funkcji ADD_TAGS, gdzie ocena skrócona (short-circuit) pozwala zabronionym tagom ominąć ograniczenia FORBID_TAGS. Atakujący mogą stworzyć dane wejściowe zawierające tagi wymienione w FORBID_TAGS, które są również dodane przez funkcję ADD_TAGS, powodując ich zachowanie w oczyszczonym wyjściu.

DOMPurify przed wersją 3.4.7 (dotknięte wersje <= 3.4.5) przekazuje bezpośrednie referencje do modułowych zestawów DEFAULT_ALLOWED_TAGS i DEFAULT_ALLOWED_ATTR do hooków uponSanitizeElement i uponSanitizeAttribute przez data.allowedTags / data.allowedAttributes, gdy sanitize jest wywoływane bez jawnej tablicy cfg.ALLOWED_TAGS / cfg.ALLOWED_ATTR. Hook, który mutuje te pola, trwale rozszerza domyślne listy dozwolonych na czas życia instancji DOMPurify, więc wszystkie kolejne wywołania sanitize z domyślną konfiguracją dziedziczą rozszerzone domyślne, a ładunki atakującego używające zatrutych nazw tagów/atrybutów przetrwają sanityzację. removeAllHooks(), clearConfig() i przekazanie świeżego cfg nie przywracają stanu; tylko utworzenie nowej instancji DOMPurify.

DOMPurify do wersji 3.4.6 zawiera podatność na XSS w trybie IN_PLACE, która ufa kontrolowanemu przez atakującego nodeName na żywych węzłach niebędących formularzami. Atakujący mogą dostarczyć wrogie żywe obiekty DOM z prawdziwymi dziećmi skryptów, których obserwowalny nodeName jest nadpisywany, aby wyglądać jak dozwolone elementy, powodując wykonanie skryptów po wstawieniu oczyszczonego drzewa do żywego dokumentu.

DOMPurify w wersjach od 3.0.0 do 3.4.8, skonfigurowany z SAFE_FOR_TEMPLATES i trybem wyjścia DOM, nie usuwa wyrażeń szablonów (np. ${evil}) wewnątrz elementów <template>. Ostateczne czyszczenie nie przetwarza template.content, więc wyrażenia mogą pozostać i zostać zinterpretowane przez silnik szablonów.