CVE-2026-116583 in Seroval
Summary
by MITRE • 10/26/2026
Seroval facilitates JavaScript value stringification, including complex structures beyond JSON.stringify capabilities. From 1.6.0 until 1.6.11, the JavaScript-output APIs derive a typed array's constructor name from a property on the value that can be replaced by an own constructor property. When application code copies untrusted properties onto a typed array and then passes it to serialize, serializeAsync, crossSerialize, crossSerializeAsync, crossSerializeStream, Serializer, or compileJSON, the attacker-controlled name is written as executable JavaScript and can run in the page receiving the output. This issue is fixed in version 1.6.11.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in Seroval versions ranging from 1.6.0 to 1.6.11 represents a critical server-side code injection flaw rooted in improper handling of JavaScript object serialization, specifically concerning typed arrays. Seroval is designed to facilitate the stringification of complex JavaScript values that exceed the capabilities of standard JSON.stringify methods, allowing for the preservation of type information and circular references during data transfer between contexts such as web workers or cross-origin frames. The core technical flaw lies in how these APIs determine the constructor name for typed arrays. Instead of relying on a fixed, internal mapping or an immutable prototype property that defines the array's type, the serialization logic derives this identifier from a specific property on the value object itself. This design choice creates a dangerous attack surface because it allows any own property named to match the expected constructor signature to override the default behavior.
In a typical secure implementation, typed arrays such as Int8Array or Float64Array have their type determined by their internal [[TypedArrayElementType]] slot or prototype chain, which cannot be easily spoofed from external data. However, in vulnerable versions of Seroval, if an application code path copies untrusted properties onto a typed array instance before passing it to serialization functions like serialize, serializeAsync, crossSerialize, or compileJSON, the attacker can inject a property that masquerades as the constructor name. When the serializer processes this object, it reads this maliciously injected property and outputs it directly into the resulting JavaScript string without adequate sanitization or validation against a whitelist of known safe constructors. This results in the generation of executable code fragments within the serialized output stream rather than pure data representation.
The operational impact of this vulnerability is severe, as it leads to Cross-Site Scripting (XSS) and Remote Code Execution scenarios depending on how the serialized data is consumed by the receiving application. When an attacker controls the input that gets serialized into a typed array structure with a forged constructor property, they can inject arbitrary JavaScript code snippets such as function declarations or immediate invocations. If the recipient of this serialized data evaluates it using eval, new Function, or similar mechanisms to reconstruct the original object graph in another context like a web worker, the injected payload executes immediately within that scope. This bypasses standard Content Security Policy protections if the policy does not strictly restrict script sources, allowing attackers to steal session tokens, hijack user sessions, or perform actions on behalf of the victim.
This vulnerability aligns with CWE-94, which describes Improper Control of Generation of Code (Code Injection), and specifically maps to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, as it enables an attacker to execute arbitrary scripts within a trusted application context. The root cause is classified under CWE-20, Improper Input Validation, where the system fails to validate that properties on complex objects are safe for serialization when they influence code generation logic. Mitigation strategies primarily involve upgrading Seroval to version 1.6.11 or later, where this behavior has been corrected by hardening the constructor name derivation process to prevent property-based spoofing. For applications unable to upgrade immediately, developers should implement strict input validation on all objects before serialization, ensuring that no untrusted data is copied onto typed arrays and avoiding the use of serialize functions with inputs derived from user-controlled sources without rigorous sanitization protocols.