Description

Seroval facilitates JS value stringification, including complex structures beyond JSON.stringify capabilities. Prior to 1.6.3, deserializeTypedArray in fromJSON and fromCrossJSON trusts a deserialized source value as an ArrayBuffer and does not bound the serialized element count. An attacker can provide a small untrusted JSON object with a large length value, causing the array-like TypedArray constructor to synchronously allocate the selected number of elements and exhaust CPU or memory while starving the event loop. The offset check does not reject the crafted source because source.byteLength is undefined. DataView reaches a similar unchecked cast but throws rather than allocating, and the issue has no identified confidentiality or integrity impact. This issue is fixed in version 1.6.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-02T16:16:47.070Z",
  "pubdate": "2026-10-02T16:16:47.070Z",
  "executiveSummary": "A denial of service (DoS) vulnerability has been identified in Seroval, a library designed for JavaScript value stringification of complex data structures. In versions prior to 1.6.3, the deserialization functions fromJSON and fromCrossJSON fail to securely process untrusted input within the deserializeTypedArray component. Specifically, the implementation lacks proper validation and bounding checks on the element count during the reconstruction of typed arrays, while trusting a deserialized source value as an ArrayBuffer. An attacker can exploit this flaw by submitting a small, crafted JSON payload containing an artificially inflated length value. When processed, this payload forces the underlying JavaScript engine to perform a massive synchronous allocation, leading to severe CPU exhaustion, memory starvation, and event loop blockage. This effectively renders the application unresponsive to legitimate users. The vulnerability requires no authentication or special privileges, representing a significant availability risk for services utilizing Seroval to deserialize untrusted user input. While DataView components suffer a similar unchecked cast, they safely throw an exception instead of allocating memory. This issue has been fully resolved in Seroval version 1.6.3.",
  "technicalDetails": "The root cause of this vulnerability lies in the deserializeTypedArray function, which is utilized by both fromJSON and fromCrossJSON to reconstruct serialized JavaScript TypedArray structures. During the deserialization process, the application processes a source object representation that it expects to be an ArrayBuffer. However, the logic fails to enforce boundary constraints on the incoming serialized element count, allowing an arbitrary and untrusted size parameter to be passed directly to the array-like TypedArray constructor.\nTo prevent malformed offsets, the implementation includes an offset verification mechanism. However, this check is rendered ineffective against crafted payloads because it relies on the source.byteLength property. When an attacker provides a custom, non-ArrayBuffer JSON object, the source.byteLength property resolves to undefined. Because undefined bypasses or fails to trigger the rejection logic in the offset check, the application continues execution with the invalid source.\nAn attacker can exploit this behavior by constructing a highly compressed, minimal JSON structure that specifies an extremely large length attribute. When the application attempts to deserialize this payload, the deserializeTypedArray function invokes the TypedArray constructor synchronously using the attacker-supplied length. The JavaScript runtime immediately attempts to allocate the requested number of elements in memory.\nBecause JavaScript is single-threaded and relies on an event loop, this synchronous memory allocation block completely starves the event loop. The process becomes entirely unresponsive to any concurrent or subsequent network requests. Depending on the configured limits of the hosting environment (such as Node.js heap limits), this allocation attempt will either trigger an immediate Out-Of-Memory (OOM) crash, terminating the process, or cause prolonged 100% CPU utilization as the garbage collector struggles to manage the heap.\nNotably, a similar unchecked cast occurs within the processing of DataView structures. However, the DataView implementation throws a runtime error instead of attempting a synchronous allocation, which prevents it from being abused for resource exhaustion. The vulnerability presents no risk to data confidentiality or integrity, as it does not facilitate unauthorized data access or modification. The flaw is resolved in version 1.6.3 by introducing strict bounds checking and ensuring the deserialized source undergoes appropriate type validation before constructor execution."
}