PatchFirst · Latest vulnerabilities
Vulnerabilities published for devalue in the last 30 days: 6. Listed in the KEV catalogue: 0.
Vulnerabilities: 16
`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 `parse`d and then passed to `uneval` could turn a small payload into a very large serialized string.
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` of sending data to the client, the worst that could happen is the browser tab running out of memory.
Under very specific circumstances, `parse` could create massive ArrayBuffers with very small input. This required a malformed `ArrayBuffer` custom reviver.
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.
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.
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. In versions 5.1.0 through 5.9.2, stringify and uneval functions serialize a typed array by emitting its entire backing ArrayBuffer rather than only the view, so serializing a Node Buffer, whose backing store is a process-wide shared pool, discloses up to 64 KB of unrelated process memory, including bytes from other in-flight requests. In a server-side-rendered framework such as SvelteKit or Nuxt, a public page whose load() returns a small Buffer, or that reads a small file, can therefore ship another user's request body
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. Prior to 5.9.2, devalue.parse does not reject out-of-bounds indices that are greater than or equal to values.length in src/parse.js. A specially crafted untrusted payload can make the parser alternate between array representations, producing quadratic work as the payload grows and causing denial of service in applications that parse untrusted devalue data. This issue is fixed in version 5.9.2.
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. From version 5.6.3 to before version 5.8.1, 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. This issue has been patched in version 5.8.1.
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: ```ts const result = devalue.parse(/* input creating an object with a __proto__ property */); const target = {}; Object.assign(target, result); // target's prototype is now polluted ```
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. In devalue v5.6.3 and earlier, 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. This vulnerability is fixed in 5.6.4.
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 be run through `uneval` or `stringify`.
Under certain circumstances, `uneval`ing untrusted data can produce output code that will create objects with polluted prototypes when later `eval`ed, meaning the output data can be a different shape from the input data.
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. From 5.1.0 to 5.6.1, 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. This vulnerability is fixed in 5.6.2.
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. From 5.3.0 to 5.6.1, 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. This vulnerability is fixed in 5.6.2.
Svelte devalue is a utility library. Prior to version 5.3.2, a string passed to devalue.parse could represent an object with a __proto__ property and devalue.parse does not check that an index is numeric. This could result in assigning prototypes to objects and properties, leading to prototype pollution. This issue has been fixed in version 5.3.2
Check your installed stack and versions against the current vulnerability feeds.