CVE-2026-92708: devalue: Cross-request process memory disclosure in devalue when `stringify` / `uneval` serialize Node Buffers
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
devalueto a version that resolves this vulnerability.Fixed in 5.9.3 - Configuration
Before calling devalue stringify/uneval on Node Buffer values, convert each Node Buffer to a Uint8Array, so only the intended view is serialized rather than the Node Buffer backing ArrayBuffer.
devalue Workaround: Node Buffer serialization = Convert Node Buffer objects to Uint8Array before serialization
Event History
Frequently Asked Questions
Which deployments are realistically exposed to cross-request data leakage?
Server-side applications that use affected devalue versions and serialize Node Buffer values with stringify or uneval are exposed. This is especially consequential in SSR frameworks such as SvelteKit or Nuxt when a public render returns a small Buffer or reads a small file, because the serialized output can be sent in page HTML without authentication.
Does exploitation require an attacker to submit specially crafted input or authenticate?
No. The issue occurs whenever an affected application serializes a Node Buffer, and the described SSR scenario can expose data through a public page without authentication. The disclosed memory may include data from other in-flight requests, such as request bodies or Authorization headers.
Are parser-side prototype-pollution or denial-of-service protections relevant to this issue?
No. Those guards apply when parsing untrusted input, while this disclosure occurs during serialization. They do not prevent memory exposure caused by stringify or uneval serializing a Buffer's full backing ArrayBuffer.
What can be done if upgrading cannot happen immediately?
Convert Node Buffer objects to Uint8Array before passing values to stringify or uneval. Upgrading devalue to version 5.9.3 fixes the issue.