Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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: 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…
Recommended action: Upgrade to 7.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Embedded as the README documents (<scriptwindow.S = <%= serialize(state) %</script) and parsed by Chromium, the…
Recommended action: Upgrade to 7.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? It 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. Who is impacted? Applications that use serialize-javascript to serialize untrusted or user-controlled objects are at risk. While direct exploitation is difficult, it becomes a high-priority threat if the application is also vulnerable to Prototype Pollution or handles untrusted data via YAML Deserialization, as these could be used to inject the malicious object. Patches Has the problem been patched? Yes, the issue has been patched by replacing instanceof Array checks with Array.isArray() and using Object.keys() for sparse array detection. What versions should users upgrade to? Users should upgrade to v7.0.5 or later. Workarounds Is there a way for…
Recommended action: Upgrade to 7.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The serialize-javascript npm package (versions <= 7.0.2) contains a code injection vulnerability. It is an incomplete fix for CVE-2020-7660. While RegExp.source is sanitized, RegExp.flags is interpolated directly into the generated output without escaping. A similar issue exists in Date.prototype.toISOString(). If an attacker can control the input object passed to serialize(), they can inject malicious JavaScript via the flags property of a RegExp object. When the serialized string is later evaluated (via eval, new Function, or <script tags), the injected code executes. Patches The fix has been published in version 7.0.3. https://github.com/yahoo/serialize-javascript/releases/tag/v7.0.3
Recommended action: Upgrade to 7.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in npm-serialize-javascript. The vulnerability occurs because the serialize-javascript module does not properly sanitize certain inputs, such as regex or other JavaScript object types, allowing an attacker to inject malicious code. This code could be executed when deserialized by a web browser, causing Cross-site scripting (XSS) attacks. This issue is critical in environments where serialized data is sent to web clients, potentially compromising the security of the website or web application using this package.
Recommended action: Upgrade to 6.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
serialize-javascript prior to 3.1.0 allows remote attackers to inject arbitrary code via the function "deleteFunctions" within "index.js". An object such as {"foo": /1"/, "bar": "a\"@R-<UID-0@"} was serialized as {"foo": /1"/, "bar": "a\/1"/}, which allows an attacker to escape the bar key. This requires the attacker to control the values of both foo and bar and guess the value of <UID. The UID has a keyspace of approximately 4 billion making it a realistic network attack.
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of serialize-javascript prior to 2.1.1 are vulnerable to Cross-Site Scripting (XSS). The package fails to sanitize serialized regular expressions. This vulnerability does not affect Node.js applications. Recommendation Upgrade to version 2.1.1 or later.
Recommended action: Upgrade to 2.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.