serialize-javascript EUVD-2026-108967

Four specific conditions must all hold: (1) the application uses serialize-javascript 7.0.1-7.1.3 to serialize data that includes a function value; (2) the attacker controls that function's source text, in practice via a spoofed toString() returning a body ending in exactly '</script' with no trailing delimiter character; (3) the serialized output is embedded inside an HTML <script> element and the surrounding output (or a later serialized value) supplies the closing '>' and injected markup - the advisory's example relies on the newline emitted by the { space } option; and (4) a victim loads the resulting page (UI:P / passive interaction). LIMITING FACTORS: ordinary function values end in '}' and are unaffected, and non-function values (even strings containing '</script') are escaped correctly, so the flaw cannot be triggered without attacker influence over a serialized function's source - a narrow, application-specific precondition. The complete fix is upgrading to 7.1.3; the only stated workaround if you cannot upgrade is to not serialize function values whose source/toString() an attacker can influence.

All decision signals point the same way: this is a low-priority issue. The supplied CVSS 4.0 base score is 2.3 (Low) with vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N - network-reachable and unauthenticated, but gated by an attack requirement (AT:P) and passive user interaction (UI:P), with no impact to the vulnerable system itself (VC/VI/VA all N) and only low confidentiality/integrity impact to a subsequent system (SC:L/SI:L), consistent with reflected XSS executing in a victim browser rather than compromising the server. The vuln.today decision label is 'monitor', not act_now or emergency. This is NOT in CISA KEV (status: not listed) and no EPSS score was provided, so there is no evidence of active or probable exploitation. The GHSA advisory contains a concrete reproduction (a public PoC reference exists; it is not verified as working exploit code in the input). The dominant limiting factor is the precondition: exploitation requires the attacker to already control the source text of a serialized function, in practice via a spoofed toString() - ordinary function values (which always end in '}') and non-function values are not affected. No signals conflict here; the low CVSS, 'monitor' label, absent KEV, and narrow precondition all agree this is a real-but-low-risk hardening fix, not an urgent threat. EPSS was not supplied, so probabilistic exploitation likelihood could not be cross-checked.

An application serializes JavaScript objects (via serialize-javascript 7.0.1-7.1.3) and embeds the result inside a <script> element in an HTML page, where at least one serialized function's source text can be influenced by an attacker through a spoofed toString() returning a body ending in a bare '</script'. A victim loads the page; the surrounding output (e.g. the newline from the 'space' option) supplies the tag delimiter and a later serialized value supplies '>' plus markup, so the browser closes the script early and renders injected live markup such as an <img onerror> handler. A working reproduction is published in the GHSA advisory.