
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 7.1.1, < 7.1.2
Patched in 7.1.2
Details
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.
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.
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.
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.
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.
EPSS, exploit probability
Low0.32%
estimated chance of real-world exploitation in the next 30 days, higher than 25.1% of every CVE FIRST.org scores
Refreshed 11/14/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.