Serialize JavaScript: Cross-site scripting (XSS) via unescaped </script> in serialized function bodies

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. From 7.1.1 until 7.1.2, function values serialized by serialize-javascript are not fully protected against script-closing tags in attacker-influenced function source because SCRIPT_CLOSE_REGEXP can consume a second closing tag inside one match. When the serialized function is embedded in a script element, the surviving closing tag terminates the element early and causes the remaining output to be parsed as HTML, enabling cross-site scripting in the page origin. Only function values are affected; ordinary data values and options.isJSON output are unaffected. This issue is fixed in version 7.1.2.

Source published

29 Sep 2026 16:00:33 UTC

Source modified

29 Sep 2026 16:53:35 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · 2.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. From 7.1.1 until 7.1.2, function values serialized by serialize-javascript are not fully protected against script-closing tags in attacker-influenced function source because SCRIPT_CLOSE_REGEXP can consume a second closing tag inside one match. When the serialized function is embedded in a script element, the surviving closing tag terminates the element early and causes the remaining output to be parsed as HTML, enabling cross-site scripting in the page origin. Only function values are affected; ordinary data values and options.isJSON output are unaffected. This issue is fixed in version 7.1.2.

Source published

Sep 29, 2026, 4:00:33 PM (timezone not stated)

Source modified

Sep 29, 2026, 4:53:35 PM (timezone not stated)

Saved here

11 Nov 2026 17:07:02 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 4.0 · 2.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. From 7.1.1 until 7.1.2, function values serialized by serialize-javascript are not fully protected against script-closing tags in attacker-influenced function source because SCRIPT_CLOSE_REGEXP can consume a second closing tag inside one match. When the serialized function is embedded in a script element, the surviving closing tag terminates the element early and causes the remaining output to be parsed as HTML, enabling cross-site scripting in the page origin. Only function values are affected; ordinary data values and options.isJSON output are unaffected. This issue is fixed in version 7.1.2.

Source published

29 Sep 2026 16:17:19 UTC

Source modified

30 Sep 2026 19:38:27 UTC

Saved here

25 Oct 2026 16:19:28 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · [email protected] · Secondary · 2.3 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

### 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. `SCRIPT_CLOSE_REGEXP` 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.

Source published

30 Sep 2026 15:40:05 UTC

Source modified

30 Sep 2026 16:00:18 UTC

Saved here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Publisher rating · LOW