GHSA-jp82-f5mq-hwhp: High severity npm/seroval vulnerability
Summary
deserializeTypedArray casts the source node to ArrayBuffer without checking it and never bounds the element count. Pass a plain object with a length property and it hits the array-like TypedArray constructor, allocating that many elements. The offset guard above it can't stop this: source.byteLength is undefined, so the comparison is always false.
The length is one integer in the JSON, so a tiny payload can name any allocation size, and it runs synchronously inside fromJSON, starving the event loop instead of just slowing one request. fromCrossJSON is the same.
Impact is unauthenticated CPU/memory exhaustion for any service deserializing untrusted Seroval JSON: same profile as the array-length and nested-depth DoS issues already fixed here. No confidentiality or integrity impact. DataView has the same unchecked cast but throws instead of allocating. A runtime instanceof ArrayBuffer check plus a size cap should fix it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/serovalto a version that resolves this vulnerability.Fixed in 1.6.3 - Compensating control
In deserializeTypedArray and fromCrossJSON, validate that the source is an ArrayBuffer at runtime before casting, enforce a maximum element/allocation size, and apply the same unchecked-cast validation and size cap to the DataView path.
Event History
Frequently Asked Questions
Which deployments are exposed?
Services that deserialize untrusted Seroval JSON through fromJSON or fromCrossJSON are exposed. The described impact is unauthenticated CPU and memory exhaustion; confidentiality and integrity are not affected.
What does an attacker need to exploit this?
An attacker needs to supply crafted JSON that reaches the affected deserialization functions. A small payload containing a plain object with a chosen integer length can request an arbitrarily large TypedArray allocation.
Why does the existing offset validation not prevent exploitation?
For a plain object, source.byteLength is undefined, causing the offset comparison to evaluate false. Processing then reaches the array-like TypedArray constructor rather than rejecting the input.
What can be done if patching is not immediately possible?
Where application code controls deserialization inputs, reject sources that are not ArrayBuffer instances and enforce a maximum permitted element count before constructing a TypedArray. Restricting untrusted data from reaching fromJSON and fromCrossJSON also removes the described attack path.
How can I identify an affected use case?
Review whether untrusted JSON is passed to Seroval's fromJSON or fromCrossJSON and whether the input can represent typed-array data. Inputs containing a plain object with a length property are relevant to the described allocation path.