devalue Prototype Pollution and Resource Exhaustion

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 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.

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.

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.

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.

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.

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.

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).