Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact 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 of unrelated process memory — including bytes from other in-flight requests — into the output. In an SSR framework (SvelteKit, Nuxt) a public page whose load() returns a 2-byte Buffer, or a small file read with readFileSync, ships another user's request body / Authorization header in its HTML. Unauthenticated, silent, ~43,000× amplification. This is serialization-side, so the parse/unflatten prototype-pollution and DoS guards do not apply — it fires on every SSR render, not only when parsing untrusted input. Workarounds Convert Node Buffer objects to Uint8Array:
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Under very constrained circumstances, data that was parsed and then passed to uneval could turn a small payload into a very large serialized string.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:
Recommended action: Upgrade to 5.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.6.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The parser's ArrayBuffer hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system. Impact This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources. Affected systems should upgrade to patched versions immediately.
Recommended action: Upgrade to 5.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The parser's typed array hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system. Impact This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources. Affected systems should upgrade to patched versions immediately.
Recommended action: Upgrade to 5.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1. devalue.parse allows proto to be set A string passed to devalue.parse could represent an object with a proto property, which would assign a prototype to an object while allowing properties to be overwritten: 2. devalue.parse allows array prototype methods to be assigned to object In a payload constructed with devalue.stringify, values are represented as array indices, where the array contains the 'hydrated' values: devalue.parse does not check that an index is numeric, which means that it could assign an array prototype method to a property instead: This could be used by a creative attacker to bypass server-side validation.
Recommended action: Upgrade to 5.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.