serialize-javascript CVE-2026-115897

Requires an application to serialize a function value whose source text / toString() output is controllable by the attacker, and that function body must end exactly at a bare '</script' with no trailing delimiter character. The surrounding serialized output must then supply the delimiter (for example the newline emitted by the 'space' pretty-print option) and a later serialized value must supply the closing '>' followed by injected markup. The resulting serialized string must be embedded inside an HTML <script> element and rendered in a victim's browser. Limiting factors: ordinary functions end in '}' and are unaffected; non-function values and strings containing '</script' are escaped correctly; the attacker needs control over function source via a spoofed toString(); and a victim must load the page (passive user interaction). The only complete fix per the vendor is upgrading to 7.1.3; if upgrade is not possible, the vendor advises not serializing function values whose source text can be attacker-influenced.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The CVSS 4.0 base score is 2.1 and the vuln.today decision label is 'monitor' - both point away from urgency. There is no CISA KEV listing and no EPSS score was supplied, so there is no evidence of active or probable widespread exploitation (no public exploit identified as actively used at time of analysis; a public PoC reproducer is included in the GHSA advisory but is not verified as a weaponized working exploit). The 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N) encodes exactly why real risk is low despite network reach: high attack complexity, a present attack requirement, a privilege requirement, passive user interaction, and only Low confidentiality/integrity impact with no availability impact. The most important limiter is not captured well by the raw score and must be read from the advisory: exploitation requires an application to serialize a function whose source text is attacker-influenced (in practice via a spoofed toString()), which is an unusual precondition. Ordinary function values - which always end in '}' - and all non-function values including strings containing '</script' are escaped correctly and are not affected. This is therefore a real, verifiable defect worth patching on a normal maintenance cadence, not a high-CVSS-but-low-real-risk mismatch and not an emergency.

An application using serialize-javascript < 7.1.3 serializes attacker-influenced data that includes a function whose spoofed toString() returns source ending in a bare '</script', while a later serialized value supplies the closing '>' plus injected markup such as '<img src=x onerror=alert(1)>'. When that serialized output is embedded inside an HTML <script> element and the victim loads the page, the script element terminates early at the injected tag and the markup becomes a live element, executing attacker script in the victim's browser. The GHSA advisory includes a concrete reproducer demonstrating this.