GHSA-5c6j-r48x-rmvq

What it actually does

Affected versions of the npm package serialize-javascript can generate unsafe JavaScript output when serializing attacker-influenced RegExp or Date values. Specifically, malicious behavior can be introduced through RegExp.flags or Date.prototype.toISOString() handling, allowing injected JavaScript to be emitted into the serialized result. If an application later embeds that serialized output into executable JavaScript, evaluates it, or serves it into a context where it runs, the flaw can lead to remote code execution in the consuming application context.

Why it matters to the business

Applications that use serialize-javascript to transform data into executable JavaScript may be exposed to code execution if untrusted or attacker-influenced values are serialized. This can result in server-side compromise, browser-side script execution, credential theft, application takeover, data exposure, or downstream compromise of systems that consume generated JavaScript. The package is common in JavaScript build and server-side rendering workflows, so affected transitive dependencies may be present even when the package is not directly imported. This issue is not currently listed in CISA KEV and has no known mature public exploitation signal in the provided data, but the high severity and RCE classification warrant timely remediation.

How an attack unfolds

An attacker first needs a path to influence values that are passed into serialize-javascript, directly or through a framework, rendering pipeline, build process, template helper, caching layer, or API that serializes application state. The attacker crafts data involving RegExp or Date behavior that abuses unsafe handling of RegExp.flags or Date.prototype.toISOString(). When the vulnerable package serializes that value, it may produce JavaScript containing attacker-controlled code rather than inert data. If the application then embeds, evaluates, or serves the serialized output in an executable JavaScript context, the injected code runs with the privileges of that context. Depending on where serialization occurs, impact may range from browser-side execution in users’ sessions to server-side command execution if the generated code is executed by Node.js or another JavaScript runtime.

How to fix it

Upgrade serialize-javascript to version 7.0.3 or later. For npm-based projects, update direct dependencies and regenerate lockfiles so transitive references are also resolved to a fixed version. Where the package is pulled in transitively, upgrade the parent package that depends on it, use npm/yarn/pnpm override or resolution mechanisms where appropriate, and verify the final dependency tree no longer contains vulnerable versions. As defense-in-depth, do not serialize untrusted JavaScript objects into executable code; prefer JSON serialization for pure data; avoid eval, new Function, vm execution, or script embedding of serialized untrusted content; and apply strict output encoding and Content Security Policy where serialized data is emitted into web pages.

How to confirm the fix worked

Confirm that all deployed applications, build artifacts, containers, and lockfiles resolve serialize-javascript to 7.0.3 or later. Run package inventory commands such as npm ls serialize-javascript, yarn why serialize-javascript, or pnpm why serialize-javascript in each JavaScript project and CI build context. Review package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and container image dependency scans for vulnerable versions. Validate that no runtime or bundled artifact includes a pre-7.0.3 copy. In application code, review uses of serialize-javascript to ensure attacker-controlled objects are not serialized into executable JavaScript and that serialized output is not passed to eval-like APIs or embedded into script contexts without appropriate controls.

Typical attack path

1. Identify an application, framework, plugin, or build/rendering path that uses a vulnerable version of serialize-javascript before 7.0.3.
2. Find an input path where attacker-controlled or attacker-influenced values can reach the serialization routine.
3. Craft data that abuses RegExp.flags or Date.prototype.toISOString() handling to cause unsafe JavaScript to be emitted.
4. Trigger the vulnerable serialization path through an HTTP request, API call, plugin input, template/rendering action, or build-time data source.
5. Cause the generated serialized JavaScript to be executed by a browser, server-side JavaScript runtime, or downstream consumer.
6. Use the resulting execution context to steal data, execute commands, modify application behavior, or pivot further.

How to detect it

Detection is highly application-specific because exploitation depends on how serialize-javascript is used and whether attacker-controlled values reach executable JavaScript contexts. Review web, API, application, SSR, build worker, and Node.js runtime logs for requests or job inputs containing suspicious JavaScript syntax, RegExp literals, manipulated Date serialization behavior, or payloads attempting to break out of serialized values. Inspect generated JavaScript artifacts, rendered HTML, cached pages, and hydration-state script blocks for unexpected function calls, child_process usage, eval-like constructs, script tag breakouts, or network callbacks to untrusted domains. On servers, correlate suspicious requests with Node.js process anomalies, spawned shell commands, unexpected outbound connections, modified build artifacts, newly written files, or errors mentioning RegExp flags or Date toISOString. For browser-side exposure, review CSP reports, WAF logs, CDN logs, and client error telemetry for inline script violations or injected JavaScript appearing in serialized state.

• serialize-javascript@0.
• serialize-javascript@1.
• serialize-javascript@2.
• serialize-javascript@3.
• serialize-javascript@4.
• serialize-javascript@5.
• serialize-javascript@6.
• RegExp.flags
• Date.prototype.toISOString
• toISOString()
• child_process
• require('child_process')
• require("child_process")
• process.mainModule.require
• constructor.constructor
• Function(
• eval(
• vm.runInThisContext
• vm.runInNewContext
• </script>
• new RegExp(

What your security team should do

• Inventory all repositories, container images, serverless packages, and build pipelines for serialize-javascript and prioritize upgrades to 7.0.3 or later.
• Regenerate and redeploy affected lockfiles, containers, and build artifacts; do not rely only on package.json version ranges.
• Search for transitive vulnerable copies and apply package manager overrides or parent dependency upgrades where direct updates are not sufficient.
• Prioritize externally exposed server-side rendering, templating, API documentation, preview, CMS, plugin, and build systems that serialize attacker-influenced content.
• Review application code for use of serialize-javascript output in eval, new Function, vm.runIn*, script tags, inline hydration state, or other executable JavaScript contexts.
• Add dependency scanning gates in CI/CD to block serialize-javascript versions earlier than 7.0.3.
• If suspicious exploitation is possible, perform retrospective log and artifact review for crafted RegExp/Date serialization abuse and unexpected JavaScript execution indicators.