CVE-2026-42570: Svelte Devalue Denial-of-Service via Sparse Array Deserialization

Technical summary

The vulnerability resides in devalue.parse's handling of sparse arrays during deserialization. When parsing untrusted input containing arrays with large gaps between populated indices, certain JavaScript engines allocate memory for all intermediate slots rather than storing only the defined values. An attacker can construct payloads that exploit this behavior to allocate gigabytes of memory with relatively small input, triggering out-of-memory conditions. The root cause stems from how different JS engines (V8, SpiderMonkey, JavaScriptCore) optimize array internals—devalue does not normalize or validate array density before allocation. The fix in 5.8.1 includes array preprocessing logic to detect and handle sparse arrays safely.

Business impact

Any application using devalue for server-side or client-side deserialization of untrusted data faces a denial-of-service risk. Supply chain attacks are a concern: if a package uses devalue and is itself consumed by downstream applications, a single compromised upstream package can cascade the vulnerability. Organizations processing user-submitted JSON-like structures (APIs, webhooks, form data) that rely on devalue for serialization are at risk. Affected applications may become unresponsive, drop user sessions, or require restarts—particularly problematic for long-running services or Lambda/serverless environments with memory constraints.

Affected systems

The vulnerability affects Svelte devalue versions 5.6.3 through 5.8.0 (inclusive). Any application or library that imports devalue and calls devalue.parse on untrusted input is affected. This includes Svelte applications, Node.js backend services, and bundled web applications. The Svelte framework itself uses devalue; dependent packages in the npm ecosystem should be inventoried. Verify your supply chain to identify all direct and transitive dependencies on devalue.

Exploitability

Exploitability is straightforward for attackers with network access to untrusted input channels. No authentication, user interaction, or special privileges are required. The attack is network-accessible and requires only crafting a malicious payload containing a sparse array—well within reach of script-based exploitation. However, practical impact depends on the application's memory limits and how the application exposes devalue.parse. If the service runs in a containerized environment with memory quotas, the impact may be mitigated to service restart rather than host-level compromise. Public proof-of-concept payloads are unlikely to exist (as of publication), but the attack surface is low-complexity.

Remediation

Upgrade devalue to version 5.8.1 or later immediately. Review your npm dependency tree (npm ls devalue) to identify all direct and transitive occurrences. If you cannot upgrade devalue directly, depend on a later version of any package that bundles it. For applications that deserialize untrusted data, consider implementing input validation or sandboxing—for example, limiting payload size before passing to devalue.parse, or running deserialization in a worker process with memory quotas. Validate that your updated version has propagated through your build pipeline and is deployed to all affected services.

Patch guidance

Upgrade to devalue 5.8.1 via npm update devalue or by explicitly setting "devalue": "^5.8.1" in package.json, then run npm install and npm audit to confirm no regressions. For monorepos or workspaces, ensure all affected packages reference the patched version. Test deserialization workflows with existing payloads to confirm compatibility. If you maintain packages that depend on devalue, release a patched version and notify your own consumers. Verify the patch by checking node_modules/devalue/package.json version field post-install.

Detection guidance

Monitor application memory usage patterns, particularly spikes coinciding with deserialization operations. Enable heap snapshot analysis in Node.js (--inspect flag) to observe allocation patterns during parse calls. Log payload sizes and array dimensions passed to devalue.parse; anomalously sparse arrays with millions of indices but few values are a red flag. Implement request rate-limiting and payload size caps on endpoints that accept untrusted serialized data. Alert on out-of-memory errors in application logs, especially if they correlate with unusual input. Use Web Application Firewalls (WAF) to detect and block payloads with suspicious array patterns (large index ranges, minimal density).

Why prioritize this

This vulnerability warrants high priority due to its network accessibility, low attack complexity, and guaranteed denial-of-service impact. The CVSS 7.5 score reflects the availability threat. While not in CISA's Known Exploited Vulnerabilities catalog as of the published date, the simplicity of crafting exploits means adoption could be rapid. Organizations with public APIs, multi-tenant SaaS platforms, or critical always-on services should patch within days. Downstream package maintainers should backport and communicate urgently to their own users.

Risk score, explained

The CVSS v3.1 score of 7.5 (HIGH) is driven by: network accessibility (AV:N), low attack complexity (AC:L), no privilege or user interaction required (PR:N, UI:N), and a guaranteed availability impact (A:H). Confidentiality and integrity are unaffected (C:N, I:N). The unchanged scope (S:U) indicates the vulnerability does not jump privilege boundaries. This is a classic availability-focused denial-of-service vulnerability. The score does not account for supply-chain risk or ecosystem reach; consider local context when prioritizing within your organization.

Frequently asked questions