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 hakr25 via the Yahoo bug bounty program.

Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. Prior to 7.1.3, the function-source escaping logic does not neutralize a bare closing-script prefix when attacker-influenced function source text ends exactly at that prefix. Because each function body is escaped independently, a delimiter supplied by surrounding serialized output can terminate an HTML script element, and a later serialized value supplies injected markup that becomes a live element in the page. Exploitation requires control of a serialized function's source text, such as through a spoofed toString(). This issue is fixed in version 7.1.3.

Impact

serialize-javascript escapes its output so it is safe to embed inside a <script> element. In 7.1.1 that guarantee does not hold for function values: a crafted function body can carry a literal, unescaped </script> into the output, terminating the script element early so the remainder is parsed as HTML.

SCRIPTCLOSEREGEXP used <\/script[^>]> as its first alternative. The character class excludes only >, so a single match could run from one </script all the way to the next > anywhere in the source — swallowing a second, complete </script> along the way. Only one replacement is emitted per match, and the plain-code branch neutralizes just the leading < ('< ' + match.slice(1)), so the swallowed tag was re-emitted verbatim.

Reaching that shape requires </script in code position, which is legal JavaScript: x</script=+/ parses as x < /script=+/, a comparison against a regex literal.

js const serialize = require('serialize-javascript'); const src = "function f(x){ return x</script=+/ + '</script><img src=x onerror=alert(1)>' }"; const out = serialize({ h: new Function('return ' + src)() }); // {"h":function f(x){ return x< /script=+/ + '</script><img src=x onerror=alert(1)>' }}

Embedded as the README documents (<script>window.S = <%= serialize(state) %></script>) and parsed by Chromium, the script element ends at the injected tag and the <img> becomes a live DOM node with its onerror handler executing in the page origin.

Only the function path is affected. The same payload passed as data is escaped correctly, and options.isJSON / non-function values are unaffected.

Patches

Fixed in 7.1.2. The wildcard now excludes < as well as > ([^<>]), so a match can never reach past a second <. Every </script in the source therefore either begins its own match or is followed by a character the HTML tokenizer does not accept as ending a tag name — it ends the tag name only on TAB, LF, FF, CR, SPACE, / or >, and emits anything else as text.

Workarounds

Upgrade to 7.1.2. If you cannot upgrade, 7.1.0 and earlier are unaffected, or avoid serializing functions whose source text is attacker-influenced.

Regression note

This is a regression specific to 7.1.1, not a long-standing issue. 7.1.0 and earlier applied the same wildcard but escaped the entire match, so no tag survived. Downstream scanners defaulting to a >= 7.1.0 range would be overly broad.

Serialize JavaScript to a superset of JSON that includes regular expressions and functions. Prior to version 7.0.5, there is a Denial of Service (DoS) vulnerability caused by CPU exhaustion. When serializing a specially crafted "array-like" object (an object that inherits from Array.prototype but has a very large length property), the process enters an intensive loop that consumes 100% CPU and hangs indefinitely. This issue has been patched in version 7.0.5.