CVE-2026-115897: Cross-Site Scripting via Function Body Boundary Bypass in serialize-javascript

The serialize-javascript package, maintained by Yahoo, is widely used in Node.js server-side rendering (SSR) frameworks and web applications to serialize JavaScript objects into a superset of JSON. Unlike standard JSON.stringify(), which strips functions, regular expressions, dates, and undefined values, serialize-javascript preserves these rich data types as executable JavaScript source code. A primary use case for this library is serializing application state on the server and embedding the resulting string directly inside an HTML <script> element for hydration on the client.

Because the serialized output is designed to be placed directly inside <script>...</script> blocks, a core security requirement of serialize-javascript is neutralizing sequences that an HTML parser would interpret as script termination tags. Under the WHATWG HTML specification, a browser tokenizer operating in the script data state will exit the script block if it encounters the case-insensitive sequence </script followed immediately by an HTML end-tag delimiter (whitespace, /, or >). If an attacker can smuggle an unescaped closing script tag into the serialized output, they can break out of the JavaScript execution context and inject arbitrary HTML markup into the page.

In CVE-2026-115897 (tracked internally by the vendor as PSECBUGS-118415 and aliased as GHSA-m5mm-p8h7-m29v and CVE-2026-115754), this context-escaping mechanism fails under specific boundary conditions involving serialized functions. When a function's source representation ends with the bare prefix </script, the library's sanitization logic fails to identify it as a dangerous sequence because no trailing delimiter is present within the isolated function string itself.

When the sanitized function string is subsequently reassembled into the parent object structure, formatting options (such as indentation spaces or newlines passed via the space parameter) can immediately follow the function body. This formatting supplies the missing HTML end-tag delimiter right after the unescaped </script prefix. If a subsequent property in the serialized object supplies a closing > character and malicious markup, the browser prematurely closes the <script> tag and executes the injected payload, resulting in Cross-Site Scripting (CWE-79).

To understand the root cause of CVE-2026-115897, it is necessary to examine how serialize-javascript processes different data types during serialization. For standard string values and regular expressions, the library replaces all occurrences of <, >, /, and Unicode line terminators (\u2028, \u2029) with their corresponding Unicode escape sequences (e.g., \u003C). However, this blanket character replacement cannot be applied to serialized functions. Escaping all <, >, or / characters inside a function body would corrupt valid JavaScript syntax, such as comparison operators (a < b), arrow functions (=>), division operators, or regular expression literals.

To preserve valid JavaScript syntax while preventing HTML script breakout, serialize-javascript processes functions through a dedicated pipeline. During the initial pass over the input object, JSON.stringify() is called with a custom replacer function that replaces any encountered function with a unique string placeholder (@__F-<UID>-<index>__@). In a post-processing step, these placeholders are replaced with the actual function source code obtained via fn.toString() and sanitized by the internal helper escapeFunctionBody().

Prior to version 7.1.3, escapeFunctionBody() relied on the regular expression SCRIPT_CLOSE_REGEXP to locate dangerous closing script sequences within the function source code:

var SCRIPT_CLOSE_REGEXP = /<\/script[^<>]*>|<\/script(?=[\t\n\f\r \/>])/gi;

This regular expression matches two distinct patterns: a complete closing tag (<\/script[^<>]*>) or a bare prefix (<\/script) followed by a positive lookahead (?=[\t\n\f\r \/>]). The lookahead was designed to match the exact set of characters that the HTML5 specification defines as valid end-tag delimiters in the script data state: tab (\t), line feed (\n), form feed (\f), carriage return (\r), space ( ), solidus (/), or greater-than (>). The library matched the bare prefix without requiring a closing > inside the same function because a matching > could be supplied by a separate serialized value later in the output.

The vulnerability arises because escapeFunctionBody() executes on each function's string representation in complete isolation before placeholder substitution occurs. If a function's string representation ends immediately with the characters </script (for example, inside a trailing single-line comment function f(){}//</script), there are no characters following </script during the execution of escapeFunctionBody(). Consequently, the positive lookahead (?=[\t\n\f\r \/>]) evaluates against the end of the string, fails to find a matching delimiter character, and leaves the trailing </script sequence unmodified.

Once escapeFunctionBody() returns the unmodified string, serialize() substitutes it back into the JSON string in place of its @__F-...__@ placeholder. If the caller invoked serialize(obj, { space: 2 }) or similar formatting options, JSON.stringify() will have placed a newline character (\n) immediately after the placeholder. In the final concatenated output, the trailing </script from the function body is now directly adjacent to the \n from the JSON formatting, creating a valid HTML end-tag prefix (</script\n) that only requires a subsequent > anywhere later in the output to complete the tag and break out of the script context.

The vulnerability resides in index.js within the yahoo/serialize-javascript repository. When serializing functions, the library invokes serializeFunc(), which extracts the function source via .toString() and passes it to escapeFunctionBody() unless options.unsafe is explicitly set to true.

function serializeFunc(fn, options) {
  var serializedFn = fn.toString();
  if (IS_NATIVE_CODE_REGEXP.test(serializedFn)) {
    throw new TypeError('Serializing native function: ' + fn.name);
  }
 
  // pure functions, example: {key: function() {}}
  if (IS_PURE_FUNCTION.test(serializedFn)) {
    return !(options && options.unsafe) ? escapeFunctionBody(serializedFn) : serializedFn;
  }
  ...

In Commit 2864b3c6260a3bfd52d2db3e70d1a079de108a61 (Pull Request #235), the maintainers updated SCRIPT_CLOSE_REGEXP in index.js to account for the end-of-string boundary within isolated function bodies:

diff --git a/index.js b/index.js
--- a/index.js
+++ b/index.js
@@ -26,7 +26,11 @@ var UNSAFE_CHARS_REGEXP   = /[<>\/\u2028\u2029]/g;
 // stays in script data, so only these need neutralizing. The bare-prefix form
 // matters because the matching `>` could be supplied by a different
 // serialized value later in the output, so escaping stops there without
-// waiting for a closing `>`. A trailing backslash is not a delimiter here
+// waiting for a closing `>`. For the same reason the bare form also matches
+// at the very end of the string: each function body is escaped on its own, so
+// a body ending in `</script` can't see the delimiter (e.g. the newline added
+// by the `space` option) that the surrounding output supplies next
+// (PSECBUGS-118415). A trailing backslash is not a delimiter here
 // (that's a JS-level concern, not an HTML one), so this doesn't affect tagged
 // template literals like `String.raw`.
 //
@@ -38,7 +42,7 @@ var UNSAFE_CHARS_REGEXP   = /[<>\/\u2028\u2029]/g;
 // longer contain a second `<`, every `</script` in the source is either the
 // start of its own match or is followed by a non-delimiter — and the latter
 // the tokenizer never treats as an end tag.
-var SCRIPT_CLOSE_REGEXP = /<\/script[^<>]*>|<\/script(?=[\t\n\f\r \/>])/gi;
+var SCRIPT_CLOSE_REGEXP = /<\/script[^<>]*>|<\/script(?=$|[\t\n\f\r \/>])/gi;
 
 var RESERVED_SYMBOLS = ['*', 'async'];

The patch modifies the positive lookahead in the second branch of SCRIPT_CLOSE_REGEXP from (?=[\t\n\f\r \/>]) to (?=$|[\t\n\f\r \/>]). By adding the end-of-input anchor $ as an alternative inside the lookahead assertion, any occurrence of </script at the exact end of a function string is now matched during escapeFunctionBody() execution.

When escapeFunctionBody() finds a match via SCRIPT_CLOSE_REGEXP, it determines whether the match lies within a JavaScript string/template/comment span or within code tokens. If the trailing </script is at the end of a single-line comment (//</script), it is replaced with the Unicode-escaped sequence \u003C\u002Fscript. If it occurs in a code position (such as division following a block closure }</script), it is rewritten as < /script, inserting a space between < and / to prevent the HTML tokenizer from entering the end-tag open state while preserving valid JavaScript syntax.

Fix Completeness Assessment

The fix directly addresses the boundary discrepancy between isolated function sanitization and final document assembly. Because escapeFunctionBody() is the sole sanitization path that permits raw < and > characters in the output (all other serialized types undergo unconditional replacement of [<>\/\u2028\u2029]), anchoring the bare </script prefix check to both the HTML delimiter character class and the end-of-string anchor $ closes the gap where external formatting tokens could complete the tag delimiter requirement.

Exploiting CVE-2026-115897 requires specific application conditions, which is reflected in its CVSS v4.0 Attack Complexity (AC:H) and Attack Requirements (AT:P) ratings. First, the target application must pass an object containing functions (or objects with a custom/spoofed .toString() method that is treated as a function) into serialize(). Second, the attacker must be able to control or influence the source representation of at least one function so that it ends with </script, as well as a subsequent serialized function or unescaped code structure that contains a closing > character and the desired HTML payload.

Third, the serialization output must supply a valid HTML end-tag delimiter immediately following the first function body. In typical JSON structures without formatting, a function value inside an object or array is immediately followed by ,, }, or ]. Because none of ,, }, or ] are HTML end-tag delimiters (\t, \n, \f, \r, space, /, >), </script, or </script} will not close the <script> tag in a standard browser parser. However, if the space option in serialize(obj, { space: 2 }) is used, JSON.stringify outputs a newline (\n) immediately after nested object properties before the closing brace, supplying the required delimiter.

The following proof-of-concept, derived from the unit test suite added in Pull Request #235 (test/unit/serialize.js), demonstrates how two serialized functions interact with the space option to achieve script breakout:

const serialize = require('serialize-javascript');
 
// 1. First function overrides toString() to end strictly with '</script'
var f = function () {};
f.toString = function () {
    return 'function f(){ return 1 }//</script';
};
 
// 2. Second function supplies the closing '>' and the injected HTML payload
var g = function () {};
g.toString = function () {
    return 'function g(x){ return x } > <img src=x onerror=alert(1)>';
};
 
// 3. Serialize with formatting enabled (space: 2)
var payload = serialize({ a: { f: f }, g: g }, { space: 2 });
console.log('<script>var state = ' + payload + ';</script>');

When executed on serialize-javascript version 7.1.2 or earlier, the snippet produces the following HTML structure:

<script>var state = {
  "a": {
    "f": function f(){ return 1 }//</script
  },
  "g": function g(x){ return x } > <img src=x onerror=alert(1)>
};</script>

When a browser parses this HTML:

1. The tokenizer enters the <script> block and parses var state = ... // as script data.
2. It encounters </script followed immediately by \n (the newline inserted after "f" before }).
3. Because \n is a valid whitespace delimiter in the HTML script data end tag open state, the tokenizer transitions to the attribute state and consumes }, "g": function g(x){ return x } as malformed attributes on the closing </script> tag.
4. Upon encountering the > inside function g, the tokenizer closes the <script> element.
5. The remaining string <img src=x onerror=alert(1)> is parsed in the standard HTML data state, rendering the image element and executing the onerror JavaScript handler in the victim's browser.

The primary impact of CVE-2026-115897 is Cross-Site Scripting (XSS) within the client browser rendering the serialized output. If an attacker successfully exploits this flaw, they can execute arbitrary JavaScript within the origin of the vulnerable web application. This allows the attacker to read or modify sensitive data accessible to the DOM, steal session tokens or authentication cookies (if not marked HttpOnly), perform unauthorized actions on behalf of the authenticated user, or alter the visual presentation of the page.

Despite the severity of XSS once triggered, the vulnerability carries a CVSS v4.0 base score of 2.1 (Low) with the vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N. The score is constrained by the stringent prerequisites required for exploitation (AC:H and AT:P). Standard user input is rarely converted into JavaScript Function objects prior to serialization, and standard strings are unaffected because their <, >, and / characters are unconditionally escaped via UNSAFE_CHARS_REGEXP.

For an application to be vulnerable in practice, it must serialize objects containing functions where the function body or its .toString() method is influenced by untrusted input, and it must either use the space formatting option or serialize a structure where a whitespace delimiter naturally follows the function placeholder. Furthermore, a second unescaped > must appear later in the serialized stream (such as inside another serialized function body) because > characters in ordinary string properties are converted to \u003E.

At the time of publication, there is no evidence of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, because serialize-javascript is a foundational dependency in many server-side rendering toolchains and state hydration libraries, downstream applications that dynamically construct or transpile functions from user-supplied templates or configuration files should treat this flaw as a defense-in-depth priority.

The recommended remediation is to upgrade serialize-javascript to version 7.1.3 or later. Version 7.1.3 updates SCRIPT_CLOSE_REGEXP to detect and neutralize </script sequences occurring at the exact end of serialized function bodies.

Administrators and developers can update the package using their standard Node.js package manager:

# Using npm
npm install serialize-javascript@^7.1.3
 
# Using Yarn
yarn add serialize-javascript@^7.1.3
 
# Using pnpm
pnpm add serialize-javascript@^7.1.3

> [!NOTE] > Because serialize-javascript is frequently included as a transitive dependency by SSR frameworks, bundlers, and state management libraries (such as Redux or Webpack plugins), developers should inspect their lockfiles (package-lock.json, yarn.lock, or pnpm-lock.yaml) using npm ls serialize-javascript and apply package overrides or resolutions if a parent dependency pins an older version.

For environments where an immediate upgrade is not possible, several configuration and architectural mitigations can eliminate the attack surface:

1. Disable Function Serialization: If the application only needs to serialize data primitives, dates, regular expressions, or collections (Maps/Sets) and does not require serializing executable functions, pass { ignoreFunction: true } in the options object when calling serialize(obj, { ignoreFunction: true }). This instructs the library to skip function properties entirely.
2. Omit Formatting in Production: Avoid passing the space option (e.g., { space: 2 }) when serializing state for embedding into HTML <script> blocks. Without formatting whitespace inserted after function bodies, the comma or closing brace immediately following a function value prevents the HTML tokenizer from recognizing </script as a valid closing tag.
3. Enforce Content Security Policy (CSP): Implement a strict Content Security Policy using cryptographic nonces or hashes (script-src 'nonce-...' 'strict-dynamic') to restrict the execution of unauthorized inline scripts and event handlers (onerror, onload) injected via HTML breakout.