Devalue
Monthly
The npm package devalue (all versions through 5.6.2) can exhaust CPU and memory when it serializes a true sparse array through its uneval or stringify functions, producing a denial of service wherever such an array reaches a server-side serialization call. Practical exploitability is low despite the 8.7 CVSS 4.0 base score: JSON and form/query encodings cannot express an array with holes, so the sparse array must first be constructed by server-side application logic the attacker can influence, which is why our independent assessment scores the issue AC:H. No public exploit code has been identified at time of analysis, and the flaw is fixed in 5.6.3.
Denial of service in Svelte devalue through 5.9.2 can let remote, unauthenticated attackers block the Node.js event loop by routing attacker-influenced sparse arrays into uneval(), which performs synchronous work proportional to the array's declared length rather than its actual contents. The vendor describes exploitation as very difficult because attacker-controlled creation of sparse arrays is hard, and the independent assessment reflects that with AC:H and availability-only impact. Vendor-released patch: 5.9.3; no public exploit was identified at time of analysis and no CISA KEV entry is present in the supplied data.
Memory and CPU exhaustion in Svelte devalue through 5.9.2 can occur when an application parses attacker-controlled data with devalue and then passes the parsed value to uneval; repeated primitive strings cause quadratic expansion, turning a small payload into a very large serialized string. The impact is availability-only (CWE-400/CWE-409), and the trigger is constrained because the deployed application must contain that parse-then-uneval round trip on untrusted input, so this is not a default-configuration remote denial of service. The vendor fixed the package in devalue 5.9.3; no public exploit identified at time of analysis.
Memory exhaustion in Svelte devalue 1.0.0 through 5.9.2 occurs when an application uses uneval to serialize an attacker-influenced, very large sparse array and then evaluates the generated code, causing allocation proportional to the array's declared length. The supplied CVSS 4.0 vector rates this 8.7 with network reach, low complexity, no privileges, and no user interaction, but availability-only impact; the vendor states the default parse sparse-array path is unaffected and the common uneval-to-client use case would at worst exhaust a browser tab's memory. No public exploit was identified at time of analysis.
Memory-exhaustion denial of service in the npm library devalue (all versions up to and including 5.9.2) lets a malformed custom ArrayBuffer reviver bypass typed-array allocation validation inside parse(), so a very small crafted payload can cause allocation of massive ArrayBuffers. The flaw is not reachable by default: the integrating application must pass that malformed ArrayBuffer reviver to parse(), a configuration the GHSA describes as occurring only 'under very specific circumstances', and no public exploit code has been identified at time of analysis. Impact is confined to availability (VC:N/VI:N/VA:H, unauthenticated and without user interaction per the assessed vector), and the vendor shipped a fix in devalue 5.9.3.
Denial of service in the npm package devalue 5.8.0 through 5.9.2 lets a rejected internal promise from stringifyAsync go unhandled, so Node.js can terminate the process even when the caller catches the returned promise. Unauthenticated remote attackers can only trigger this if the application serializes multiple promises at once and lets untrusted input influence the timing or failure of those asynchronous values; the vendor describes exploitation as essentially impossible and far more likely to appear as a developer-introduced bug. There is no confidentiality or integrity impact - the only outcome is availability loss - and no public exploit has been identified at time of analysis.
Serialization of Node.js Buffer objects in the JavaScript library devalue 5.1.0 through 5.9.2 leaks unrelated process memory: when stringify, stringifyAsync, or uneval encounters a Buffer, it emits the view's entire backing ArrayBuffer instead of only the visible bytes, and because small Buffers are carved from Node's process-wide shared allocation pool, the serialized output can include up to roughly 64 KB of memory belonging to other in-flight requests. Any server-side-rendered application that serializes a Buffer into HTML without authentication - a SvelteKit or Nuxt page whose load() returns a small Buffer or reads a small file - can therefore publish another user's request body or Authorization header in a public response, and the flaw triggers on every such render because it occurs during serialization rather than parsing, so the library's parse/unflatten prototype-pollution and denial-of-service guards provide no protection. Unauthenticated remote attackers need no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5), the affected CPE is cpe:2.3:a:sveltejs:devalue:*, and no public exploit code or confirmed active exploitation was identified at time of analysis.
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.
Denial of service in Svelte devalue library versions 5.1.0 through 5.6.1 allows remote attackers to exhaust CPU and memory resources by supplying malformed input to the parse function, affecting applications that process untrusted serialized data. The vulnerability stems from insufficient validation of ArrayBuffer inputs during deserialization. Applications should upgrade to version 5.6.2 or later.
Denial of service in Svelte devalue versions 5.3.0 through 5.6.1 allows remote attackers to exhaust CPU and memory resources by supplying malformed input to the parse function, affecting applications that process untrusted data. The vulnerability stems from insufficient validation of typed array inputs before hydration, enabling attackers to trigger excessive resource consumption. Update to version 5.6.2 or later to remediate.
Prototype pollution in the npm package devalue (versions up to and including 5.6.2) allows attacker-influenced data to change the shape of reconstructed objects: when untrusted input is passed to `uneval` and the resulting code string is later `eval`ed, the generated objects can inherit polluted prototypes rather than matching the original input. The practical precondition is narrow - an application must both serialize untrusted data with `uneval` and then evaluate the produced string - and impact is limited to low confidentiality and integrity with no availability effect, which is why this is rated a low-priority, monitor-level issue rather than an emergency. Fixed in devalue 5.6.3; no public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing).
Prototype injection in the sveltejs devalue npm package (4.0.0 through 5.6.3) allows unauthenticated remote attackers to supply crafted serialized input that devalue.parse or devalue.unflatten deserializes into an object carrying a `__proto__` own property. The flaw becomes exploitable only when downstream application code copies that result onto a target object with Object.assign, at which point the target's prototype is polluted and its behavior can be influenced - the vendor states that emitting the `__proto__` property is not a vulnerability on its own. Impact is confined to integrity (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N; CVSS 4.0 base score 6.3 with AT:P reflecting the required downstream merge precondition), a fix ships in devalue 5.6.4, and no public exploit code was identified at time of analysis.
The npm package devalue (sveltejs) through 5.9.2 can be induced by crafted serialized payloads to produce objects carrying a __proto__ own property, an incomplete fix for GHSA-mwv9-gp5h-frr4. By the vendor's own statement this does not by itself cause prototype pollution - it mirrors native JSON.parse behavior - so any real impact depends on how downstream code handles the parsed object; the assessed impact is limited integrity only (I:L, no confidentiality or availability effect). Exploitation requires an application to pass attacker-controlled data to devalue's parse function; no public exploit code or active exploitation is identified, and the vendor ships a fix in 5.9.3.
Quadratic-complexity denial of service in the Svelte devalue JavaScript deserializer (all versions prior to 5.9.2) lets remote attackers stall Node/browser consuming processes by feeding a crafted serialized string to devalue.parse. Because the parser fails to reject indices greater than or equal to values.length in src/parse.js, a payload can alternate between array representations and force work that grows quadratically with payload size; the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) confirms this is unauthenticated and requires no user interaction, with impact limited to availability. Exploitation is deployment-conditional: the target application must actually call devalue.parse (or unflatten) on untrusted input - a library that only round-trips trusted internal data is not exposed regardless of version. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and EPSS data was not provided; the issue is fixed by rejecting out-of-bounds indices in version 5.9.2.
The npm package devalue (all versions through 5.6.2) can exhaust CPU and memory when it serializes a true sparse array through its uneval or stringify functions, producing a denial of service wherever such an array reaches a server-side serialization call. Practical exploitability is low despite the 8.7 CVSS 4.0 base score: JSON and form/query encodings cannot express an array with holes, so the sparse array must first be constructed by server-side application logic the attacker can influence, which is why our independent assessment scores the issue AC:H. No public exploit code has been identified at time of analysis, and the flaw is fixed in 5.6.3.
Denial of service in Svelte devalue through 5.9.2 can let remote, unauthenticated attackers block the Node.js event loop by routing attacker-influenced sparse arrays into uneval(), which performs synchronous work proportional to the array's declared length rather than its actual contents. The vendor describes exploitation as very difficult because attacker-controlled creation of sparse arrays is hard, and the independent assessment reflects that with AC:H and availability-only impact. Vendor-released patch: 5.9.3; no public exploit was identified at time of analysis and no CISA KEV entry is present in the supplied data.
Memory and CPU exhaustion in Svelte devalue through 5.9.2 can occur when an application parses attacker-controlled data with devalue and then passes the parsed value to uneval; repeated primitive strings cause quadratic expansion, turning a small payload into a very large serialized string. The impact is availability-only (CWE-400/CWE-409), and the trigger is constrained because the deployed application must contain that parse-then-uneval round trip on untrusted input, so this is not a default-configuration remote denial of service. The vendor fixed the package in devalue 5.9.3; no public exploit identified at time of analysis.
Memory exhaustion in Svelte devalue 1.0.0 through 5.9.2 occurs when an application uses uneval to serialize an attacker-influenced, very large sparse array and then evaluates the generated code, causing allocation proportional to the array's declared length. The supplied CVSS 4.0 vector rates this 8.7 with network reach, low complexity, no privileges, and no user interaction, but availability-only impact; the vendor states the default parse sparse-array path is unaffected and the common uneval-to-client use case would at worst exhaust a browser tab's memory. No public exploit was identified at time of analysis.
Memory-exhaustion denial of service in the npm library devalue (all versions up to and including 5.9.2) lets a malformed custom ArrayBuffer reviver bypass typed-array allocation validation inside parse(), so a very small crafted payload can cause allocation of massive ArrayBuffers. The flaw is not reachable by default: the integrating application must pass that malformed ArrayBuffer reviver to parse(), a configuration the GHSA describes as occurring only 'under very specific circumstances', and no public exploit code has been identified at time of analysis. Impact is confined to availability (VC:N/VI:N/VA:H, unauthenticated and without user interaction per the assessed vector), and the vendor shipped a fix in devalue 5.9.3.
Denial of service in the npm package devalue 5.8.0 through 5.9.2 lets a rejected internal promise from stringifyAsync go unhandled, so Node.js can terminate the process even when the caller catches the returned promise. Unauthenticated remote attackers can only trigger this if the application serializes multiple promises at once and lets untrusted input influence the timing or failure of those asynchronous values; the vendor describes exploitation as essentially impossible and far more likely to appear as a developer-introduced bug. There is no confidentiality or integrity impact - the only outcome is availability loss - and no public exploit has been identified at time of analysis.
Serialization of Node.js Buffer objects in the JavaScript library devalue 5.1.0 through 5.9.2 leaks unrelated process memory: when stringify, stringifyAsync, or uneval encounters a Buffer, it emits the view's entire backing ArrayBuffer instead of only the visible bytes, and because small Buffers are carved from Node's process-wide shared allocation pool, the serialized output can include up to roughly 64 KB of memory belonging to other in-flight requests. Any server-side-rendered application that serializes a Buffer into HTML without authentication - a SvelteKit or Nuxt page whose load() returns a small Buffer or reads a small file - can therefore publish another user's request body or Authorization header in a public response, and the flaw triggers on every such render because it occurs during serialization rather than parsing, so the library's parse/unflatten prototype-pollution and denial-of-service guards provide no protection. Unauthenticated remote attackers need no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5), the affected CPE is cpe:2.3:a:sveltejs:devalue:*, and no public exploit code or confirmed active exploitation was identified at time of analysis.
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.
Denial of service in Svelte devalue library versions 5.1.0 through 5.6.1 allows remote attackers to exhaust CPU and memory resources by supplying malformed input to the parse function, affecting applications that process untrusted serialized data. The vulnerability stems from insufficient validation of ArrayBuffer inputs during deserialization. Applications should upgrade to version 5.6.2 or later.
Denial of service in Svelte devalue versions 5.3.0 through 5.6.1 allows remote attackers to exhaust CPU and memory resources by supplying malformed input to the parse function, affecting applications that process untrusted data. The vulnerability stems from insufficient validation of typed array inputs before hydration, enabling attackers to trigger excessive resource consumption. Update to version 5.6.2 or later to remediate.
Prototype pollution in the npm package devalue (versions up to and including 5.6.2) allows attacker-influenced data to change the shape of reconstructed objects: when untrusted input is passed to `uneval` and the resulting code string is later `eval`ed, the generated objects can inherit polluted prototypes rather than matching the original input. The practical precondition is narrow - an application must both serialize untrusted data with `uneval` and then evaluate the produced string - and impact is limited to low confidentiality and integrity with no availability effect, which is why this is rated a low-priority, monitor-level issue rather than an emergency. Fixed in devalue 5.6.3; no public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing).
Prototype injection in the sveltejs devalue npm package (4.0.0 through 5.6.3) allows unauthenticated remote attackers to supply crafted serialized input that devalue.parse or devalue.unflatten deserializes into an object carrying a `__proto__` own property. The flaw becomes exploitable only when downstream application code copies that result onto a target object with Object.assign, at which point the target's prototype is polluted and its behavior can be influenced - the vendor states that emitting the `__proto__` property is not a vulnerability on its own. Impact is confined to integrity (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N; CVSS 4.0 base score 6.3 with AT:P reflecting the required downstream merge precondition), a fix ships in devalue 5.6.4, and no public exploit code was identified at time of analysis.
The npm package devalue (sveltejs) through 5.9.2 can be induced by crafted serialized payloads to produce objects carrying a __proto__ own property, an incomplete fix for GHSA-mwv9-gp5h-frr4. By the vendor's own statement this does not by itself cause prototype pollution - it mirrors native JSON.parse behavior - so any real impact depends on how downstream code handles the parsed object; the assessed impact is limited integrity only (I:L, no confidentiality or availability effect). Exploitation requires an application to pass attacker-controlled data to devalue's parse function; no public exploit code or active exploitation is identified, and the vendor ships a fix in 5.9.3.
Quadratic-complexity denial of service in the Svelte devalue JavaScript deserializer (all versions prior to 5.9.2) lets remote attackers stall Node/browser consuming processes by feeding a crafted serialized string to devalue.parse. Because the parser fails to reject indices greater than or equal to values.length in src/parse.js, a payload can alternate between array representations and force work that grows quadratically with payload size; the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) confirms this is unauthenticated and requires no user interaction, with impact limited to availability. Exploitation is deployment-conditional: the target application must actually call devalue.parse (or unflatten) on untrusted input - a library that only round-trips trusted internal data is not exposed regardless of version. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and EPSS data was not provided; the issue is fixed by rejecting out-of-bounds indices in version 5.9.2.