CVE-2024-11831

What it actually does

This vulnerability is a cross-site scripting flaw in yahoo/serialize-javascript. The library can serialize JavaScript values such as regular expressions and other object types without sufficiently neutralizing attacker-controlled content. If an application embeds that serialized output into an HTML page or browser-executed script context, crafted input can break out of the intended serialized data representation and introduce attacker-controlled JavaScript. Successful exploitation requires an attacker to influence serialized data and a user to load the affected page; the impact is execution of script in the victim user’s browser under the origin of the vulnerable web application, enabling limited confidentiality and integrity compromise but not direct server-side code execution.

Why it matters to the business

A vulnerable application may allow attackers to run unauthorized actions in a user’s browser, steal session-related data that is accessible to client-side JavaScript, modify page content, redirect users to phishing pages, or abuse the trusted website to attack users. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the issue has been public for a significant period, so organizations should treat affected dependencies as overdue for remediation, especially for internet-facing applications that serialize user-controlled data into web pages.

How an attack unfolds

An attacker first identifies an application that uses yahoo/serialize-javascript to place serialized data into a client-side JavaScript or HTML context. The attacker then finds an input path that is later included in an object, regular expression, or similar value passed to the serializer. By supplying a payload that is not properly sanitized during serialization, the attacker causes the generated page to contain executable JavaScript rather than inert data. When a victim loads the affected page, the browser executes the injected script in the security context of the vulnerable site. The script may read accessible page data, perform actions as the user, change page content, exfiltrate tokens that are not protected from JavaScript access, or redirect the victim. There is no public KEV or named threat actor linkage in the provided data, and exploit maturity is listed as none, so defenders should focus on exposure reduction and log review for suspicious XSS-style payloads rather than campaign-specific indicators.

How to fix it

Upgrade or patch yahoo/serialize-javascript to a version that includes the upstream fix. The provided fixed reference is commit f27d65d3de42affe2aac14607066c293891cec4e. If consuming the package through npm or a downstream dependency, update lockfiles and dependency manifests so the resolved package includes that fix or a later secure release. Rebuild and redeploy all applications that bundle or vendor the affected library. As defense in depth, avoid placing serialized user-controlled data directly inside executable script blocks; prefer JSON responses with application/json content type, safe JSON encoding, and DOM APIs that do not interpret HTML. Apply context-aware output encoding for HTML, JavaScript string, attribute, and URL contexts. Enforce a restrictive Content Security Policy that avoids unsafe-inline, uses nonces or hashes, and limits outbound exfiltration destinations. Where immediate upgrade is not possible, prevent attacker-controlled regular expressions or complex JavaScript object types from reaching serialize-javascript and encode dangerous sequences before embedding output into browser-executed contexts.

How to confirm the fix worked

Confirm dependency resolution shows a patched yahoo/serialize-javascript build containing commit f27d65d3de42affe2aac14607066c293891cec4e or a later fixed release. Check package-lock.json, yarn.lock, pnpm-lock.yaml, vendored source, container images, and bundled frontend/server artifacts for stale copies. Run software composition analysis and verify no vulnerable transitive dependency remains. Exercise application paths that serialize user-controlled data into pages and inspect the generated HTML/JavaScript for unsafe raw payload execution. Add regression tests using representative XSS payloads such as script tags, closing script delimiters, event handlers, javascript: URLs, and crafted RegExp/object values; the expected result is inert encoded data, not executable code. In production, validate that Content Security Policy blocks inline script execution and that error monitoring does not show new CSP violations tied to suspicious inputs.

Typical attack path

1. Identify a web application that includes yahoo/serialize-javascript in server-side rendering, state hydration, templating, or client bootstrap code.
2. Locate a user-controllable field that is stored or reflected into data later passed to serialize-javascript.
3. Submit a crafted JavaScript-breaking payload, often involving script delimiters, event handlers, JavaScript URLs, regular expression content, or object values that alter the serialized output.
4. Cause a victim user to view the affected page through stored content, a crafted link, workflow interaction, or another user-driven path.
5. The browser parses the vulnerable page and executes the injected script under the application’s origin.
6. Use the script to perform unauthorized in-browser actions, steal accessible data, alter page behavior, or redirect the user.

How to detect it

To determine whether exploitation already occurred, review web server, reverse proxy, CDN, WAF, and application logs for requests containing XSS-style payloads in query strings, form bodies, JSON fields, path parameters, cookies, User-Agent, Referer, and other headers. Pay particular attention to inputs that are later displayed in server-rendered pages, embedded application state, templates, comments, profile fields, search terms, saved names, or other stored content. Look for payloads that attempt to close script blocks, introduce new script tags, use event-handler attributes, invoke eval-like JavaScript, use javascript: URLs, or abuse constructors. Correlate suspicious requests with subsequent victim page views, CSP violation reports, browser error telemetry, unusual redirects, unexpected third-party beacon requests, account setting changes, or session anomalies. If logs include rendered response bodies or application debug output, search for serialized data containing unescaped attacker-controlled JavaScript. For stored XSS scenarios, inspect content records and moderation/audit trails for malicious strings, then identify users who viewed the affected content during the exposure window. Because no campaign-specific indicators or threat actors are provided, detection should be behavior- and payload-pattern-based rather than focused on fixed infrastructure indicators.

• <script
• </script
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• eval(
• Function(
• constructor.constructor
• alert(
• prompt(
• confirm(
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• new Image()
• atob(
• btoa(
• String.fromCharCode
• setTimeout(
• setInterval(
• data:text/html
• data:application/javascript
• \x3cscript
• \u003cscript
• \u003c/script
• srcdoc=
• iframe
• svg/onload
• img/src=x
• serialize-javascript
• f27d65d3de42affe2aac14607066c293891cec4e

What your security team should do

• Inventory all applications, services, build pipelines, and vendored code that include yahoo/serialize-javascript or serialize-javascript-derived code.
• Prioritize internet-facing applications and any application that serializes user-supplied content into server-rendered HTML or client hydration state.
• Upgrade to a build containing commit f27d65d3de42affe2aac14607066c293891cec4e or later, then rebuild and redeploy dependent applications.
• Review code paths that call serialize-javascript and remove direct embedding of untrusted serialized values into executable script contexts where possible.
• Add or tighten Content Security Policy using nonces or hashes and without unsafe-inline to reduce the impact of missed XSS sinks.
• Search historical web, application, WAF, CDN, and reverse proxy logs for XSS payload patterns in parameters, headers, referrers, stored content submissions, and API requests.
• If suspicious exploitation is found, review affected user sessions, authentication events, account changes, and unusual outbound browser callbacks to attacker-controlled domains.
• Add CI checks for vulnerable dependency versions and regression tests for XSS payloads in serialization and server-side rendering code.