CVE-2026-92708 in devalue
Summary
by MITRE • 09/18/2026
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. In versions 5.1.0 through 5.9.2, stringify and uneval functions serialize a typed array by emitting its entire backing ArrayBuffer rather than only the view, so serializing a Node Buffer, whose backing store is a process-wide shared pool, discloses up to 64 KB of unrelated process memory, including bytes from other in-flight requests. In a server-side-rendered framework such as SvelteKit or Nuxt, a public page whose load() returns a small Buffer, or that reads a small file, can therefore ship another user's request body or Authorization header in its HTML without authentication. Because this occurs during serialization, it fires on every such render and is not mitigated by the parse/unflatten prototype-pollution and denial-of-service guards, which only apply when parsing untrusted input. As a workaround, convert Node Buffer objects to Uint8Array before serialization. This issue has been fixed in version 5.9.3.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified as Svelte devalue deserialization flaw represents a critical information disclosure risk within JavaScript libraries designed for serializing complex data structures into strings when standard JSON methods are insufficient. Specifically, this issue affects versions of the library ranging from 5.1.0 through 5.9.2 and centers on the behavior of its stringify and uneval functions when handling typed arrays. The core technical flaw lies in how these functions process Node.js Buffer objects. Instead of serializing only the specific view or slice of data intended for transmission, the library erroneously emits the entire backing ArrayBuffer associated with the typed array. This architectural oversight is particularly dangerous because Node.js Buffers utilize a process-wide shared memory pool to optimize performance and reduce allocation overhead. Consequently, when a developer passes a small Buffer object into the serialization function, the output includes not just the intended data but also adjacent memory contents from that shared pool.
This mechanism leads to severe operational impacts in server-side rendering environments such as SvelteKit or Nuxt applications. In these frameworks, it is common for public-facing pages to retrieve small amounts of data via load functions or by reading small files before sending HTML responses to clients. If the retrieved data is stored in a Node Buffer and subsequently passed through the vulnerable serialization logic, the resulting HTML payload will inadvertently contain up to 64 KB of unrelated process memory. This leaked memory often contains sensitive information from other concurrent requests processed by the same server instance. Attackers can exploit this behavior on public pages that do not require authentication to harvest credentials such as Authorization headers or request bodies belonging to other users. Because the leakage occurs during the serialization phase, it bypasses security controls designed for parsing untrusted input, including prototype pollution guards and denial-of-service mitigations, which only activate when data is being deserialized rather than serialized.
From a classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, as the application inadvertently reveals internal state that should remain confidential. It also relates to CWE-134: Use of Externally-Controlled Format String if one considers how the serialized output is constructed and transmitted without proper boundary checks on memory content. In terms of attack vectors, this falls under ATT&CK technique T1005: Data from Local System, where an adversary accesses data stored locally on a system to gain unauthorized access to sensitive information. The lack of isolation between different request contexts within the shared buffer pool allows for cross-request data leakage, effectively breaking the assumption that one user's session or request data remains isolated from another in multi-tenant server environments.
To mitigate this risk immediately, developers should ensure they are not passing Node Buffer objects directly into serialization functions provided by vulnerable versions of Svelte devalue. The recommended workaround is to convert any Node Buffer instances to Uint8Array before performing serialization operations. This conversion ensures that only the specific view data is processed rather than the entire backing ArrayBuffer shared across the process. Furthermore, organizations must upgrade their dependencies to version 5.9.3 or later, where this behavior has been corrected to serialize typed arrays correctly without exposing adjacent memory contents. Regular dependency audits and automated security scanning tools should be employed to detect such library vulnerabilities early in the development lifecycle, ensuring that serialization logic adheres strictly to data boundary expectations and prevents accidental exposure of sensitive process memory.