Is devalue safe ? 16 known vulnerabilities, worst severity HIGH.
// reach 0 direct dependencies
none carry a known advisory
18 packages depend on it
an advisory here reaches each of them
// ai model usage Tracked for PyPI packages. HuggingFace models declare Python dependencies, so npm packages are not covered.
cvss severity band, no base score published
epss chance of exploitation in 30 days
xyz score CyberXYZ composite out of 10
fig. 01 — GHSA-r9w8-h9r3-54w4, the advisory selected below
// 16 advisories GHSA-r9w8-h9r3-54w4 Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver. HIGH GHSA-x5rw-q4pp-hg5g 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. HIGH GHSA-j22f-vq7h-c4qm 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 HIGH GHSA-mcm9-63f2-9j32 Under very constrained circumstances, data that was parsed and then passed to uneval could turn a small payload into a very large serialized string. HIGH GHSA-77vg-94rm-hx3p 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. HIGH GHSA-g2pg-6438-jwpf 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. HIGH GHSA-vw5p-8cq8-m7mv 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. HIGH GHSA-vj54-72f3-p5jv 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: HIGH GHSA-hx4r-w6wj-j8fg 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. MODE GHSA-4q55-j62x-fr9h 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 __pro MODE Show all 16 advisories
GHSA-r9w8-h9r3-54w4 HIGH GitHub rating Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver.
Checked 2026-11-06 at 22:40 UTC. The most recent advisory here was published 2026-10-01. Updated continuously from NVD, GHSA, OSV and CNA feeds.
Think a verdict here is wrong? Tell us — we respond within 2 business days. Report an issue with this page