v138 · security · dom

Mutation XSS Playground

Type an attribute value containing < and >, then watch what pre-138 browsers serialised vs what Chrome 138 serialises. The re-parse test shows whether the two DOMs match — a mismatch is the fingerprint of a mutation-XSS window.

Attribute <> escaping: checking…

Attack presets

Input attribute value

DOM creation method

setAttribute() dataset.* .title property

All three paths write to the DOM. outerHTML then serialises back — the escaping happens at that boundary.

Character-level diff: pre-138 vs Chrome 138

Run the test to see the diff.

Step 1 — write to DOM

—

Step 2 — outerHTML (serialised)

—

Step 3 — re-parse innerHTML

—

Step 4 — DOM integrity check

—

The mutation-XSS attack path: A sanitizer writes el.setAttribute('data-value', userInput), then reads back el.outerHTML to store or transmit. If the serialiser doesn't escape < and > inside the attribute value, the serialised string contains unescaped tag markup. When that string is later re-parsed by another innerHTML call — even in a sandboxed context — the parser sees the unescaped tags and instantiates them as live DOM nodes. Chrome 138 closes this by escaping < → < and > → > in attribute values during serialisation.