Vulnerability details

### Impact `serialize-javascript` escapes its output so it is safe to embed inside a `<script>` element. Before 7.1.3 that guarantee did not hold for a **function value whose source ends in a bare `</script`**. Each function body is escaped on its own, and a bare `</script` was only neutralized when followed — within the same body — by a character the HTML tokenizer treats as ending the tag name (TAB, LF, FF, CR, SPACE, `/` or `>`). A body ending exactly at `</script` has no following character, so it was emitted unescaped. The delimiter is then supplied by the surrounding output (for example the newline the `space` option emits after the value), and a later serialized value can supply the closing `>` followed by markup: ```js const serialize = require('serialize-javascript'); function f() {} f.toString = () => 'function f(){ return 1 }//</script'; function g() {} g.toString = () => 'function g(x){ return x } > <img src=x onerror=alert(1)>'; serialize({ a: { f }, g }, { space: 2 }); // { // "a": { // "f": function f(){ return 1 }//</script // }, // "g": function g(x){ return x } > <img src=x onerror=alert(1)> // } ``` Embedded in a `<script>` element, the script ends at the injected tag and the `<img>` becomes a live element in the page. Exploitation requires an attacker to control the **source text** of a serialized function, in practice through a spoofed `toString()`. Real functions always end in `}`, so ordinary function values are not affected, and non-function values (including strings containing `</script`) are escaped correctly. ### Patches Fixed in **7.1.3** (#235). The bare `</script` form is now also matched at the end of the function body, so it is escaped regardless of what follows it in the output. ### Workarounds Upgrade to **7.1.3**. If you cannot upgrade, do not serialize function values whose source text (or `toString()`) can be influenced by an attacker. ### Credits Reported by **ha_kr25** via the Yahoo bug bounty program.