When serializing multiple promises, a later promise can reject before an earlier one settles. An internal rejected promise remains unhandled even if the caller catches the returned stringifyAsync promise. Under Node's default unhandled-rejection behavior this can terminate the process. Applications whose asynchronous failures/timing can be influenced by requests are potentially exposed. This is essentially impossible to exploit, and is much more likely to surface as a developer-introduced bug.
Evaluating legitimate uneval output for a sparse array can allocate memory proportional to its declared length. A tiny serialized value can therefore cause large memory allocation in a consuming browser/runtime. This occurs during evaluation of generated code, not in default parse sparse-array construction. You would only be affected by this if you were serializing very large sparse arrays and then evaluating the results. In the general use case for uneval …
uneval performs synchronous work proportional to a sparse array's declared length. An application that passes attacker-influenced sparse values to uneval can suffer event-loop blocking. Since attacker-controlled creation of sparse arrays is so difficult, this vulnerability is very difficult to exploit.
Under very constrained circumstances, data that was parsed and then passed to uneval could turn a small payload into a very large serialized string.
This is another instance of https://github.com/sveltejs/devalue/security/advisories/GHSA-mwv9-gp5h-frr4, where some payloads could cause parse to create objects with a proto own property. This on its own is not enough to cause prototype pollution, and indeed this is actually how JSON.parse works, but we decided to be a little more defensive here and not allow the creation of objects with proto own-properties. It is very unlikely for this to cause any issues.
Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver.
stringify and uneval serialize a typed array by emitting its backing ArrayBuffer, not just the view. In the case of a Node Buffer object, the backing buffer is a process-wide shared pool, meaning unrelated memory can be serialized into a response that is then sent to the client. For a Node Buffer the backing store is Node's process-wide shared pool, so serializing a small Buffer copies up to 64 KB …
devalue.parse prior to version 5.9.2 fails to reject out-of-bounds indices. Specially-crafted payloads can exploit this to cause devalue to alternate between different array representations, resulting in work that is quadratic with payload size. Applications are potentially affected if they call devalue.parse with untrusted data.
devalue.parse could, due to quirks in some JavaScript engines, be convinced to allocate much more memory than was needed when deserializing sparse arrays, leading to excessive memory consumption.
In some circumstances, devalue.parse and devalue.unflatten could emit objects with proto own properties. This in and of itself is not a security vulnerability (and is possible with, for example, JSON.parse as well), but it can result in prototype injection if downstream code handles it incorrectly: const result = devalue.parse(/* input creating an object with a proto property */); const target = {}; Object.assign(target, result); // target's prototype is now polluted
In devalue v5.6.3, devalue.parse and devalue.unflatten were susceptible to prototype pollution via maliciously crafted payloads. Successful exploitation could lead to Denial of Service (DoS) or type confusion.
Under certain circumstances, serializing sparse arrays using uneval or stringify could cause CPU and/or memory exhaustion. When this occurs on the server, it results in a DoS. This is extremely difficult to take advantage of in practice, as an attacker would have to manage to create a sparse array on the server — which is impossible in every mainstream wire format — and then that sparse array would have to …
Under certain circumstances, unevaling untrusted data can produce output code that will create objects with polluted prototypes when later evaled, meaning the output data can be a different shape from the input data.
Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the ArrayBuffer hydration expecting base64 encoded strings as input, but not checking the assumption before decoding the input.
Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the typed array hydration expecting an ArrayBuffer as input, but not checking the assumption before creating the typed array.